I'm having trouble including Google Play Services in a Maven build. I've use the android SDK deployer to deploy an apklib for GPS and have added the following to my pom.xml.
<dependency>
<groupId>com.google.android.gms</groupId>
<artifactId>google-play-services</artifactId>
<version>7</version>
<type>apklib</type>
</dependency>
<dependency>
<groupId>com.google.android.gms</groupId>
<artifactId>google-play-services</artifactId>
<type>jar</type>
<version>7</version>
</dependency>
This works for importing the library but the issue occurs when I try to build the project using Maven. I get the following error during the build process.
[INFO] UNEXPECTED TOP-LEVEL EXCEPTION:
[INFO] java.lang.IllegalArgumentException: already added: Landroid/UnusedStub;
[INFO] at com.android.dx.dex.file.ClassDefsSection.add(ClassDefsSection.java:123)
[INFO] at com.android.dx.dex.file.DexFile.add(DexFile.java:163)
[INFO] at com.android.dx.command.dexer.Main.processClass(Main.java:490)
[INFO] at com.android.dx.command.dexer.Main.processFileBytes(Main.java:459)
[INFO] at com.android.dx.command.dexer.Main.access$400(Main.java:67)
[INFO] at com.android.dx.command.dexer.Main$1.processFileBytes(Main.java:398)
[INFO] at com.android.dx.cf.direct.ClassPathOpener.processArchive(ClassPathOpener.java:245)
[INFO] at com.android.dx.cf.direct.ClassPathOpener.processOne(ClassPathOpener.java:131)
[INFO] at com.android.dx.cf.direct.ClassPathOpener.process(ClassPathOpener.java:109)
[INFO] at com.android.dx.command.dexer.Main.processOne(Main.java:422)
[INFO] at com.android.dx.command.dexer.Main.processAllFiles(Main.java:333)
[INFO] at com.android.dx.command.dexer.Main.run(Main.java:209)
[INFO] at com.android.dx.command.dexer.Main.main(Main.java:174)
[INFO] at com.android.dx.command.Main.main(Main.java:91)
I've been able to resolve the error by setting the scope on the jar or apklib to provided but this causes a class not found exception at runtime. What am I missing here? From everything I've read online this is all you should need to use GPS with Maven.
It turns out another dependency of mine was also pulling down Google Play Services. I'm using the Drive SDK in my application along with google-api-client-android which was the culprit. The frustrating part was that the groupId and artifactId for GPS was different in google-api-client-android than the ones generated using the Android SDK Deployer. The solution was to add the exclusion to the google-api-client-android dependency as follows.
<dependency>
<groupId>com.google.api-client</groupId>
<artifactId>google-api-client-android</artifactId>
<version>1.15.0-rc</version>
<exclusions>
<exclusion>
<groupId>com.google.android.google-play-services</groupId>
<artifactId>google-play-services</artifactId>
</exclusion>
</exclusions>
</dependency>
Related
I have a Google App Engine project that I'm building with maven. I added jax-rs to it by adding the following bom to my pom:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.google.cloud</groupId>
<artifactId>google-cloud-bom</artifactId>
<version>0.73.0-alpha</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<dependency>
<groupId>org.glassfish.jersey</groupId>
<artifactId>jersey-bom</artifactId>
<version>2.27</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
Also I needed these three dependencies:
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-servlet</artifactId>
<exclusions>
<exclusion><!-- Exclude this repackaged javax.inject. -->
<groupId>org.glassfish.hk2.external</groupId>
<artifactId>javax.inject</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.inject</groupId>
<artifactId>jersey-hk2</artifactId>
<exclusions>
<exclusion><!-- Exclude this repackaged javax.inject. -->
<groupId>org.glassfish.hk2.external</groupId>
<artifactId>javax.inject</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.media</groupId>
<artifactId>jersey-media-json-binding</artifactId>
</dependency>
As you can see I have excluded some of the repackaged to get rid of some runtime warnings about duplicate classes being found. To be clear, every rest call using the jax-rs api's works fine and I don't see the warnings on google app engine itself, just locally. (full code at https://github.com/Leejjon/blindpool) When running it on the local jetty runtime using 'mvn appengine:run', it still complains about every json related class in the javax.json-1.1.jar and javax.json-api-1.1.jar.
Example
[INFO] GCLOUD: 2018-12-11 22:01:13.495:WARN:oeja.AnnotationParser:main: Unknown asm implementation version, assuming version 393216
[INFO] GCLOUD: 2018-12-11 22:01:13.780:WARN:oeja.AnnotationParser:qtp551734240-15: javax.json.Json scanned from multiple locations: jar:file:///C:/Users/Leejjon/IdeaProjects/Blindpool/backend/target/blindpool-1.0-SNAPSHOT/WEB-INF/lib/javax.json-api-1.1.jar!/javax/json/Json.class, jar:file:///C:/Users/Leejjon/IdeaProjects/Blindpool/backend/target/blindpool-1.0-SNAPSHOT/WEB-INF/lib/javax.json-1.1.jar!/javax/json/Json.class
When I look at my 'mvn dependency:tree' output I can see that my 'jersey-media-json-binding' dependency has both javax.json-1.1 and javax.json-api-1.1 in it. And they have classes that have the same names.
[INFO] +- org.glassfish.jersey.media:jersey-media-json-binding:jar:2.27:compile
[INFO] | +- org.glassfish:javax.json:jar:1.1:compile
[INFO] | +- org.eclipse:yasson:jar:1.0:compile
[INFO] | | +- javax.json:javax.json-api:jar:1.1:compile
[INFO] | | \- javax.enterprise:cdi-api:jar:2.0:compile
[INFO] | | +- javax.el:javax.el-api:jar:3.0.0:compile
[INFO] | | \- javax.interceptor:javax.interceptor-api:jar:1.2:compile
[INFO] | \- javax.json.bind:javax.json.bind-api:jar:1.0:compile
Full dependency tree (https://pastebin.com/JfwzavDX).
I have tried to exclude them but failed to do so in a way that didn't cause me to actually break my web app and get errors like: javax.servlet.ServletException: org.glassfish.jersey.server.ContainerException: java.lang.ExceptionInInitializerError
TLDR: What dependency to I exclude here to get rid of the duplicate location warning thrown by the 'mvn appengine:run' command without breaking the jax-rs application.
Hoping for that jax-rs/maven/jetty/jersey/google app engine god to pass by and point me in the right direction :)
Overall applicatiom I'm using Apache HttpComponents dependency:
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpclient</artifactId>
<version>4.5.2</version>
</dependency>
But also another library uses this artifact, but different version (4.3.2, not 4.5.2):
<dependency>
<groupId>com.sendgrid</groupId>
<artifactId>sendgrid-java</artifactId>
</dependency>
The problem is that API between this versions is changed and I'm getting this error:
Caused by: java.lang.ClassNotFoundException: org.apache.http.ssl.SSLContexts
How I can say to maven not to override Sendgrid's version of HttpComponents (4.3.2) with 4.5.2?
EDIT: version of httpcomponents is specified in dependencyManagement section of parent pom
Given the following parent pom.xml section:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpclient</artifactId>
<version>4.5.2</version>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>com.sendgrid</groupId>
<artifactId>sendgrid-java</artifactId>
<version>2.0.0</version>
</dependency>
</dependencies>
<modules>
<module>module-a</module>
<module>module-b</module>
</modules>
Indeed in module-a the dependency tree is the following, executing:
mvn dependency:tree
We get as part of the output:
[INFO] --- maven-dependency-plugin:2.8:tree (default-cli) # module-a ---
[INFO] com.sample:module-a:jar:0.0.1-SNAPSHOT
[INFO] \- com.sendgrid:sendgrid-java:jar:2.0.0:compile
[INFO] +- org.json:json:jar:20140107:compile
[INFO] +- org.apache.httpcomponents:httpcore:jar:4.3.2:compile
[INFO] +- org.apache.httpcomponents:httpclient:jar:4.5.2:compile
[INFO] | +- commons-logging:commons-logging:jar:1.2:compile
[INFO] | \- commons-codec:commons-codec:jar:1.9:compile
[INFO] +- com.sendgrid:smtpapi-java:jar:1.0.0:compile
[INFO] \- org.apache.httpcomponents:httpmime:jar:4.3.4:compile
Note:
We get org.apache.httpcomponents:httpclient:jar:4.5.2:compile
We also get org.apache.httpcomponents:httpcore:jar:4.3.2:compile
A potential versons mismatch happens here between libraries of the same family
Adding then to the module-a's pom.xml the following:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpclient</artifactId>
<version>4.3.2</version>
</dependency>
</dependencies>
</dependencyManagement>
And re-running our dependency tree execution, we get as part of the output:
[INFO] --- maven-dependency-plugin:2.8:tree (default-cli) # module-a ---
[INFO] com.sample:module-a:jar:0.0.1-SNAPSHOT
[INFO] \- com.sendgrid:sendgrid-java:jar:2.0.0:compile
[INFO] +- org.json:json:jar:20140107:compile
[INFO] +- org.apache.httpcomponents:httpcore:jar:4.3.2:compile
[INFO] +- org.apache.httpcomponents:httpclient:jar:4.3.2:compile
[INFO] | +- commons-logging:commons-logging:jar:1.1.3:compile
[INFO] | \- commons-codec:commons-codec:jar:1.6:compile
[INFO] +- com.sendgrid:smtpapi-java:jar:1.0.0:compile
[INFO] \- org.apache.httpcomponents:httpmime:jar:4.3.4:compile
We now get httpcore and httpclient aligned, with the versions we wanted.
Also note the httpmime to version 4.3.4, it's a fix version change, but still a misalignment (should be harmless though).
In this case it seems you are adding governance at parent level in dependencyManagement (good approach), but then at the level of one of the modules you need to override it. That can happen, but better to properly comment it, for maintenance and for the future yourself looking at it in the future.
Also note: other modules in this project would not be affected by this change, that is, they will still get version 4.5.2. If the final result of the whole multimodule build is an ear or war file, for example, carefully check what you eventually get.
It is impossible in a simple maven project to have 2 different versions of the same artifact in the classpath. So you cannot have 4.3.2 and 4.5.2 versions in the classpath simultaneously.
However there are several options... You can either
use in your project the older version (4.3.*), compatible with sendgrid-java dependency (simplest way); or
update sendgrid-java dependency, if newer one is compatible with http components 4.5.* (preferred way); or
mark sendgrid-java as a 'provided' dependency, build a separate class loader in runtime and load it with correct dependencies versions (a bit tricky, but I saw this approach in a couple bank applications)
In my project I have openejb-core dependency with scope provided. However it has transitive dependency of slf4j and its scope is compile (see screenshot). All other transitive dependencies are provided as expected.
Question: Is it bug or am I missing something?
In a sample pom I added:
<dependencies>
<dependency>
<groupId>org.apache.openejb</groupId>
<artifactId>openejb-core</artifactId>
<version>4.7.0</version>
<scope>provided</scope>
</dependency>
</dependencies>
Then running:
mvn dependency:tree -Dincludes=org.slf4j
The output is:
[INFO] --- maven-dependency-plugin:2.8:tree (default-cli) # test-junit ---
[INFO] com.sample:test-sample:jar:0.0.1-SNAPSHOT
[INFO] \- org.apache.openejb:openejb-core:jar:4.7.0:provided
[INFO] +- org.slf4j:slf4j-jdk14:jar:1.7.7:provided
[INFO] \- org.slf4j:slf4j-api:jar:1.7.7:provided
So as you can see Maven is coherent with its official documentation. The issue from your screenshot is probably on your IDE.
The table is the key point on this topic:
From it, we can see that what is transitively in scope compile or runtime goes in scope provided, what is in scope provided or test is ignored.
However, if I change my sample pom to:
<dependencies>
<dependency>
<groupId>org.apache.openejb</groupId>
<artifactId>openejb-core</artifactId>
<version>4.7.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.7</version>
</dependency>
</dependencies>
And re-run the dependency tree command, the output is as following:
[INFO] --- maven-dependency-plugin:2.8:tree (default-cli) # test-junit ---
[INFO] com.sample:test-sample:jar:0.0.1-SNAPSHOT
[INFO] +- org.apache.openejb:openejb-core:jar:4.7.0:provided
[INFO] | \- org.slf4j:slf4j-jdk14:jar:1.7.7:provided
[INFO] \- org.slf4j:slf4j-api:jar:1.7.7:compile
Look now: it comes not as a child of the provided dependency, but at the same level.
Let's keep on.
If on my sample pom I remove the sl4f-api dependency but I add to the pom the following:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.7</version>
<scope>compile</scope>
</dependency>
</dependencies>
</dependencyManagement>
And re-re-run the dependency tree command, I finally get the same as your screenshot:
[INFO] --- maven-dependency-plugin:2.8:tree (default-cli) # test-junit ---
[INFO] com.sample:test-sample:jar:0.0.1-SNAPSHOT
[INFO] \- org.apache.openejb:openejb-core:jar:4.7.0:provided
[INFO] +- org.slf4j:slf4j-jdk14:jar:1.7.7:provided
[INFO] \- org.slf4j:slf4j-api:jar:1.7.7:compile
Bingo: the dependencyManagement section is overriding the scope of the transitive dependency, affecting also the mediation on provided scope. This is not a bug, it's by design as in this section you define kind of governance concerning your dependencies. The diagram in this case is also correct and not misleading, since the dependency is only introduced by openejb-core which is then affected by the dependencyManagement decision to put sl4f-api in scope compile.
We have been using Android API version 17 in a project and wish to upgrade to API version 19 because the application runs on Android 4.4.
We use Maven as our build environment. I have replaced all the occurrences of SDK version 17 to 19 in our AndroidManifest.xml. But I am having problems upgrading to the 4.4 platform through Maven.
I used the Android SDK Deployer tool to push the android-4.4 package into my local Maven repository. I then replaced the reference to android-4.2 to android-4.4 in our 'parent' POM.xml:
<dependencyManagement>
<dependencies>
<dependency>
<!-- <groupId>com.google.android</groupId> OLD -->
<groupId>android</groupId>
<artifactId>android</artifactId>
<!-- <version>4.2.2_r2</version> OLD -->
<version>4.4.2_r4</version>
<scope>provided</scope>
</dependency>
This change seemed to introduce a conflict. Another dependency is bringing in version 2.1_r1 of android package which is conflicting with the new 4.4.2_r4 package:
Excerpt from 'mvn dependency:tree':
.
[INFO] +- com.github.tony19:logback-android-classic:jar:1.0.10-2:compile
[INFO] | \- com.github.tony19:apktool-lib:jar:1.4.4-3:compile
[INFO] | \- com.google.android:android:jar:2.1_r1:compile
[INFO] | +- org.khronos:opengl-api:jar:gl1.1-android-2.1_r1:compile
[INFO] | +- xerces:xmlParserAPIs:jar:2.6.2:compile
[INFO] | \- xpp3:xpp3:jar:1.1.4c:compile
I noticed that if I move the <dependency> declaration of the 4.4 package above the logback-android-classic dependency declaration in pom.xml then our module will use the 4.4 dependency. However I don't think this is a proper fix, and I am running into various issues building the project as a whole.
Can those more experienced with Maven please advise on the correct way to resolve this?
Going through each affected module and adding an exclusion to the logback-android-classic dependency seems to have resolved it:
<exclusions>
<exclusion>
<artifactId>android</artifactId>
<groupId>android</groupId>
</exclusion>
<exclusion>
<artifactId>android</artifactId>
<groupId>com.google.android</groupId>
</exclusion>
</exclusions>
I'm writing a standalone client for an ejb application deployed to jboss wildfly 9.0.1.Final. The documentation I've reviewed suggests there is a readme file (readme-ejb-jms.txt) in the wildfly directory. This file contained the following suggestion for the maven dependencies:
<dependencies>
<dependency>
<groupId>org.jboss.as</groupId>
<artifactId>jboss-as-ejb-client-bom</artifactId>
<type>pom</type>
</dependency>
<dependency>
<groupId>org.jboss.as</groupId>
<artifactId>jboss-as-jms-client-bom</artifactId>
<type>pom</type>
</dependency>
</dependencies>
If I use this I get an error saying version is required so I modified the dependencies to look like this:
<dependency>
<groupId>org.jboss.as</groupId>
<artifactId>jboss-as-ejb-client-bom</artifactId>
<version>9.0.1.Final</version>
<type>pom</type>
</dependency>
<dependency>
<groupId>org.jboss.as</groupId>
<artifactId>jboss-as-jms-client-bom</artifactId>
<version>9.0.1.Final</version>
<type>pom</type>
</dependency>
When I run mvn clean install with the above I get this error:
The following artifacts could not be resolved:
org.jboss.as:jboss-as-ejb-client-bom:pom:9.0.1.Final,
org.jboss.as:jboss-as-jms-client-bom:pom:9.0.1.Final:
Failure to find org.jboss.as:jboss-as-ejb-client-bom:pom:9.0.1.Final
The full output from mvn clean install is shown below:
C:\_WORKSPACE\workspace\_myapp\myappjbosswildflyclient>mvn clean install
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building myappjbosswildflyclient 4.3.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[WARNING] The POM for org.jboss.as:jboss-as-ejb-client-bom:pom:9.0.1.Final is missing, no dependency information available
[WARNING] The POM for org.jboss.as:jboss-as-jms-client-bom:pom:9.0.1.Final is missing, no dependency information available
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 0.957s
[INFO] Finished at: Tue Aug 04 17:17:04 EDT 2015
[INFO] Final Memory: 5M/118M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal on project myappjbosswildflyclient: Could not resolve dependencies for project mycompany-myapp:myappjbosswildflyclient:jar:4.3.0-SNAPSHOT: The following artifacts could not be resolved: org.jboss.as:jboss-as-ejb-client-bom:pom:9.0.1.Final, org.jboss.as:jboss-as-jms-client-bom:pom:9.0.1.Final: Failure to find org.jboss.as:jboss-as-ejb-client-bom:pom:9.0.1.Final in http://downl
oad.java.net/maven/2 was cached in the local repository, resolution will not be reattempted until the update interval of java.net2 has elapsed or updates are forced -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
C:\_WORKSPACE\workspace\_myapp\myappjbosswildflyclient>
What should I be using for these dependencies?
This works fine for me:
<dependency>
<groupId>org.wildfly</groupId>
<artifactId>wildfly-ejb-client-bom</artifactId>
<type>pom</type>
<version>9.0.1.Final</version>
</dependency>
<dependency>
<groupId>org.wildfly</groupId>
<artifactId>wildfly-jms-client-bom</artifactId>
<type>pom</type>
<version>9.0.1.Final</version>
</dependency>
It looks like you don't have access to the maven repository or could have disconnected while retrieving the dependency jars. You can manually delete your local repo and retry the build
Your dependencies must be of type POM.
<type>pom</type>
I found this post and followed the suggestions it provided:
https://developer.jboss.org/thread/237382
My dependencies look like this:
<dependency>
<groupId>org.wildfly</groupId>
<artifactId>wildfly-ejb-client-bom</artifactId>
<type>pom</type>
<version>8.0.0.Final</version>
<scope>import</scope>
</dependency>
<dependency>
<groupId>org.wildfly</groupId>
<artifactId>wildfly-jms-client-bom</artifactId>
<type>pom</type>
<version>8.0.0.Final</version>
<scope>import</scope>
</dependency>
I am now able to build the project and create the initial context for the ejb look up.
I Tried using 9.0.1.Final and 9.0.0.Final for the versions with no luck.
I am very uncomfortable with the fact that the versions do not match and with the fact that the dependencies documented in the README-EJB-JMS.txt file provided with the distribution does not work.