How to use Mina with slf4j on Android Gradle build? - android

I am getting a DEX error (already added classes..) since mina is depending on slf4j-api, and slf4j-android is also carrying some of the slf4j-api internally.
Is there a way to solve this while still using gradle external (maven based) dependencies?
dependencies {
compile('org.apache.mina:mina-core:2.0.7')
compile 'org.slf4j:slf4j-android:1.6.1-RC1'
}

The answer seems to be the ability to exclude a module (sub-dependency):
dependencies {
compile('org.apache.mina:mina-core:2.0.7') {
exclude module: 'slf4j-api'
}
compile 'org.slf4j:slf4j-android:1.6.1-RC1'
}

Related

Issue With New Timber 4.1.2

While I was trying to use stetho-timber Library in my Android application I faced this problem:
Error:Module 'com.facebook.stetho:stetho-timber:1.3.1' depends on one
or more Android Libraries but is a jar
After inspecting in its codes I found that it uses timber v3.0.1!
Just add this to your build.gradle dependencies tag to exclude timber within the stetho library,
cause it is an old version and conflicts with new one:
dependencies {
compile ("com.facebook.stetho:stetho-timber:1.3.1") {
exclude group: "com.jakewharton.timber", module: "timber"
}
.
.
.

In an Android Gradle build, how to exclude dependencies from an included jar file?

In my Android project, I use a library that comes as a jar.
I include it in the dependencies section like so:
dependencies {
...
compile files('libs/thethirdpartylibrary.jar')
...
}
I also want to use the okhttp library, which I include like this:
compile ('com.squareup.okhttp:okhttp:2.7.5')
(This particular version of okhttp depends on okio 1.6.0.)
The problem is that the thirdparty jar library depends on okio v0.9.0 and what's worse, bundles it.
As a result, I get a dex conflict error at build time.
I was able to resolve this by manually removing okio from the jar file and this seems to work. But I'm wondering if there's a way to do this in gradle.
My question: Can I remove bundled, transitive ( <- I hope I'm using this word the right way) dependencies from an included jar during build-time with gradle?
Exclude the Group in the dependencies by using the below lines.
1.
configurations {
all*.exclude group: 'com.android.support', module: 'support-v4'
}
2.
dependencies {
compile 'com.android.support:support-v4:13.0.+'
compile ("com.xxx:xxx-commons:1.+") {
exclude group: 'junit', module: 'junit'
}
}
3.
configurations {
runtime.exclude group: "org.slf4j", module: "slf4j-log4j12"
}
Try this one.
For more detail
According to this discussion here https://groups.google.com/forum/#!topic/adt-dev/g1AiJM7PeVs, what you want to do is not possible.
The syntax suggested in the other answers is for "normal" Maven dependencies.

How to exclude module from all dependencies but leave explicit declaration Gradle

I am trying to solve the problem,
I have some dependencies declared in build.gradle file for my android app, but the problem is that a lot of these dependencies use the same compat library, in my case appcompat-v7.
It is possible to exclude this library for each dependency
compile ('com.github......'){
exclude group: 'com.android.support', module: 'appcompat-v7'
}
But I need to do this in for each dependency
Another way is to use such expression
configurations {
compile.exclude module: 'appcompat-v7'
}
This works, but even If declare this library explicitly it is ignored compile 'com.android.support:appcompat-v7:+'
All what I need it is to include this library only once for the whole app, because if compile without exclude it will show a lot of errors like has been already defined.
Maybe there is an easier way to get this working. I would be grateful for any help, thanks.
We use a provided configuration in gradle (so that when we gradle:eclipse, the packages are included, but are not included when compiled into a jar, as these jars are expected to be provided at runtime). This configuration looks like the following:
configurations {
provided {
dependencies.all {dep ->
configurations.default.exclude group: dep.group, module:dep.name
}
}
compile.extendsFrom provided
}
This allows us to include dependencies as follows:
dependencies {
compile("org.scala-lang:scala-library:2.11.7")
compile("org.scala-lang:scala-compiler:2.11.7")
provided("org.apache.spark:spark-core_2_11:2.0.0")
}
Try creating a configuration which contains all dependencies where you want to exclude appcompat-v7, and then extend compile from this new configuration.

Error compiling Android project after updating FindBugs to 3.0.1

After updating Findbugs plugin up to 3.0.1 version I can't compile multi module project in Android Studio. Also i use "com.google.code.findbugs:annotations:3.0.1" dependency for using FindBugs annotations (e.g. #SuppressFBWarnings).
I get following error while assembling project:
Execution failed for task ':presentation:packageAllDevelopDebugClassesForMultiDex'.
> java.util.zip.ZipException: duplicate entry: javax/annotation/CheckForNull.class
How can I fix it?
I resolved this issue, the cause was in adding to "com.google.code.findbugs:annotations:3.0.1" additional dependencies ('com.google.code.findbugs:jsr305:3.0.1' and 'net.jcip:jcip-annotations:1.0'). To fix it we need to exclude some transitive dependencies.
Replace:
dependencies {
compile "com.google.code.findbugs:annotations:3.0.1"
}
with
dependencies {
compile ("com.google.code.findbugs:annotations:3.0.1") {
exclude module: 'jsr305'
exclude module: 'jcip-annotations'
}
}
or with
dependencies {
compile ("com.google.code.findbugs:annotations:3.0.1") {
transitive = false
}
}
As suggested previously excluding module jsr305 worked for me, but I've used a different syntax due to importing a projest, not a module.
I was importing a library project present as indipendent project on my disk, so I had
compile project(path: ':shareLib')
To exclude module jsr305 I turned my code in
compile (project(path: ':shareLib')) {
exclude module: 'jsr305'
}

gradle dependency error in android

In the following build.gradle, I added the configuration section to avoid double inclusion of support libraries. Support libraries are used in the main project and in the dependent projects like facebook sdk. Without the configuration section, I get "UNEXPECTED TOP-LEVEL EXCEPTION". Adding that configuration makes the error go away and the app all works fine.
Now, I'm trying to add RecyclerView to my app and I get RecyclerView class not found while inflating the recyclerview (although it builds ok). If I remove the facebook SDK and configuration section, the recyclerview works just fine.
Question: What changes can I make to the build.gradle to make the facebook SDK work and RecyclerView work? In other words, why is the config section excluding v7 when it is only supposed to exclude v4?
dependencies {
compile fileTree(include: ['*.jar'], dir: 'libs')
compile 'com.android.support:support-v4:+'
compile 'com.android.support:support-v13:+'
compile 'com.android.support:cardview-v7:+'
compile 'com.android.support:recyclerview-v7:+'
compile 'com.google.android.gms:play-services:4.4.52'
compile project(':facebook-3.15')
compile project(':parse-1.5.1')
compile project(':viewpagerindicator-2.4.1')
}
configurations {
// to avoid double inclusion of support libraries
all*.exclude group: 'com.android.support', module: 'support-v4'
}
If you're having a dependency conflict with the v4 support library, you can just exclude it from one of the libraries via the gradle script:
compile ('com.android.support:recyclerview-v7:+') {
exclude module: 'support-v4'
}
I fixed that adding:
compile ('com.facebook.android:facebook-android-sdk:3.22.0#aar'){
exclude module: 'support-v4'
}
Found a solution to this:
Removed the config section in the build.gradle that excludes support-v4
It turns out that .aar files are basically a zip, so removed the support-v4 jar from the dependency .aar library (using 7-zip).
And now, I don't get the top-level exception and at the same time able to use recyclerview-v7.
If you are using dependency projects instead of .aar files, try removing the support-v4.jar files in the dependency projects before compiling.
Shouldn't the gradle build tool be intelligent enough to exclude the duplicate packages rather than having the users go thru this kind of workarounds and headaches?

Categories

Resources