I'm attempting to create an Android library myLibrary which will be delivered as an AAR to others in my company.
Many of the dependencies of myLibrary are APIs for communicating with the phone's hardware (barcode scanning, etc.). It's a requirement of one of these third party libraries to add it to your project with compileOnly instead of implementation, as the provided JAR file contains the stub implementation; the full implementation is provided by the device.
In my library module's build.gradle:
implementation files('libs/Vendor1.jar')
implementation files('libs/Vendor2.jar')
compileOnly files('libs/Vendor3.jar')
In this example, Vendor3's API to the device hardware is compileOnly.
My use case is that I want consumers of myLibrary to be able to extend the functionality I provide. Meaning, if I have a MyCoolVendor3Class and they want to extend it and customize some aspect of it, they won't be able to touch the Vendor3 API.
How can I provide myLibrary's dependent compileOnly API to consumers of the library without using implementation? Or will they need to get their hands on the Vendor3 Jar on their end to make this approach feasible?
Thanks.
Note: You can't use the compileOnly configuration with AAR dependencies.
Ref from: https://developer.android.com/studio/build/dependencies
I think it may be caused by the resources packed in the jar, it's ok to compileOnly the classes files, but what about the resources
Related
LibA is added inside App module using 'api' and LibB is added inside LibA using 'implementation'.
I am not able to access LibB inside App, it gives compilation error.
Can anyone explain what is happening here ?, am i missing anything or misunderstanding concept of 'api','implementation' ?.
The explanation can be found in the official documentation of the Java Library plugin, especially in the API and Implementation separation chapter:
The plugin exposes two configurations that can be used to declare dependencies: api and implementation. 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.
The main idea with the APi configuration is to avoid internal dependencies of the library module to leak into the library consummer classpath.
In your case, LibB is considered as internal dependency to LibA, as it's defined in the implementation configuration, therefore you are not supposed to access LibB directly in your App module .
If you need to consume library LibB from App, then just declare a direct dependency from App to LibB, with either api or implementation configuration.
The api dependency is basically transitive in nature to its upstream projects only. So in your case, if you want LibB to be exposed to App, then you can have the dependencies like this -
App with implementation dependency to LibA and
LibA with api dependency to LibB
This will allow LibB to be exposed transitively to App
But, one should use api dependency cautiously and only when needed.
Is there some good reason to use api over implementation in gradle when using your own library ? Is there any good reason to use it in some other situation ? I could not find answer in other questions about it. Or its just when you have to because of transition from using of compile ?
Besides your own library one the most relevant situation where I see it useful is when you have a multi-module project. In this kind of projects you most likely end up having modules that have dependencies of other modules and since you might want that gradle recompiles your modules dependencies if there is any change in those modules api is the answer.
api is the equivalent of compile, and implementation was added to improve gradle builds by not having to recompile every dependency but only the ones that needs to be recompiled.
The following articles are a good source of information about it, and they are very concise.
Implementation vs API dependency
Implementation Vs Api in Android Gradle plugin 3.0
Update:
From gradle docs:
The api bucket is used to declare dependencies that should
transitively be visible by downstream consumers when they are
compiled. The implementation bucket is used to declare dependencies
which should not leak into the compile classpath of consumers (because
they are purely internal details).
This means that if your own library wants to expose any dependency to its consumers you should use api. Any dependencies with api in your own library will be part of the compile classpath of the app consuming your own library. With implementation you wont expose the dependencies you are using in your own library to the app that is consuming it.
You can see this being applied in well known libraries like ButterKnife for instance. Where the "core" butterknife module, which is the one the consumer app adds as dependency, is exposing butterknife-annotations to the consumer through api project(':butterknife-annotations'). And this is what allows the consumer use the binding annotations from butterknife such as #BindView.
If the butterknife-annotations were added in butterknife with implementation instead of api, the consumer app will not be able to use those binding annotations. Because the butterknife-annotations will no longer be part of the compile classpath of the consumer app.
I know the difference between the two as discussed here.
As Android developer,
Why I should care about this?
In gradle, why should I use compileOnly vs implementation/api?
Why I should care about this?
To make your apps build but not ship with unnecessary stuff.
In gradle, why should I use compileOnly vs implementation/api?
The documentation for compileOnly gives one use case as an example:
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).
source
For example, consider a push messaging library that supports both Firebase FCM and Amazon ADM but does not require either. It would unnecessarily bloat apps if it would ship with both as transitive dependencies. With compileOnly the library can still be built. Developers using the library can select which dependencies to actually use.
Another example could be compile-time annotations that do not need to ship with the application.
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.