How would I translate those to implementation or api?
Fx. what should I replace those with?
compile project(':jabraServiceApi')
compile files('libs/samsung-digital-health-healthdata-1.2.1.jar')
Maybe compile project and compile files are still supported and should stay as they are?
Gradle 3.4 introduced new Java Library plugin configurations configurations that allow you to control whether a dependency is published to the compile and runtime classpaths of projects that consume that library. The Android plugin is adopting these new dependency configurations, and migrating large projects to use them can drastically reduce build times. The following table helps you understand which configurations you should use.
I already give the answer here please check compile configuration 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.
This question already has answers here:
Gradle Implementation vs API configuration
(8 answers)
Closed 5 years ago.
I recently updated Android studio to version 3.0. Now in build.gradle all the dependencies are added using the implementation keyword instead of old compile keyword.
dependencies {
implementation fileTree(include: ['*.jar'], dir: 'libs')
implementation 'com.android.support:appcompat-v7:25.4.0'
}
But the compile keyword still works. What is the difference between compile and Implementation?
compile has been deprecated so use for libraries use api or implementation
Gradle 3.4 introduced new Java Library plugin configurations that allow you to control whether a dependency is published to the compile and runtime classpaths of projects that consume that library. The Android plugin is adopting these new dependency configurations, and migrating large projects to use them can drastically reduce build times.
implementation
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
Read more from new dependency configurations
I'm using Android Studio 3.0 Preview to start new Kotlin project. As I try to add dependencies in build.gradle I saw implementation scope instead of usual compile.
androidTestImplementation('com.android.support.test.espresso:espresso-core:2.2.2', {
exclude group: 'com.android.support', module: 'support-annotations'
})
implementation 'com.android.support:appcompat-v7:25.3.1'
testImplementation 'junit:junit:4.12'
There's also androidTestImplementation and testImplementation scope.
In the end, I add compile to add third party dependencies and it works.
compile 'io.reactivex.rxjava2:rxandroid:2.0.1'
So my questions are..
What is implementation, androidTestImplementation, and testImplementation scope?
Is it any different than compile, testCompile, and androidTestCompile?
Which one I should use for my Kotlin project?
Edit:
My bad, this question is not Kotlin specific. It's the new Android Gradle Plugin configuration.
This is not specific to Kotlin, but has to do with the new Gradle plugin for Android.
compile, provided and apk are now deprecated.
Use implementation or api instead of compile, compileOnly instead of provided, and runtimeOnly instead of apk.
The reason for this is to speed up multi-module builds. Given module A which depends on module B which in turn depends on module C, a change in module C would trigger a recompile of module A as well. If A does not use C directly, there is no need for A to recompile when C changes.
The implementation configuration ensures exactly this: if you specify implementation project(':C') in B, you cannot access C from A and you avoid building unnecessary modules. In a large multi-module project this can save a lot of time.
See Migrate to the new Gradle plugin for more information.
Earlier version of gradle v3.0.0-alpha1 used to use compile but it has been deprecated now on.
Why?
Dependencies appearing in the compile configurations will be transitively exposed to consumers of the library, and as such will appear on the compile classpath of consumers. Dependencies found in the implementation configuration will, on the other hand, not be exposed to consumers, and therefore not leak into the consumers' compile classpath.
Let's take an example to understand this. Let's say, I created a Library_Image_Upload that supports Image uploading to the server. I used Library_Network lib in Library_Image_Upload that supports all the network operations. My library only makes use of image uploads and provide a convenient way of uploading images. Now as i used Library_Network lib in my Library_Image_Upload project, everyone using this lib will have functionality of Image Uploading along with all network operations that someone may also use(Important). Later on i thought there is a better alternative to Library_Network as Library_Magic_Image and used it. So all the API functions exposed by Library_Network are gone and whoever is using those functions has broken build.
implementation comes with several benefits:
Dependencies do not leak into the compile classpath of consumers anymore, so you will never accidently depend on a transitive dependency
Faster compilation thanks to reduced classpath size
Less recompilations when implementation dependencies change: consumers would not need to be recompiled
Cleaner publishing: when used in conjunction with the new maven-publish plugin, Java libraries produce POM files that distinguish exactly between what is required to compile against the library and what is required to use the library at runtime (in other words, don't mix what is needed to compile the library itself and what is needed to compile against the library).
To learn more read The Java Library Plugin
So i think you have the answer of all three questions.
I hope it helps.
I know that in order to get the latest version of Android/Google libraries, I can always go to the Android SDK Manager and update the Android Support Repository / Google Repository.
How about to update the other dependency libraries, such as the "commons-net:commons-net:20030805.205232" from Apache collection libraries? Since it is able to add these libraries from a Module's dependencies, I assume there should be a way to update it within the Android Studio IDE, but so far all the solutions I found is to download the specific .jar and put in the libs directory.
Just curious if anyone know there is a way to update these libraries from within the Android Studio IDE like the Android/Google dependencies.
Android Studio & IntelliJ have a dependency setting window themselves. Though, it does not have a "update" feature as the SDK Manager does. Reason being: Updating a library can cause bugs, errors, or complete crashes in your app.
so far all the solutions I found is to download the specific .jar and put in the libs directory
Not sure where you read that... Remote Gradle dependencies are preferred in most cases.
such as the "commons-net:commons-net:20030805.205232"
Go find what you want in Maven Central, find the most recent version, click the "Gradle" tab, the copy that into your build.gradle section.
There is no automated process for this, as far as I know, though you should be able to auto-complete version numbers via the IDE while you type it out.
When you create a project under Android Studio, it generates for your gradle files which let you use dependencies. Gradle is like maven, you can find lot of documents on google.
Under "Project" tab -> Gradle Scripts -> build.gradle (Module app), you'll find something like this :
dependencies {
compile fileTree(include: ['*.jar'], dir: 'libs')
testCompile 'junit:junit:4.12'
compile 'com.android.support:appcompat-v7:23.4.0'
compile 'com.android.support:design:23.4.0'
compile 'com.journeyapps:zxing-android-embedded:3.0.2#aar'
compile 'com.android.support:support-v13:23.4.0'
compile 'com.google.zxing:core:3.2.0'
compile 'com.android.support:support-v4:23.4.0'}
So you just have to put your dependencies and gradle will download them for you.
More here.
One of the advantages of using Gradle in Android Studio is that it helps in dependency management. So if I have used a particular version of a library in my build.gradle file,
then how will I force it to update the dependency version once the higher version is available?
Some of the dependencies in my build.gradle are specified as
dependencies {
compile project(':facebookSDK')
compile files('libs/picasso-2.1.1.jar')
compile files('libs/crouton-1.8.1.jar')
}
One of the advantages of using Gradle in Android Studio is that it helps in dependency management.
Not the way that you are using it.
So if i have used a particular version of a library in my build.gradle file, then how will i force it to update the dependency version once the higher version is available?
In your case, you would download the new JARs, put them in libs/, and update your build.gradle to match.
The preferred approach is for you to delete those JARs and replace your two compile files statements with ones that pull down the dependencies from Maven Central or another artifact repository. You can find the proper statements for popular open source libraries like those via the Gradle, please site.
In your case, you would use:
compile 'com.squareup.picasso:picasso:2.3.3'
compile 'de.keyboardsurfer.android.widget:crouton:1.8.5'
These will require you to also have a repositories closure as a peer to your dependencies closure:
repositories {
mavenCentral()
}
This may already exist.
These compile statements still pin you to a specific version of those libraries, but moving to a new version would be a simple matter of updating the compile statement, and Gradle will pull down the new dependency on your next build.
If you want, you could replace part of the version number with a wildcard (e.g., 2.3.+). This will cause Gradle to automatically update to new patchlevels of the library, in this case. Some developers do not approve of this approach, as while it is convenient, it does reduce your ability to be able to reproduce a build (e.g., you need to recompile some older branch of your code, and now you don't know what version of the artifact you were using back then).
As you are compiling files from your local project, I don't think you can automatically compile a new individual jar version if available. What you can do instead of compiling individual files is:
compile fileTree(dir: 'libs', include: '*.jar')
This will compile all jars in the libs directory so you will always have the latest version.
Both the libraries you are using are available to be compiled as dependencies from mavencentral.
compile 'de.keyboardsurfer.android.widget:crouton:1.8.5'
compile 'com.squareup.picasso:picasso:2.3.3'
If you want to ensure you are getting the latest versions is you use a plus in place of the version number. It's up to you how open you want to be with this.. so
compile 'de.keyboardsurfer.android.widget:crouton:1.+'
compile 'com.squareup.picasso:picasso:2.+'
will give you the latest version under the 1. or 2. versioning cycles...
If you want, you could replace part of the version number with a wildcard (e.g., 2.3.+).
This will cause Gradle to automatically update to new patch-levels of the library, in this case.
Some developers do not approve of this approach, as while it is convenient it does reduce your ability to be able to reproduce a build (e.g., you need to recompile some older branch of your code, and now you don't know what version of the artifact you were using back then).
I have found Gradle, please to be my answer here.
Easily get the latest android library gradle compile statement.