I am porting my Swing app to Android. I use mail.jar and jscape's secure iNet factory (sinetfactory.jar) for FTP/SFTP/SSH support in my swing app.
Both mail.jar and sinetfactory.jar use the java activation framework (activation.jar) which has java.awt dependencies. The android version of mail.jar and activation.jar are modified to remove this dependency on java.awt.
When I add android mail.jar, activation.jar and sinetfactory.jar to my Android Studio project, I get the following error:
UNEXPECTED TOP-LEVEL EXCEPTION:
com.android.dex.DexException: Multiple dex files define Lcom/sun/activation/registries/LineTokenizer;
This exact same error has a topic on StackOverflow, but does not apply to my situation. That topic seemed to be a Gradle issue. My issues is that I have 2 libraries with the same dependency (activation framework). I need to use both versions of activation.jar. i.e. mail.jar needs the android modified version of activation.jar, whereas sinetfactory.jar needs the original java version of activation.jar.
What are my options to resolve this issue? Can this be done via some gradle setting?
Try to use it
android {
packagingOptions {
exclude 'META-INF/DEPENDENCIES.txt'
exclude 'META-INF/LICENSE.txt'
exclude 'META-INF/NOTICE.txt'
exclude 'META-INF/NOTICE'
exclude 'META-INF/LICENSE'
exclude 'META-INF/DEPENDENCIES'
exclude 'META-INF/notice.txt'
exclude 'META-INF/license.txt'
exclude 'META-INF/dependencies.txt'
exclude 'META-INF/LGPL2.1'
}
defaultConfig {
// Enabling multidex support.
multiDexEnabled true
}
}
compile 'javax.mail:javax.mail-api:1.5.3'
Related
I've written a Flutter plugin to use an SDK that requires the inclusion of some .aar modules. It builds and runs perfectly in the example app for the plugin, but when I import the plugin in a different app and try to build it, the build immediately fails with a message saying that one of the .aar modules could not be found in the plugin. This makes no sense because the module is definitely there - the platform channels to use the SDK would fail in the example app if the module wasn't there.
Why would the example app build and run without any problems but a different app won't? The only thing I can think of is that I import the plugin from path in my pubspec but it seems unlikely to me that this is the culprit.
Any advice or assistance here would be appreciated. TIA!
I got it!!!!
The answer is as found here: How to add .aar dependency in library module?
The way this adapts to a Flutter plugin is as follows:
Add a libs folder at the root of the android project in the plugin. Add the .aar files there.
In the plugin's build.gradle file, update rootProject.allProjects to look as follows:
repositories {
google()
jcenter()
flatDir {
dirs 'libs'
dirs project(':your_plugin_name_here').file('libs')
}
}
}
Still in the same build.gradle, add your .aar file(s) as dependencies as follows:
implementation(name:'aar_name_here', ext:'aar')
In the Flutter app that you want to use the plugin for, open the app-level build.gradle file and add the plugin itself as a dependency, like so:
android {
...
dependencies {
implementation project(':your_flutter_plugin');
}
}
In the settings.gradle file for the app that us using the plugin, change
include ':app'
to
include ':app', ':your_flutter_plugin'
And this should do it!!
I want to understand the dependencies for a multi-module maven project and for that referred to eclipse dependency hierarchy.
I did understand fairly, however some of the things I am not able to understand at all.
Below is the screen shot.
The things which I didn't understand are:
--> managed from 1.0.2 [Compile}
--> managed from 1.0.2 (omitted for conflict with 1.0.0) [Compile]
I did search online but I got information in traces. Can anyone help me understand what they mean in easy to understand?
Thanks.
Maven builds a flat classpath from the dependency tree each for compiling ([compile]), for testing, and for running.
In a flat classpath, unlike OSGi, a dependency can only exist in one version. In your cropped screenshot, there is on the second level among other things:
kafka-streams 1.0.2 and
kafka-clients 1.0.0.
kafka-streams 1.0.2 requires kafka-clients 1.0.2 which conflicts to kafka-clients 1.0.0. Therefore kafka-streams 1.0.2 is omitted for conflicts with 1.0.0 even if the version 1.0.2 is required here ("managed from 1.0.2").
More detailed:The classpath which is used to compile or run a plain Java application is flat: all required libraries are globally specified as an ordered list. It is not possible to use a library of a specific version for one package and for another package the same library in a different version.In Maven dependencies builds a tree: each dependency might have its own dependencies. Maven maps the tree of dependencies to the classpath, an ordered list of libraries. If in the Maven dependencies tree the same library exists in different versions, it is not possible to create a flat classpath. This is a conflict.This conflict is resolved by picking one version and omitting all other versions. At the place where the picked version is used instead of the required version, (managed from <required but not picked version>) and (omitted for conflict with <picked version to use instead>) is displayed.In addition, Maven can create different classpaths to compile, to test or to run a Java application via so-called scopes. The [compile] scope is the default scope for using a library in all tasks: compiling, testing and running.
Make sure that the versions specified in the pom.xml file are compatible with each other (which is not yet the case in your screenshot): you have to upgrade kafka-clients from 1.0.0 to 1.0.2 (or downgrade the other libraries).
I'm trying to learn Gradle in Eclipse.
Is there any good integration where you can search for a Jar to include in the project?
Right now it's a hit-and-miss operation from my side.
Example:
I want to add the CLI library from Apache Commons. Also the Codec library.
I have added both jcenter() and mavenCentral like this:
repositories {
jcenter()
mavenCentral()
}
and I have tried this (and variations) in the dependencies section:
compile 'org.apache.commons:cli:1.2'
compile 'org.apache.commons:codec:1.10'
but all I get is
Could not resolve: org.apache.commons:cli:1.2
Could not resolve: org.apache.commons:codec:1.10
When searching in search.maven.org, if I search on org.apache.commons I get 111 pages of hits... I haven't found the time to step thru them all.
When searching for commons-cli, it finds a version from 2005... plus a library called
org.mod4j.org.apache.commons cli
No idea what the "mod4" means.
Is the conclusion that Apache commons doesnt exist in these repositories?
How do you do in these cases? How do you come up with the correct "compile"-specification?
Can I for example say "get latest version of this jar" ?
Would love to have a way to do:
gradle search apache-commons --only-latest-version
or something similar. Something like the wonderful GEM/BUNDLE commands in Ruby.
Thanks for all help
You can search the Maven Central repository to find specific versions of artifacts, but in some cases you have to know the exact name (artifactId) of the artifact. Unfortunately the apache artifacts are not consistent in their groupId or artifactId naming schemes. For example, Apache Commons CLI is commons-cli:commons-cli.
Here is the latest version of that artifact. There is even a convenient panel that shows the exact line to use based on your dependency tool (maven, Gradle, Ivy, etc.)
The below build.gradle works. Have a look at the syntax for dependency declaration. Please read this documentation for syntax.
apply plugin: 'java'
repositories {
jcenter()
mavenCentral()
}
dependencies {
compile group: 'commons-cli', name: 'commons-cli', version: '1.2'
compile group: 'commons-codec', name: 'commons-codec', version: '1.10'
testCompile 'junit:junit:4.12'
}
And as for getting the 'latest' version of a library in gradle, I am afraid thats not possible currently like in maven.
Is there any good integration where you can search for a Jar to include in the project?
As far as I know Gradle itself has no specific support for this.
How do you do in these cases? How do you come up with the correct "compile"-specification?
Before searching in Maven repositories for the desired dependency, best is to consult the project's homepage first. commons-cli for example has a separate Dependency Information section and lists the required information for all kinds of build tools. For Gradle/Grails and the latest SNAPSHOT version this is
compile 'commons-cli:commons-cli:1.4-SNAPSHOT'
The list of valid versions is compiled in the Changes Reports section.
Can I for example say "get latest version of this jar"?
There is a plugin called gradle-versions-plugin that can list updates of defined dependencies. Of course, this requires that you have already defined your dependencies correctly.
When I do a fresh git clone of the greenDAO repo, import the project with Android Studio, and try to compile, references to all the Android objects throw Unresolved Symbol/Method errors. Similarly, the Android specific import statements are also unresolved.
I've gotten as far as realizing that the build.gradle files don't call apply plugin: 'android', but instead lists dependencies like:
dependencies {
provided 'com.google.android:android:4.1.1.4'
provided 'com.google.android:android-test:4.1.1.4'
provided 'com.google.android:annotations:4.1.1.4'
provided 'com.google.android:support-v4:r7'
provided 'com.google.android:support-v4:r7'
...
}
I've used the SDK manager to make sure I have all the files for API v4.1 installed. I also know how to use greenDAO by using the Maven repos and/or importing JARs. My problem is specific to building from source.
Update 1: As stated, when using provided, none of the Android files are found.
I don't have enough reputation to post images, but you can find a screenshot here.
I have an Android library project in Eclipse that I am trying to build with Android Studio so I can generate an .aar file for my users.
The project seems to have been imported cleanly into Android Studio using the "Import Project" option in the welcome screen.
How do I now build the module? The instructions on the dev site say that I need to change:
apply plugin: 'android'
to
apply plugin: 'android-studio'
However my build.gradle file doesn't have that line (I would have assumed that the importer would have added it(?)).
If I insert the line apply plugin: 'android-library', and try to 'Sync Project with Gradle Files', I get the error:
Gradle 'MyProject' project refresh failed
Error:C:\Users\Fred\AndroidStudioProjects\MyProject\src\main\AndroidManifest.xml
(The system cannot find the path specified)
The same happens if I try to make the project anyway.
Here's what my build.gradle looks like:
// Top-level build file where you can add configuration options common to all sub-projects/modules.
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath 'com.android.tools.build:gradle:0.9.+'
}
}
allprojects {
repositories {
mavenCentral()
}
}
apply plugin: 'android-library'
My searches to find a solution have failed. Anyone know what is going on?
I'm using the latest Android Studio (0.5.8)
Don't put the apply plugin: 'android-library' statement in the top-level build file. You should find an apply plugin statement in your module-level build file, and you can modify it there as necessary.
Okay. After some head scratching and more searching, I resolved all my problems I think. For the record:
I think my first import broke somehow. Partly because of the problem highlighted by Scott Barta and possibly because my project directory had spaces in it? Not totally sure.
A later import went more smoothly and I was able to sync and build without errors. However, apart from the build output in the Gradle Console, there was no evidence anything had actually happned. The artifact (ie. the .aar file) doesn't show up in the UI.
After finding this question: How to export library to Jar in Android Studio? I realised that the aar file is in fact built. It is just hidden from you. You have to root around in the file system to find the .aar. It is in:
<Library module>/build/libs/
Something that the docs don't tell you anywhere. Sigh.
Hope this helps someone else..