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.
Related
in spring boot project tomcat-embed-core: 9.0.12 is getting resolved by parent dependency spring-boot-starter-web:2.1.0.
but due to some reasons we have to upgrade the tomcat-embed-core version from 9.0.12 to 9.0.20.
I have added the below dependency separately in POM,
<dependency>
<groupId>org.apache.tomcat.embed</groupId>
<artifactId>tomcat-embed-core</artifactId>
<version>9.0.20</version>
</dependency>
now I can see V9.0.20 in dependency hierarchy, but also omitted for conflict with 9.0.20.
is this a correct way, if no then suggest the best way to do this?
I am trying to resolve dependency version conflicts while using the below dependencies.
The worst one I am facing is zucchini project supports the apache commons-io versions from 1.4 to latest one. It does not support versions
below 1.4
and at the same time pagerduty-client supports commons-io versions below 1.4 version.
So It is not possible to specify a common version of this dependency (dependency management)
which supports in both zucchini and pager-duty client (both are third party libraries).
In this particular situation I couldn't find a possible way to resolve this issue. Any help will be appreciated.
<dependency>
<groupId>com.comcast.zucchini</groupId>
<artifactId>zucchini</artifactId>
<version>[2.2.5,)</version>
</dependency>
<dependency>
<groupId>com.github.dikhan</groupId>
<artifactId>pagerduty-client</artifactId>
<version>3.0.2</version>
</dependency>
Possibility 1
If the old and new commons-io package/class names are a close enough match, excluding the old dependency from pagerduty-client could possibly work.
https://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html
<dependency>
<groupId>com.github.dikhan</groupId>
<artifactId>pagerduty-client</artifactId>
<version>3.0.2</version>
<exclusions>
<exclusion>
<groupId>org.apache.commons</groupId>
<artifactId>commons-io</artifactId>
</exclusion>
</exclusions>
</dependency>
This relies on the binary API of commons-io between versions 1.3.2 and 2.x being similar enough.
There does seem to be lots of overlap, looking at the code of each version:
https://github.com/apache/commons-io/tree/commons-io-1.3.2/src/java/org/apache/commons/io
https://github.com/apache/commons-io/tree/commons-io-2.5/src/main/java/org/apache/commons/io
Possibility 2
Split up your application so that the commons-io dependency is not shared and does not conflict.
It could be that the pagerduty-client and zucchini parts of your application do not need to be 'bundled' together, so split them up.
If they do need work together then you could still have two apps/processes and send messages between them.
Note
I cloned the pagerduty-client repo and changed the commons-io dependency from org.apache.commons:commons-io:1.3.2 to commons-io:commons-io:2.5 and the tests worked, so maybe you can suggest to the project owner that they upgrade commons-io.
And looking at the code it seems commons-io is hardly used (one place, HttpApiServiceImpl.java):
\pagerduty-client>findstr /s /c:"commons" *.java
src\main\java\com\github\dikhan\pagerduty\client\events\domain\AcknowledgeIncident.java:import org.apache.commons.lang3.StringUtils;
src\main\java\com\github\dikhan\pagerduty\client\events\domain\Incident.java:import org.apache.commons.lang3.StringUtils;
src\main\java\com\github\dikhan\pagerduty\client\events\domain\Incident.java:import org.apache.commons.lang3.builder.Builder;
src\main\java\com\github\dikhan\pagerduty\client\events\domain\Payload.java:import org.apache.commons.lang3.StringUtils;
src\main\java\com\github\dikhan\pagerduty\client\events\domain\ResolveIncident.java:import org.apache.commons.lang3.StringUtils;
src\main\java\com\github\dikhan\pagerduty\client\events\HttpApiServiceImpl.java:import org.apache.commons.io.IOUtils;
src\main\java\com\github\dikhan\pagerduty\client\events\PagerDutyEventsClient.java:import org.apache.commons.lang3.StringUtils;
src\main\java\com\github\dikhan\pagerduty\client\events\utils\FakePagerDutyEventsClient.java:import org.apache.commons.lang3.StringUtils;
As your commons-io is the problem you'll have to look further up the line. That means either upgrade pagerduty-client to a version that uses a newer version of commons-io that Cucumber likes, or downgrade zucchini to require a version of Cucumber that works with pagerduty-client as well.
This is a common problem with some jakarta commons packages, they at some point decided to massively change the public interface without changing the package name, causing conflicts like this for users.
You may be in luck, I once worked on a project where we had to rewrite thousands of lines of code just so we could link to a library we desperately needed that depended on a newer version of commons-io than the one we'd been using.
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).
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.
I have the following dependency (only so far) pom.xml
<dependency>
<groupId>org.springframework.data</groupId>
<artifactId>spring-data-jpa</artifactId>
<version>1.6.2.RELEASE</version>
</dependency>
This dependency obviously depends on other "dependencies" via it's pom.xml... when maven finished downloading these dependencies I noticed that it didn't grab the latest version of the Spring stuff (4.0.6.RELEASE)... it grabbed a 3.2.x version.
How can I force maven to grab the latest version of the Spring stuff? Do I need to explicitly modify my pom.xml to include all the dependencies or is there some "magic" I can use for this?
Thanks.
Spring "Bill Of Materials"
Salvation may come from special "bill of materials" POMs supported by Maven and published by Spring. Quoting from Maven "Bill Of Materials" Dependency in their manual:
It is possible to accidentally mix different versions of Spring JARs when using Maven. For example, you may find that a third-party library, or another Spring project, pulls in a transitive dependency to an older release. If you forget to explicitly declare a direct dependency yourself, all sorts of unexpected issues can arise.
To overcome such problems Maven supports the concept of a "bill of materials" (BOM) dependency. You can import the spring-framework-bom in your dependencyManagement section to ensure that all spring dependencies (both direct and transitive) are at the same version.
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-framework-bom</artifactId>
<version>4.0.6.RELEASE</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
Would this work for you?
Looking at the spring-data-jpa artifact pom file, we can see that it has a parent called spring-data-parent with current version 1.4.2.RELEASE. It's pom describes dependencies and their versions. Currently spring version is at 3.2.10.RELEASE
One way you can possibly accomplish what you want is to add explicit dependency on spring artifacts. But you would still have to define their versions.