Реалізація Gradle vs API

Я намагаюся зрозуміти це , в чому різниця між apiі implementationконфігурацією при побудові своїх залежностей.
У документації йдеться про те, що implementationкращий час на побудову, але, побачивши цей коментар у подібному питанні, я повинен задуматися, чи правда це.
Оскільки я не фахівець з граду, я сподіваюся, що хтось може допомогти. Я вже читав документацію, але мені цікаво було легко зрозуміти пояснення.

compileКлючове слово Gradle застаріле на користь apiта implementationключових слів для налаштування залежностей.

Використовуючи apiце еквівалент з використанням застарілого compile, так що якщо ви заміните всі compileзі apiвсім , буде працювати як завжди.

Для розуміння implementationключового слова розглянемо наступний приклад.

ПРИКЛАД

Припустимо, у вас є бібліотека під назвою, MyLibraryяка внутрішньо використовує іншу бібліотеку під назвою InternalLibrary. Щось на зразок цього:

    // 'InternalLibrary' module
    public class InternalLibrary {
        public static String giveMeAString(){
            return "hello";
        }
    }

    // 'MyLibrary' module
    public class MyLibrary {
        public String myString(){
            return InternalLibrary.giveMeAString();
        }
    }

Припустимо, конфігурація MyLibrary build.gradleвикористання виглядає так:apidependencies{}

dependencies {
    api project(':InternalLibrary')
}

Ви хочете використовувати MyLibraryу своєму коді, щоб у додатку build.gradleдодавати цю залежність:

dependencies {
    implementation project(':MyLibrary')
}

За допомогою apiконфігурації (або застарілої compile) ви можете отримати доступ InternalLibraryу коді програми:

// Access 'MyLibrary' (granted)
MyLibrary myLib = new MyLibrary();
System.out.println(myLib.myString());

// Can ALSO access the internal library too (and you shouldn't)
System.out.println(InternalLibrary.giveMeAString());

Таким чином модуль MyLibraryпотенційно "просочує" внутрішню реалізацію чогось. Ви не повинні (бути в змозі) використовувати це, оскільки це не безпосередньо імпортоване вами.

implementationКонфігурація була введена , щоб запобігти цьому. Так що тепер , якщо ви використовуєте implementationзамість apiв MyLibrary:

dependencies {
    implementation project(':InternalLibrary')
}

ви більше не зможете зателефонувати InternalLibrary.giveMeAString()у свій додаток.

Така стратегія боксу дозволяє плагіну Android Gradle знати, що якщо ви щось редагуєте InternalLibrary, він повинен викликати лише перекомпіляцію, MyLibraryа не перекомпіляцію всього вашого додатка, оскільки ви не маєте доступу до нього InternalLibrary.

Коли у вас багато вкладених залежностей, цей механізм може значно прискорити збірку. (Дивіться відео, пов'язане в кінці, для повного розуміння цього)

ВИСНОВКИ

• При переході на новий Android Gradle плагін 3.xx, ви повинні замінити всі ваші compileз implementationключовим словом (1 *) . Потім спробуйте скласти і протестувати додаток. Якщо все нормально, залиште код таким, як є, якщо у вас є проблеми, ви, мабуть, щось не так з вашими залежностями або ви використовували щось, що зараз є приватним і не доступнішим. Пропозиція інженера плагінів Android Gradle Джерома Дочеса (1 ) * )

• Якщо ви керуєте бібліотекою, ви повинні використовувати apiдля кожної залежності, яка необхідна для загальнодоступного API вашої бібліотеки, тоді як використовувати implementationдля тестових залежностей або залежностей, які не повинні використовуватись кінцевими користувачами.

Корисна стаття, що показує різницю між впровадженням та api

ДОВІДКИ (Це те саме відео, розбите для економії часу)

Google I / O 2017 - Як прискорити створення Gradle (ПОВНЕ ВІДЕО)

