I am running into the following error
java.lang.NoSuchFieldError: WRITE_DURATIONS_AS_TIMESTAMPS
at com.fasterxml.jackson.datatype.joda.ser.DurationSerializer.<init>(DurationSerializer.java:28)
at com.fasterxml.jackson.datatype.joda.ser.DurationSerializer.<init>(DurationSerializer.java:25)
at com.fasterxml.jackson.datatype.joda.JodaModule.<init>(JodaModule.java:45)
I checked to see what versions of jackson-datatype-joda are available. It appears that maven has excluded all version mismatches.
Any other reason this might cause serialization errors?
The problem is that among the maven dependencies (mind that it could be a transitive one) you have incompatible versions of jackson-datatype-joda and jackson-databind. Incompatible in the sense that jackson-databind's SerializationFeature class is missing the WRITE_DURATIONS_AS_TIMESTAMPS field. To see what dependencies maven brings you can run the following command in the terminal (or you can use an IDE's maven plug to search and analyse the maven dependency tree):
mvn dependency:tree | grep databind
the outcome will most probably be something like:
[INFO] | +- com.fasterxml.jackson.core:jackson-databind:jar:2.4.1:compile
The version of course can vary but the important thing is that the WRITE_DURATIONS_AS_TIMESTAMPS field is only available since version 2.5
You can exclude a transitive dependency like this:
<dependency>
<groupId>group.id</groupId>
<artifactId>artifact-id</artifactId>
<version>${artifact.version}</version>
<exclusions>
<exclusion>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
</exclusion>
</exclusions>
</dependency>
If it's not a transitive dependency you need to update version of jackson-databind.
I got it resolved by using following dependency as this dependency has overridden any other version used:
<dependency>
<groupId>com.fasterxml.jackson.datatype</groupId>
<artifactId>jackson-datatype-joda</artifactId>
<version>2.5.3</version>
</dependency>
I had same error. I had included all jackson*2.7.0 libraries under WEB-INF/lib/ and i was still getting that error. I am using wildfly 8.2 and it had jackson 2.4.1 libraries under modules and somehow it was loading 2.4.1 jars from that location. So I had to manually upgrade them to 2.7.0 which fixed the issue. I was under impression that if I did not mention it to load jackson jars in deployment configuration file, it would not load wildfly jars. I guess I was wrong.
Related
Is it possible, given a dependency such as shown below to determine the versions of included dependencies:
<!-- https://mvnrepository.com/artifact/org.apache.tomcat.embed/tomcat-embed-core -->
<dependency>
<groupId>org.apache.tomcat.embed</groupId>
<artifactId>tomcat-embed-core</artifactId>
<version>8.5.6</version>
</dependency>
For example, can we determine which version of javax.servlet-api tomcat-embed-core uses as dependency?
I would like to use the same version of javax.servlet-api in a sub-module. But I don't want to include the whole tomcat-embed-core dependency just to get the right version of javax.servlet.api.
(Optional question: Is there an easy way to do this in IntelliJ?)
In Intelij you can right click on the pom -> maven -> show effective pom.
Or I would say best is from the command line:
mvn dependency:list | grep tomcat
We are upgrading openam to version 13. I've set artifacts version to 13.0.0 but when I start building the service with Maven I get a error message saying:
failure to find org.forgerock.openam:openam-oauth2-common:jar:13.0.0.
We are using forgerock repository: http://maven.forgerock.org/repo/repo/
Question: why the dependency is suddendly not available any longer and how to properly upgrade it?
It appears that the artifact you were using has been refactored, moving from a single project (i.e. a library) to a multi-module project (several modules, several libraries). Hence, although its Maven coordinates have not changed (GAV, GroupId, ArtifactId, Version), the usage (the consumption) of this library has been directly affected because its type has changed (again, from jar to pom).
Version 11.0.0, for example, was a jar, hence you could import it as most of the Maven dependency, via a dependency section.
However, since version 12.0.0, the artifact is a pom defining the following modules:
<module>oauth2-core</module>
<module>oauth2-restlet</module>
<module>openid-connect-core</module>
<module>openid-connect-restlet</module>
<module>oauth2-oidc-test-server</module>
Hence, what previously would have been:
<dependency>
<groupId>org.forgerock.openam</groupId>
<artifactId>openam-oauth2-common</artifactId>
<scope>provided</scope>
<version>11.0.0</version>
</dependency>
It cannot be simply upgraded via its version number but must be replaced via several dependencies (you can now narrow down what you actually need):
<dependency>
<groupId>org.forgerock.openam</groupId>
<artifactId>oauth2-core</artifactId>
<version>13.0.0</version>
</dependency>
<dependency>
<groupId>org.forgerock.openam</groupId>
<artifactId>oauth2-restlet</artifactId>
<version>13.0.0</version>
</dependency>
<dependency>
<groupId>org.forgerock.openam</groupId>
<artifactId>openid-connect-core</artifactId>
<version>13.0.0</version>
</dependency>
<dependency>
<groupId>org.forgerock.openam</groupId>
<artifactId>openid-connect-restlet</artifactId>
<version>13.0.0</version>
</dependency>
<dependency>
<groupId>org.forgerock.openam</groupId>
<artifactId>oauth2-oidc-test-server</artifactId>
<version>13.0.0</version>
</dependency>
Most probably version 11.0.0 is provided as a subset of the dependencies above, including them should fix the issue (but you could also investigate later on which one is effectively required by your project, e.g. the last one, oauth2-oidc-test-server, is most probably not required simply looking at its artifactId name, as an immediate guess).
We have recently upgraded from Drools 5 to Drools 6 and have run into disturbing conflict issues.
We have kie-ci imported into out project. kie-ci brings in sisu-guava. sisu-guava changes the accessibility of some of the classes from google's guava. Unfortunately, it uses the same package name as google's guava.
Since we're working with google's guava in our project, we are running into conflicts of classes.
An attempt to remove sisu-guava from the project (using a maven exclusion) results in accessibility exceptions, as the kie-ci code attempt to access classes which are public in sisu-guava but are private in google's guava.
Any idea how to get round this.
This may not be correct solution for all situation, but I was able to resolve this issue by excluding the susi-guava jar in my pom:
<dependency>
<groupId>org.jbpm</groupId>
<artifactId>jbpm-kie-services</artifactId>
<version>${jbpm.version}</version>
<exclusions>
<exclusion>
<groupId>org.sonatype.sisu</groupId>
<artifactId>sisu-guava</artifactId>
</exclusion>
</exclusions>
</dependency>
I seem to have the same problem using drools 6.2. Drools is dependent on guava 10.0.1, where as my project had a dependency on guava 16 and maven was picking the version 16 (correctly).
On inspecting the dependency tree, I find that the drools dependency on guava is dictated by "org.eclipse.sisu:org.eclipse.sisu.plexus:jar:0.0.0.M5:runtime".
There is a newer version of org.eclipse.sisu.plexus, so I added the following to my project's pom to pick up the latest version, which is:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.eclipse.sisu</groupId>
<artifactId>org.eclipse.sisu.plexus</artifactId>
<version>0.3.1</version>
</dependency>
</dependencies>
</dependencyManagement>
Now, there does not seem to be a dependency on guava, for drools and the problem is solved and my project can use version 16 of guava.
I try to compile maven web project with
<dependency>
<groupId>org.springframework.ws</groupId>
<artifactId>spring-ws</artifactId>
<version>3.0.5-FINAL</version>
</dependency>
The problem is that when I try compile it I get the following errors:
[ERROR] Failed to execute goal on project inferx-d2aserver: Could
not resolve dependencies for project
com.inferx:inferx-d2aserver:war:4.0: The following artifacts could not
be resolved: maven-plugins:maven-cobertura-plugin:plugin:1.3,
maven-plugins:maven-findbugs-plugin:plugin:1.3.1,
org.springframework.ws:spring-ws:jar:3.0.5.RELEASE: Failure to find
maven-plugins:maven-cobertura-plugin:plugin:1.3 in
http://repository.springsource.com/maven/bundles/release was cached in
the local repository, resolution will not be reattempted until the
update interval of com.springsource.repository.bundles.release has
elapsed or updates are forced -> [Help 1] [ERROR]
I use Apache Maven 3.0.3, Java: 1.7.0 OS: Windows 7 (64 bit)
I am not sure if this is the same case since my dependencies is different. I got similar error message with the same dependencies error so I removed both dependencies from ~/.m2/repository/jaxen/jaxen/1.1.3/jaxen-1.1.3.pom and the project is compile fine now.
I was also facing similar issue. I just excluded jaxen from Jdom dependency and it worked for me.
jdom 1.1.2 includes jaxen 1.1.3 which imports those artifacts.
<dependency>
<groupId>org.jdom</groupId>
<artifactId>jdom</artifactId>
<version>1.1.2</version>
<exclusions>
<exclusion>
<groupId>jaxen</groupId>
<artifactId>jaxen</artifactId>
</exclusion>
</exclusions>
</dependency>
It look like your pom or parent pom contains a wrong definition of the maven-coberatura-plugin which should be fixed first. Furthermore remove the folder in your local repository.
From the error message related to cobertura version, it looks like you may be having a pom.xml corresponding to maven 1.
The following are maven 1.x versions of the plugins and not supported.
maven-plugins:maven-cobertura-plugin:plugin:1.3,
maven-plugins:maven-findbugs-plugin:plugin:1.3.1
Removing the pom is not the solution; in future builds may be you need them. Best solution according to my opinion is to modify the POM of corresponding jars. Like if you are getting error because of any jar; actually there is the dependency defined in its POM. So use <exclude>. That will work for sure.
I'm trying to upgrade my struts2 web app from guice2.0 to guice3.0.
I'm trying to test it out using maven jetty.
I've successfully upgraded my pom.xml to use the correct version and groupId for the 3.0 release, but if I call mvn jetty:run
I see that it is trying to download
guice-3.0-no_deps.jar
which throws a build error and can't be found the central repository?
I don't get this error if I don't include any guice extensions.
Any ideas?
Thanks
I posted this question also to the guice user group.
This is the answer I received.
The guice-3.0-no_deps.jar is a build-time artifact that's used to compile the extensions, but is not required at runtime - it's not on maven central because the Guice team didn't want people depending on this "uber-jar" by mistake. The extensions have an optional dependency to guice-3.0-no_deps.jar (so they can compile) but they also have a non-optional dependency to guice-3.0.jar for the runtime case.
Well-behaved maven plugins should see that the the no_deps dependency is optional and not throw a build error if it's missing, so this sounds like a bug in the jetty plugin. To workaround the Jetty bug you can explicitly hide this dependency as follows:
<dependency>
<groupId>com.google.inject.extensions</groupId>
<artifactId>guice-struts2</artifactId>
<version>3.0</version>
<exclusions>
<exclusion>
<groupId>com.google.inject</groupId>
<artifactId>guice</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>com.google.inject</groupId>
<artifactId>guice</artifactId>
<version>3.0</version>
</dependency>
Note that we can't do this in the original build pom because we still need the no_deps dependency when doing the original compilation.