What I have
I have two different modules in my android project:
app: This is the main app android module, where is located almost all the code of the app.
core: This is another module where I would like to specify all the base code that will be used in the app module, like BaseFragment, BaseViewModel, or interfaces that I would like to implement in the app module.
In the core build.gradle file, I have all of these dependencies:
//Moshi
implementation "com.squareup.moshi:moshi-kotlin:$moshi_version"
//Retrofit
implementation "com.squareup.retrofit2:retrofit:$retrofit_version"
implementation "com.squareup.retrofit2:converter-moshi:$moshi_converter_version"
//okhttp
implementation "com.squareup.okhttp3:okhttp:$okhttp3_version"
implementation "com.squareup.okhttp3:logging-interceptor:$okhttp_loggin_interceptor"
//Koin
implementation "io.insert-koin:koin-android:$koin_version"
implementation "io.insert-koin:koin-androidx-viewmodel:$koin_viewmodel_version"
All of these dependencies I would like not to be declared also in the app build.gradle file.
I am reading some blogs and the Gradle official documentation but I am not able to successfully achieve this.
What I want
I want to "inherit" all the dependencies just from the core module gradle file
The structure of the project should be something like this:
core
|_build.gradle (common dependencies)
|_app
|_build.gradle (just specific dependencies)
What I have tried
I have read that this is possible implementing the core project as follows (in the app build.gradle file):
dependencies {
implementation project (":core")
......
}
But I have some classes in the app module that uses core classes` that could not find. For example:
import com.example.core.presentation.base.BaseViewModel
The error says that could not resolve the reference like it not exists.
Some ideas?
Thanks in advance!!
I took a look at your GitHub :-)
I think this is the example you are trying
https://github.com/smoralb/BaseApplication/tree/feature/core?
What you describe in your question should work, so I took a look.
The problem is in your core modules build.gradle line 1
(https://github.com/smoralb/BaseApplication/blob/feature/core/core/build.gradle#L1)
You have this:
apply plugin: 'com.android.application'
When you should have this:
apply plugin: 'com.android.library'
then using
implementation project (":core")
inside your app module, will give you access to the classes from core in app.
Simplest way to achieve this is with a convention plugin. Don't let the plugin part scare you too much, it's a bit of setup but not that complex.
You get 3 options there:
put the plugins in a buildSrc dir and have gradle pick it up automatically
put the plugin in a specific module and include the build (composite build)
put the plugin in a specific module, release it and load it as a binary dependency plugin.
more info can be found here:
https://docs.gradle.org/current/samples/sample_convention_plugins.html
alternatively, if you just want to maintain the versions in 1 place but don't mind putting the dependencies in both build gradle files a plaform might be even easier: https://docs.gradle.org/current/userguide/java_platform_plugin.html
Related
I had a usecase so I have added retrofit library to use it locally in libs folder
You can see the package structure and error in the image below when trying to import Timber android libary.
In the app/build.gradle file, I have added dependency:
implementation 'com.jakewharton.timber:timber:4.7.1'
In the libs/retrofit/build.gradle file, there also I added dependency:
// I also tried using api instead of implementation
implementation 'com.jakewharton.timber:timber:4.7.1'
Now, I synced, did invalidate cache and restart, clean, rebuild project.
Then tried to use Timber.d("some log") call in one of the files in libs/retrofit directory.
It resulted in error:
Add library: 'Gradle com.jakewharton.timber:timber:4.7.1#aar' to Classpath
Note, the Timber.d("other log") works fine in one of the files in app directory, example app/MainActivity.kt
What I am doing wrong?
Also, to note Retrofit code works perfectly fine in app module. The issue is using a Timber logging library is not working in any of the modules in libs
In my opinion, the answer lies in the question asked in this thread itself.
What happened, is that when I went through this situation myself, I saw this thread in the Google Search results.
After adding the dependency, for example:-
implementation 'com.jakewharton.timber:timber:4.7.1'
and thereafter syncing, I saw that it was merely a page refresh issue.
That is I switched to another source file which was opened in another tab and came back to this in which the following code was issued (the place of the aforesaid error):-
Timber.tag(...).e(...)
Timber usage.
Timber is packaged as an AAR file, that means it can only be used in android modules of your project.
The solution would be to convert your kotlin module to an android module by applying the plugins below in your build.gradle file of that module
apply plugin: 'com.android.library'
apply plugin: 'kotlin-android'
I am very new to both the Android and JVM platforms. Using Android Studio, I would like to create an Android app and put most of my business logic in a library. I would also like to just use Kotlin, no Java.
When I go to File > New Module, the options listed are
Phone & Tablet module
Android Library
Instant App
Feature Module
Android Wear Module
Android TV Module
Android Things Module
Import Gradle Project
Import Eclipse ADT Project
Import .JAR/.AAR Package
Java Library
I can create a Kotlin-based library with the Android Library option, but this also includes a lot of files for dealing with resources and controls.
I just want a pure Kotlin library. What is the easiest way to create one?
Can I delete a portion of an Android Library?
Can I change some settings in a Java Library?
Can I download a plugin that will just give me the option to create a Kotlin library?
I am still a bit confused the file organization in Java/Kotlin/Android projects.
You need a module with no Android dependencies and resources - this is what a Java library module does, so you start by creating one of those. From there, you just need to enable Kotlin inside this module.
The build.gradle file you get when you create your module is something like this:
apply plugin: 'java-library'
dependencies {
implementation fileTree(dir: 'libs', include: ['*.jar'])
}
You need to add the Kotlin plugin and standard library. If you don't have the mavenCentral repository added for all modules in your project yet, you need to add that as well:
apply plugin: 'java-library'
apply plugin: 'kotlin'
dependencies {
implementation fileTree(dir: 'libs', include: ['*.jar'])
implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk7:$kotlin_version"
}
repositories {
mavenCentral()
}
This is assuming that you have a kotlin_version declared in your project level build.gradle file, which is the usual way for Android projects, and I believe that's how Android Studio configures a project if you tick the checkbox to use Kotlin.
With those changes to your library's build.gradle, you can remove the automatically generated MyClass.java file from your library's source folder (/src/main/java/your/package/name), and start adding Kotlin files instead. If you'd like, you can also rename the /src/main/java folder to /src/main/kotlin. Or you can use both folders, this is entirely up to you.
Create Android studio project
After that create as many as module which are basically Android library
You can select the language of module (java/kotlin)
Extra
Upload your module to github and use jitpcak tool to make your module a library like this
Implementation 'com. My. Module:1.0'
And use your module any future project
I have an Android application. It contains two modules of app and pax-lib. app module depends on pax-lib module.
I have libs folder under pax-lib that contains some jar files. I have linked them in to gradle file of this module and use it across this module without any issue. This is how I have defined them:
dependencies {
...
// Local libs not in Maven Central
implementation files('libs/commons-io-1.3.2.jar')
implementation files('libs/commons-lang3-3.2.1.jar')
implementation files('libs/httpclientandroidlib-4.3.0.jar')
implementation files('libs/Kahuna_442.jar')
implementation files('libs/mapquest-android-sdk-1.0.5.jar')
...
}
This is how I defined this dependency in gradle file of app module.
dependencies {
implementation project(':pax-lib')
...
}
I am able to use all classes I have defined in pax-lib without any issue, however, I am not able to use .jar files that have defined in Gradle file of pax-lib module. My expectation is to be able to use them as I was in Gradle version below 3.0.
I must be able to copy/paste these jar files under app module but I want to make sure I am not doing something wrong first.
Use api rather than implementation
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.