Google I / O 2017 - Як прискорити побудову Gradle (НОВОЇ ДІЯЛЬНОЇ ГРАНІ ПЛУГІН 3.0.0)

Google I / O 2017 - Як прискорити створення Gradle (посилання на 1 * )

Документація на Android

Мені подобається думати про apiзалежність як публічну (бачиться іншими модулями), а implementationзалежність - як приватну (бачиться лише цим модулем).

Зауважте, що на відміну від public/ privateзмінних та методів, api/ implementationзалежності не виконуються під час виконання. Це лише оптимізація часу нарощування, яка дозволяє Gradleзнати, які модулі потрібно перекомпілювати, коли одна із залежностей змінює свій API.

Подумайте, у вас є appмодуль, який використовується lib1як бібліотека і lib1використовується lib2як бібліотека. Що - щось на зразок цього: app -> lib1 -> lib2.

Тепер при використанні api lib2в lib1, тоді ви app можете бачити lib2 коди при використанні: api lib1або implementation lib1в appмодулі.

АЛЕ при використанні implementation lib2в lib1, то app не можете побачити на lib2коди.

Відповіді @matpag та @ dev- bmax досить чіткі, щоб люди зрозуміли різні звички між впровадженням та api. Я просто хочу зробити додаткове пояснення з іншого боку, сподіваюся допомогти людям, які мають те саме питання.

Я створив два проекти для тестування:

• проект A як проект бібліотеки Java під назвою 'frameworks-web-gradle-plugin' залежить від 'org.springframework.boot: spring-boot-gradle-plugin: 1.5.20. RELEASE'
• проект B залежить від проекту A від реалізації 'com.example.frameworks.gradle: frameworks-web-gradle-plugin: 0.0.1-SNAPSHOT'

Описана вище ієрархія залежностей виглядає так:

[project-b] -> [project-a] -> [spring-boot-gradle-plugin]

Тоді я перевірив такі сценарії:

1. Зробити проект A залежить від 'org.springframework.boot: spring-boot-gradle-plugin: 1.5.20. RELEASE' за реалізацією .

   Запустити gradle dependenciesкоманду в терміналі в кореневому dir ject B ， з наступним скріншотом виводу, ми можемо побачити, що 'spring-boot-gradle-plugin' з'являється в дереві залежностей runtimeClasspath, але не в compileClasspath's, я думаю, що саме тому ми не можемо зробити використання бібліотеки, декларованої за допомогою реалізації, просто не буде компіляцією.

   

2. Зробити проект A залежить від 'org.springframework.boot: spring-boot-gradle-plugin: 1.5.20.RELEASE' від api

   gradle dependenciesЗнову запустіть команду в терміналі в кореневому реєстрі B об'єкта B. Тепер 'spring-boot-gradle-plugin' з'являється у дереві залежностей compileClasspath та runtimeClasspath.

   

Суттєва відмінність, яку я помітив, полягає в тому, що залежність у проекті виробника / бібліотечного проекту, оголошеного способом впровадження, не з’явиться в compileClasspath споживчих проектів, так що ми не можемо використовувати відповідну лібу у споживчих проектах.

З документації gradle :

Давайте розглянемо дуже простий сценарій збірки для проекту на базі JVM.

plugins {
    id 'java-library'
}

repositories {
    mavenCentral()
}

dependencies {
    implementation 'org.hibernate:hibernate-core:3.6.7.Final'
    api 'com.google.guava:guava:23.0'
    testImplementation 'junit:junit:4.+'
}

реалізація

Залежності, необхідні для складання джерела виробництва проекту, які не є частиною API, що піддається проекту. Наприклад, проект використовує Hibernate для своєї внутрішньої стійкості шару.

апі

Залежності, необхідні для складання виробничого джерела проекту, що є частиною API, що піддається проекту. Наприклад, проект використовує Guava та розкриває публічні інтерфейси з класами Guava в їхніх підписах методів.