Unable to understand the latest gradle dependency configurations which are introduced in Android Studio 3.0 i.e. implementation, api , compileonly and runtimeonly.
Please refer the link : Android Studio 3.0 New Gradle Configuration available at android developers official site.
Based on description mentioned in above link:
implementation: When your module configures an implementation dependency, it's letting Gradle know that the module does not want to
leak the dependency to other modules at compile time. That is, the
dependency is available to other modules only at runtime. Using this
dependency configuration instead of api or compile can result in
significant build time improvements because it reduces the amount of
projects that the build system needs to recompile. For example, if an
implementation dependency changes its API, Gradle recompiles only that
dependency and the modules that directly depend on it. Most app and
test modules should use this configuration.
api: When a module includes an api dependency, it's letting Gradle know that the module wants to transitively export that
dependency to other modules, so that it's available to them at both
runtime and compile time. This configuration behaves just like compile
(which is now deprecated), and you should typically use this only in
library modules. That's because, if an api dependency changes its
external API, Gradle recompiles all modules that have access to that
dependency at compile time. So, having a large number of api
dependencies can significantly increase build times. Unless you want
to expose a dependency's API to a separate test module, app modules
should instead use implementation dependencies.
compileOnly: Gradle adds the dependency to the compilation classpath only (it is not added to the build output). This is useful
when you're creating an Android library module and you need the
dependency during compilation, but it's optional to have present at
runtime. That is, if you use this configuration, then your library
module must include a runtime condition to check whether the
dependency is available, and then gracefully change its behavior so it
can still function if it's not provided. This helps reduce the size of
the final APK by not adding transient dependencies that aren't
critical. This configuration behaves just like provided (which is now
deprecated).
runtimeonly: Gradle adds the dependency to the build output only, for use during runtime. That is, it is not added to the compile
classpath. This configuration behaves just like apk (which is now
deprecated).
Related
I'm using com.android.tools.build:gradle:3.1.1 with the latest Gradle version (https://services.gradle.org/distributions-snapshots/gradle-4.8-20180417000132+0000-all.zip).
When I use compileOnly dependencies some of them won't compile, some will.
E.g.
compileOnly "com.android.support:support-v4:27.1.1"
works perfectly while
compileOnly "com.facebook.stetho:stetho:1.5.0"
gives a compile error:
Android dependency 'com.facebook.stetho:stetho:1.5.0' is set to compileOnly/provided which is not supported
I was under the impression than any dependency can be compileOnly. Nothing indicates otherwise (https://developer.android.com/studio/build/gradle-plugin-3-0-0-migration.html#new_configurations). Both of these libraries have transitive dependencies.
Any help would be greatly appreciated.
As an experiment, I created a new Android Studio 3.1.1 project. Then, I added a lib module to it as a plain Java library module. I could add compileOnly project(":lib") to the app module, and it compiled. I changed the lib module to be an Android library module (apply plugin: 'com.android.library') with a minimum manifest, and now compileOnly project(":lib") gets the error that you do: "Android dependency 'project :lib' is set to compileOnly/provided which is not supported".
Since there were no other material changes in the lib module, the compileOnly limitation is on Android library modules.
My guess is that it is unclear what "compile only" means for manifest entries, resources, assets, etc. So, they officially punted.
I filed an issue, requesting documentation of this limitation. My requests for documentation usually fall on deaf ears.
At the dawn of "Dynamic feature modules", compileOnly Android library modules could make sense, to allow easy access to the feature module from the base app when it is installed.
That's why I created this feature request: https://issuetracker.google.com/issues/109894265
Feel free to star it and comment with your use cases.
I had a similar issue on a project with many libraries.
I have a libX that I implement in debug with debugImplementation project(':libX') to work with sources, but in release build I target published version releaseImplementation "com.company:libX:1.0.0".
After a refactor, I got a similar error during a release sync about my libX.
Android dependency 'com.company:libX:1.0.0' is set to compileOnly/provided which is not supported.
However, I wasn't using any compileOnly...
The problem was due to one lib which was using libX always as source, (implementation project(':libX')). So in release, gradle was confused as it was implementing libX as sources in some libs, and as published lib in other.
Upgrade to Android Studio 3.0.0 mentions this, and doesn't elaborate on how to handle it:
Library modules no longer process local JARs. This is to speed up incremental builds that are caused by changes to a library module's code.
So I have a project with a library project in it. In my library project's build.gradle file I have this:
compile files('libs/com.somelib.somepackage.jar')
I changed compile to implementation and when I tried to run my app, all my classes that tried to access the import com.somelib.somepackage.SomeClass import statement threw an error that this package didnt exist.
I changed back to compile and I was able to build and run my app.
I want to comply to the new rules since compile is deprecated and will be removed with the next Gradle release, so how do I go about doing that?
If you are trying to access classes from the .jar that is included in the library project from the app project, you will have to use api instead of implementation otherwise the classes will only be accessible in the library project:
implementation files('libs/com.somelib.somepackage.jar')
should be
api files('libs/com.somelib/somepackage.jar')
As said by the documentation:
... When a module includes an api dependency, it's letting Gradle know
that the module wants to transitively export that dependency to other
modules, so that it's available to them at both runtime and compile
time ...
Reference:
https://developer.android.com/studio/build/gradle-plugin-3-0-0-migration.html#new_configurations
I'm trying to figure out what is the difference between api and implementation configuration while building my dependencies.
In the documentation, it says that implementation has better build time, but, seeing this comment in a similar question I got to wonder if is it true.
Since I'm no expert in Gradle, I hope someone can help. I've read the documentation already but I was wondering about an easy-to-understand explanation.
Gradle compile keyword was deprecated in favor of the api and implementation keywords to configure dependencies.
Using api is the equivalent of using the deprecated compile, so if you replace all compile with api everything will works as always.
To understand the implementation keyword consider the following example.
EXAMPLE
Suppose you have a library called MyLibrary that internally uses another library called InternalLibrary. Something like this:
// 'InternalLibrary' module
public class InternalLibrary {
public static String giveMeAString(){
return "hello";
}
}
// 'MyLibrary' module
public class MyLibrary {
public String myString(){
return InternalLibrary.giveMeAString();
}
}
Suppose the MyLibrary build.gradle uses api configuration in dependencies{} like this:
dependencies {
api(project(":InternalLibrary"))
}
You want to use MyLibrary in your code so in your app's build.gradle you add this dependency:
dependencies {
implementation(project(":MyLibrary"))
}
Using the api configuration (or deprecated compile) you can access InternalLibrary in your application code:
// Access 'MyLibrary' (granted)
MyLibrary myLib = new MyLibrary();
System.out.println(myLib.myString());
// Can ALSO access the internal library too (but you shouldn't)
System.out.println(InternalLibrary.giveMeAString());
In this way the module MyLibrary is potentially "leaking" the internal implementation of something. You shouldn't (be able to) use that because it's not directly imported by you.
The implementation configuration was introduced to prevent this.
So now if you use implementation instead of api in MyLibrary:
dependencies {
implementation(project(":InternalLibrary"))
}
you won't be able to call InternalLibrary.giveMeAString() in your app code anymore.
This sort of boxing strategy allows Android Gradle plugin to know that if you edit something in InternalLibrary, it must only trigger the recompilation of MyLibrary and not the recompilation of your entire app, because you don't have access to InternalLibrary.
When you have a lot of nested dependencies this mechanism can speed up the build a lot. (Watch the video linked at the end for a full understanding of this)
CONCLUSIONS
When you switch to the new Android Gradle plugin 3.X.X, you should replace all your compile with the implementation keyword *(1). Then try to compile and test your app. If everything it's ok leave the code as is, if you have problems you probably have something wrong with your dependencies or you used something that now is private and not more accessible. *Suggestion by Android Gradle plugin engineer Jerome Dochez (1))
If you are a library mantainer you should use api for every dependency which is needed for the public API of your library, while use implementation for test dependencies or dependencies which must not be used by the final users.
Useful article Showcasing the difference between implementation and api
REFERENCES
(This is the same video splitted up for time saving)
Google I/O 2017 - How speed up Gradle builds (FULL VIDEO)
Google I/O 2017 - How speed up Gradle builds (NEW GRADLE PLUGIN 3.0.0 PART ONLY)
Google I/O 2017 - How speed up Gradle builds (reference to 1*)
Android documentation
I like to think about an api dependency as public (seen by other modules) while implementation dependency as private (only seen by this module).
Note, that unlike public/private variables and methods, api/implementation dependencies are not enforced by the runtime. This is merely a build-time optimization, that allows Gradle to know which modules it needs to recompile when one of the dependencies changes its API.
Consider you have app module which uses lib1 as a library and lib1 uses lib2 as a library. Something like this: app -> lib1 -> lib2.
Now when using api lib2 in lib1, then app can see lib2 code when using: api lib1 or implementation lib1 in the app module.
BUT when using implementation lib2 in lib1, then app can not see the lib2 code.
Please refer the link: Android Studio Dependency Configuration available at android developers' official site.
Inside the dependencies block, you can declare a library dependency using one of several different dependency configurations (such as implementation shown above). Each dependency configuration provides Gradle with different instructions about how to use the dependency.
implementation
Gradle adds the dependency to the compile classpath and packages the dependency to the build output. However, when your module configures an implementation dependency, it's letting Gradle know that you do not want the module to leak the dependency to other modules at compile time. That is, the dependency is available to other modules only at runtime.
Using this dependency configuration instead of api or compile (deprecated) can result in significant build time improvements because it reduces the number of modules that the build system needs to recompile. For example, if an implementation dependency changes its API, Gradle recompiles only that dependency and the modules that directly depend on it. Most app and test modules should use this configuration.
api
Gradle adds the dependency to the compile classpath and build output. When a module includes an api dependency, it's letting Gradle know that the module wants to transitively export that dependency to other modules, so that it's available to them at both runtime and compile time.
This configuration behaves just like compile (which is now deprecated), but you should use it with caution and only with dependencies that you need to transitively export to other upstream consumers. That's because, if an api dependency changes its external API, Gradle recompiles all modules that have access to that dependency at compile time. So, having a large number of api dependencies can significantly increase build time. Unless you want to expose a dependency's API to a separate module, library modules should instead use implementation dependencies.
From gradle documentation:
Let’s have a look at a very simple build script for a JVM-based project.
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.+'
}
implementation
The dependencies required to compile the production source of the project which are not part of the API exposed by the project. For example the project uses Hibernate for its internal persistence layer implementation.
api
The dependencies required to compile the production source of the project which are part of the API exposed by the project. For example the project uses Guava and exposes public interfaces with Guava classes in their method signatures.
Answers from #matpag and #dev-bmax are clear enough to make people understand different usages between implementation and api. I just want to make an extra explaination from another angle, hopes to help for peoples that have the same question.
I created two projects for testing :
project A as a java library project named 'frameworks-web-gradle-plugin' depends on 'org.springframework.boot:spring-boot-gradle-plugin:1.5.20.RELEASE'
project B depends on project A by implementation 'com.example.frameworks.gradle:frameworks-web-gradle-plugin:0.0.1-SNAPSHOT'
The dependencies hierarchy descripted above looks like:
[project-b] -> [project-a] -> [spring-boot-gradle-plugin]
Then I tested following scenarios:
Make project A depends on 'org.springframework.boot:spring-boot-gradle-plugin:1.5.20.RELEASE' by implementation .
Run gradle dependencies command in a terminal in poject B root dir，with following screenshot of output we can see that 'spring-boot-gradle-plugin' appears in runtimeClasspath dependencies tree, but not in compileClasspath's, I think that's exactly why we can't make use of library that declared using implementation, it just won't through compilation.
Make project A depends on 'org.springframework.boot:spring-boot-gradle-plugin:1.5.20.RELEASE' by api
Run gradle dependencies command in a terminal in poject B root dir again.
Now 'spring-boot-gradle-plugin' appears both in compileClasspath and runtimeClasspath dependencies tree.
A significant difference I noticed is that the dependency in producer/library project declared in implementation way won't appear in compileClasspath of consumer projects, so that we can't make use of corresponding lib in the consumer projects.
One more technical note regarding api vs implementation. Suppose you have following dependencies:
dependencies {
api "com.example:foo:1.0"
implementation "com.example:bar:1.0"
}
If you install a generated jar file in your local Maven repository (with help of maven-publish plugin) you will see that generated pom.xml file will look like this:
<dependency>
<groupId>com.example</groupId>
<artifactId>foo</artifactId>
<version>1.0</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>com.example</groupId>
<artifactId>bar</artifactId>
<version>1.0</version>
<scope>runtime</scope>
</dependency>
Note: api was converted to compile scope and implementation - to runtime scope.
That allows for consumers of this library to avoid having runtime dependencies in their compile classpath.
Now there is good explanation in the documentation
The api configuration should be used to declare dependencies which are
exported by the library API, whereas the implementation configuration
should be used to declare dependencies which are internal to the
component.
I'm trying to figure out what is the difference between api and implementation configuration while building my dependencies.
In the documentation, it says that implementation has better build time, but, seeing this comment in a similar question I got to wonder if is it true.
Since I'm no expert in Gradle, I hope someone can help. I've read the documentation already but I was wondering about an easy-to-understand explanation.
Gradle compile keyword was deprecated in favor of the api and implementation keywords to configure dependencies.
Using api is the equivalent of using the deprecated compile, so if you replace all compile with api everything will works as always.
To understand the implementation keyword consider the following example.
EXAMPLE
Suppose you have a library called MyLibrary that internally uses another library called InternalLibrary. Something like this:
// 'InternalLibrary' module
public class InternalLibrary {
public static String giveMeAString(){
return "hello";
}
}
// 'MyLibrary' module
public class MyLibrary {
public String myString(){
return InternalLibrary.giveMeAString();
}
}
Suppose the MyLibrary build.gradle uses api configuration in dependencies{} like this:
dependencies {
api(project(":InternalLibrary"))
}
You want to use MyLibrary in your code so in your app's build.gradle you add this dependency:
dependencies {
implementation(project(":MyLibrary"))
}
Using the api configuration (or deprecated compile) you can access InternalLibrary in your application code:
// Access 'MyLibrary' (granted)
MyLibrary myLib = new MyLibrary();
System.out.println(myLib.myString());
// Can ALSO access the internal library too (but you shouldn't)
System.out.println(InternalLibrary.giveMeAString());
In this way the module MyLibrary is potentially "leaking" the internal implementation of something. You shouldn't (be able to) use that because it's not directly imported by you.
The implementation configuration was introduced to prevent this.
So now if you use implementation instead of api in MyLibrary:
dependencies {
implementation(project(":InternalLibrary"))
}
you won't be able to call InternalLibrary.giveMeAString() in your app code anymore.
This sort of boxing strategy allows Android Gradle plugin to know that if you edit something in InternalLibrary, it must only trigger the recompilation of MyLibrary and not the recompilation of your entire app, because you don't have access to InternalLibrary.
When you have a lot of nested dependencies this mechanism can speed up the build a lot. (Watch the video linked at the end for a full understanding of this)
CONCLUSIONS
When you switch to the new Android Gradle plugin 3.X.X, you should replace all your compile with the implementation keyword *(1). Then try to compile and test your app. If everything it's ok leave the code as is, if you have problems you probably have something wrong with your dependencies or you used something that now is private and not more accessible. *Suggestion by Android Gradle plugin engineer Jerome Dochez (1))
If you are a library mantainer you should use api for every dependency which is needed for the public API of your library, while use implementation for test dependencies or dependencies which must not be used by the final users.
Useful article Showcasing the difference between implementation and api
REFERENCES
(This is the same video splitted up for time saving)
Google I/O 2017 - How speed up Gradle builds (FULL VIDEO)
Google I/O 2017 - How speed up Gradle builds (NEW GRADLE PLUGIN 3.0.0 PART ONLY)
Google I/O 2017 - How speed up Gradle builds (reference to 1*)
Android documentation
I like to think about an api dependency as public (seen by other modules) while implementation dependency as private (only seen by this module).
Note, that unlike public/private variables and methods, api/implementation dependencies are not enforced by the runtime. This is merely a build-time optimization, that allows Gradle to know which modules it needs to recompile when one of the dependencies changes its API.
Consider you have app module which uses lib1 as a library and lib1 uses lib2 as a library. Something like this: app -> lib1 -> lib2.
Now when using api lib2 in lib1, then app can see lib2 code when using: api lib1 or implementation lib1 in the app module.
BUT when using implementation lib2 in lib1, then app can not see the lib2 code.
Please refer the link: Android Studio Dependency Configuration available at android developers' official site.
Inside the dependencies block, you can declare a library dependency using one of several different dependency configurations (such as implementation shown above). Each dependency configuration provides Gradle with different instructions about how to use the dependency.
implementation
Gradle adds the dependency to the compile classpath and packages the dependency to the build output. However, when your module configures an implementation dependency, it's letting Gradle know that you do not want the module to leak the dependency to other modules at compile time. That is, the dependency is available to other modules only at runtime.
Using this dependency configuration instead of api or compile (deprecated) can result in significant build time improvements because it reduces the number of modules that the build system needs to recompile. For example, if an implementation dependency changes its API, Gradle recompiles only that dependency and the modules that directly depend on it. Most app and test modules should use this configuration.
api
Gradle adds the dependency to the compile classpath and build output. When a module includes an api dependency, it's letting Gradle know that the module wants to transitively export that dependency to other modules, so that it's available to them at both runtime and compile time.
This configuration behaves just like compile (which is now deprecated), but you should use it with caution and only with dependencies that you need to transitively export to other upstream consumers. That's because, if an api dependency changes its external API, Gradle recompiles all modules that have access to that dependency at compile time. So, having a large number of api dependencies can significantly increase build time. Unless you want to expose a dependency's API to a separate module, library modules should instead use implementation dependencies.
From gradle documentation:
Let’s have a look at a very simple build script for a JVM-based project.
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.+'
}
implementation
The dependencies required to compile the production source of the project which are not part of the API exposed by the project. For example the project uses Hibernate for its internal persistence layer implementation.
api
The dependencies required to compile the production source of the project which are part of the API exposed by the project. For example the project uses Guava and exposes public interfaces with Guava classes in their method signatures.
Answers from #matpag and #dev-bmax are clear enough to make people understand different usages between implementation and api. I just want to make an extra explaination from another angle, hopes to help for peoples that have the same question.
I created two projects for testing :
project A as a java library project named 'frameworks-web-gradle-plugin' depends on 'org.springframework.boot:spring-boot-gradle-plugin:1.5.20.RELEASE'
project B depends on project A by implementation 'com.example.frameworks.gradle:frameworks-web-gradle-plugin:0.0.1-SNAPSHOT'
The dependencies hierarchy descripted above looks like:
[project-b] -> [project-a] -> [spring-boot-gradle-plugin]
Then I tested following scenarios:
Make project A depends on 'org.springframework.boot:spring-boot-gradle-plugin:1.5.20.RELEASE' by implementation .
Run gradle dependencies command in a terminal in poject B root dir，with following screenshot of output we can see that 'spring-boot-gradle-plugin' appears in runtimeClasspath dependencies tree, but not in compileClasspath's, I think that's exactly why we can't make use of library that declared using implementation, it just won't through compilation.
Make project A depends on 'org.springframework.boot:spring-boot-gradle-plugin:1.5.20.RELEASE' by api
Run gradle dependencies command in a terminal in poject B root dir again.
Now 'spring-boot-gradle-plugin' appears both in compileClasspath and runtimeClasspath dependencies tree.
A significant difference I noticed is that the dependency in producer/library project declared in implementation way won't appear in compileClasspath of consumer projects, so that we can't make use of corresponding lib in the consumer projects.
One more technical note regarding api vs implementation. Suppose you have following dependencies:
dependencies {
api "com.example:foo:1.0"
implementation "com.example:bar:1.0"
}
If you install a generated jar file in your local Maven repository (with help of maven-publish plugin) you will see that generated pom.xml file will look like this:
<dependency>
<groupId>com.example</groupId>
<artifactId>foo</artifactId>
<version>1.0</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>com.example</groupId>
<artifactId>bar</artifactId>
<version>1.0</version>
<scope>runtime</scope>
</dependency>
Note: api was converted to compile scope and implementation - to runtime scope.
That allows for consumers of this library to avoid having runtime dependencies in their compile classpath.
Now there is good explanation in the documentation
The api configuration should be used to declare dependencies which are
exported by the library API, whereas the implementation configuration
should be used to declare dependencies which are internal to the
component.
Gradle dependencies difference between.
compile
apk project
compile project
provided project
implementation
My questions are
What's the difference between compile ,apk project, compile project,provided project here?
There's two separate things to discuss here: Dependency Configurations and Dependency Sources.
Dependency Configurations
Configurations help define the transitivity of a dependency, which in turn removes the pain of having to discover and specify the libraries your own project/library requires, including them automatically. This notion of configurations in gradle is very similar to that of Maven's scopes:
compile: Compile dependencies are available in all classpaths of a project. Furthermore, those dependencies are propagated to dependent projects. A compile-time dependency is generally required at runtime.
apk: Defines a runtime dependency. A dependency with this scope will not be required at compile time, but it will be for execution. This means that you can save time while compiling and still have the dependency available when your project actually runs. This is a good example of when to use an apk dependency.
provided: It means that this dependency is available on the runtime environment. As a consequence, this scope is only available on the compilation and test classpath, and is not transitive. It is not supported on Android projects, though you can workaround it by defining your own configuration as discussed here.
There are more configurations that you can encounter on Android, such as testCompile, which allows you to specify a compile-time dependency that will only be used for testing, say you want to use junit in your tests, then you would do as follows:
testCompile 'junit:junit:4.12'
Dependency Source
Once you understand the configurations available for you, you need to specify an actual dependency. Dependencies might be internal or external, you may rely on another library you are working on, as well as on publicly available libraries. Here's where the project keyword comes in, allowing you to specify a dependency to an internal module or library. By defining a dependency as compile project, you are adding that module or library as a transitive dependency to your project.
Assume you have a project messages with three modules (producer, consumer and shared), the project structure would look as follows:
messages/
build.gradle
settings.gradle
consumer/
build.gradle
producer/
build.gradle
shared/
build.gradle
Now assume that both consumer and producer store messages in json format and that you want to use google-gson for that purpose. Assume that both projects have some common source code that they depend on, your shared module. consumer's build.gradle could then define the following dependencies:
dependencies {
// Internal dependency to project shared
compile project (':shared')
// External dependency to publicly available library,
// through public repositories such as jcenter() or mavencentral()
compile 'com.google.code.gson:gson:1.7.2'
}
To sum up, it is the combination of both configurations and sources that enables you to declare dependencies as compile, compile project, apk project and more!