I've heard that using incremental dependency in Gradle is bad.
like this
dependencies {
compile fileTree(include: ['*.jar'], dir: 'libs')
compile 'com.android.support:appcompat-v7:22.+'
}
Is that so? Why?
There are two primary issues with using wildcard dependency versions:
First, you lose control over when you update. This means that you could potentially get a bad version of the library, or pull down a good version that introduces breaking changes before you are ready to address those changes.
Second, your builds are no longer reproducible. If in a few months you decide you need to build the exact version of the app that you had on May 28th, 2015, you will find that task much more difficult because you don't know what the precise version of the library you were using on that date. If you simply check out the code from that date, you are receiving whatever version is currently the latest instead of what the latest version was on that date.
Related
maybe it is because I don't understand it but choosing the right version of dependency libraries to specify in the build.gradle file is a big mess.
How do we know which versions to choose and which versions are compatible with other versions?
Now that I have discovered maven.google.com I think I can see all the versions available to me.
Most recently I am dealing with Firebase libraries. I need both messaging and core. At this writing messaging is at 17.3.4 and core is at 16.0.4. But if I build with those versions I get an error that says cannot access zzbfm - what ever that is.
I finally got a clean compile with the following but this combination was achieved by trial and error taking an hour or so...
implementation 'com.google.android.gms:play-services-maps:15.0.1'
implementation 'com.google.android.gms:play-services-gcm:15.0.1'
implementation 'com.google.firebase:firebase-messaging:17.3.2'
implementation 'com.google.firebase:firebase-core:16.0.3'
It would be nice if the answer were "always use the latest version" but that certainly isn't the answer.
What am I missing here?
You are not really missing anything. Version compatibility is mainly a thing of trial and error. What you can do:
Only add the artifacts you really use in your code. Don't add transitive dependencies.
Look at potential conflicts in the transitive dependencies and make trials, starting with the newer version.
Generally: Try to use as few dependencies as possible, this reduces the hassle.
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 .
Android Studio 2.2.2
Compile SDK Android 7.1.1
Build Tools: 25.0.0
Gradle version: 2.14.1
Min SDK: 19
Target SDK: 25
I encountered an issue with jackson-dataformat-xml-2.8.5.jar when attempting to execute this:
JacksonXmlModule module = new JacksonXmlModule();
ObjectMapper xmlMapper = new XmlMapper(); //This line
throws the following exception
E/AndroidRuntime: FATAL EXCEPTION: Thread-418
Process: cb.myAppName, PID: 29744
java.lang.VerifyError: com/fasterxml/jackson/dataformat/xml/XmlFactory
at com.fasterxml.jackson.dataformat.xml.XmlMapper.<init>(XmlMapper.java:49)
at cb.myAppName.Core.GenerateReturnXMLFile(Core.java:863)
at cb.myAppName.RouteScreenActivity$4.run(RouteScreenActivity.java:305)
at java.lang.Thread.run(Thread.java:841)
From what I researched, it has to do with a binary incompatibility that was introduced in Jackson 1.3. As stated by Tatu Saloranta in his old blog which sadly is no longer online.
I have always valued compatibility quite highly, at least for any "non
beta" release (1.0 and above). As a result, the idea has been that any
1.x release would be simple plug-and-play over previous one. This does work for patch releases; but it turns out that not all minor releases
have worked this way. For example, versions 1.2 and 1.3 have some
unexpected incompatibilities.
Problem is this: although most commonly binary compatibility is a
harder goal than source compatibility -- that is, if you break source
compatibility, you are almost guaranteed to break binary compatibility
-- it is not strictly so. Specifically, it is quite possible to make certain changes that are source compatible, but that are NOT binary
compatible.
Specific case in point is that of changing a method that returns
nothing ("void method") into method that returns something does not
break compilation. But it does actually break binary compatibility.
UGH.
And this is exactly what happened when I decided that it would be nice
to make ObjectMapper follow "fluent" pattern, to allow for chaining of
configuration method calls. This would be nice, if it was not this
"hidden" API change...
Not quite sure how to correct this though since i'm fairly new to android development.
I already made sure to use same version of Jackson across the board as you can see in my list of dependencies from the app/build.gradle, is there something else I may be missing?
dependencies {
compile fileTree(include: ['*.jar'], exclude: ['com.symbol.emdk.jar'], dir: 'libs')
compile files('../libs/json-20151123.jar')
provided files('../libs/com.symbol.emdk.jar')
compile files('../libs/slf4j-api-1.7.6.jar')
compile files('../libs/logback-android-1.1.1-4.jar')
compile files('../libs/sun.misc.BASE64Decoder.jar')
compile files('../libs/ZSDK_ANDROID_API.jar')
compile 'com.android.support:appcompat-v7:22.2.1'
compile 'com.android.support:support-v7:22.2.0'
compile 'com.google.code.ksoap2-android:ksoap2-android:3.6.0'
compile 'com.google.code.gson:gson:2.4'
compile 'org.apache.directory.studio:org.apache.commons.io:2.4'
compile 'org.joda:joda-money:0.11'
compile 'org.apache.directory.studio:org.apache.commons.lang:2.6'
compile 'com.google.android.gms:play-services-appindexing:9.8.0'
compile 'org.greenrobot:eventbus:3.0.0'
compile 'com.fasterxml.jackson.core:jackson-core:2.8.5'
compile 'com.fasterxml.jackson.core:jackson-databind:2.8.5'
compile 'com.fasterxml.jackson.datatype:jackson-datatype-joda:2.8.5'
compile 'com.fasterxml.jackson.dataformat:jackson-dataformat-xml:2.8.5'
compile 'com.github.gcacace:signature-pad:1.2.0'
}
As per the official FasterXML Jackson github page, the extension i'm using should be supported...
XML: supports XML; provides both streaming and databind
implementations. Similar to JAXB' "code-first" mode (no support for
"XML Schema first", but can use JAXB beans)
https://github.com/FasterXML/jackson-dataformat-xml
This issue was also reported on the project's github page but no real solution was reached. -- github.com/FasterXML/jackson-dataformat-xml/issues/116
UPDATE: I used jarjar on the following dependencies:
compile files('../libs/cb-joda-time-2.9.6.jar')
compile files('../libs/cb-joda-money-0.12.jar')
compile files('../libs/cb-jackson-dataformat-xml-2.8.5.jar')
compile files('../libs/cb-jackson-datatype-joda-2.8.5.jar')
compile files('../libs/cb-java-json-0.13.0.jar')
compile files('../libs/cb-json-20160212.jar')
Also upgraded every single dependency to latest version as well as my appcompat and support api.
The error continues -
java.lang.VerifyError: cb/com/fasterxml/jackson/dataformat/xml/XmlFactory
at cb.com.fasterxml.jackson.dataformat.xml.XmlMapper.<init>(XmlMapper.java:49)
Hopefully someone can shine some light on this, not sure what is causing this...
After some research and tips from user aha I was able to further identify how to correct this. I haven't had time to test it since I ended up taking a different route and using SimpleXML library instead which works great for what I needed to do.
I will update this answer with more details when I do get around to testing it but here are some ways to attempt and correct this:
Include Stax as a dependency: github.com/FasterXML/jackson-dataformat-xml#android-quirks
Execute gradle dependencies. Gradle will then display the actual dependency tree that it has used to compile and package your app. The generated dependency tree might be different than the dependencies you'd declared, e.g. because of transitive dependencies. -Thanks aha
This is the original issue at github: github.com/FasterXML/jackson-dataformat-xml/issues/116
Is there an easy way to get gradle to update dependencies to their latest available version?
For build reproducibility all my dependencies are defined with a version number like this in my build.gradle file:
dependencies {
compile 'namespace:package1:version'
compile 'namespace:package2:version'
compile 'namespace:package3:version'
}
Periodically I want to update every package to their latest version. Typically this is the first thing I do for a new sprint after making a release.
It's a real pain doing this manually for each package. Ideally I would like a command to update the build.gradle file for me but at the very least a command that prints out which package needs an update and what the latest version number is.
In ruby land I would run bundler update.
This is all I've been able to come up with. I will happily accept another answer if there is a less manual method of doing this.
In Android studio I replace every dependency version with a plus example: compile 'namespace:package1:+'
Sync or build the project which will cause all the dependencies to be resolved to their latest version.
In Android Studio place the cursor on each dependency line in build.gradle and press alt+enter a menu pops up and you can select Replace with specific version
Add to build.gradle:
plugins {
id 'com.github.ben-manes.versions' version '0.17.0'
}
Then you can do gradle dependencyUpdates to get a report of new versions. Unlike the eponymous Maven plugin, there doesn't seem to be a way of automatically updating the build.gradle yet.
More documentation: https://github.com/ben-manes/gradle-versions-plugin
It is not a really good practice as libraries can include changes that may break your code.
A common "tolerated" syntax for
compile 'namespace:package:major_version.minor_version.revision'
would be like
compile 'namespace:package:1.0.+'
considering revision is used by the library authors as bug fixes and improvements updates
Note:
I just did that and you could do
compile 'namespace:package:+'
Edit:
A Proof Of Concept of my latest comment you may want to test.
This was made in 5 minutes, so don't expect it to be perfect nor flexible.
I suffer from it, too. And the best way to check dependencies, even manually, is to go through Project Structure and search for the dependency name and see if there is a newer version.
The problem that this query only checks for the dependencies present in the Maven repository. At least it already goes for Google's.
Note: If you choose to add the dependency with the new version, this will add a duplicity in the your App Gradle, so be sure to delete the old dependency row.
###################
Another possible quick fix is through the command line:
./gradlew app:dependencies
This will generate an output like the one below. Note that the asterisk points to a possible new existing version.
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.