Exclusing WildFly Modules in Maven Project - java

I want to put the following Maven dependency into my project.
<dependency>
<groupId>com.fasterxml.jackson.datatype</groupId>
<artifactId>jackson-datatype-joda</artifactId>
<version>2.9.9</version>
</dependency>
This dependency is dependent upon the following:
com.fasterxml.jackson.core:jackson-annotations:2.9.0
com.fasterxml.jackson.core:jackson-core:2.9.9
com.fasterxml.jackson.core:jackson-databind:2.9.9
javax.servlet:javax.servlet-api:3.1.0
joda-time:joda-time:2.7
I then want to deploy my application to a WildFly 8.2.1 server. While my particular dependency isn't provided by the server, its transitive dependencies are (under modules/system/layers/base).
com/fasterxml/jackson/core/jackson-annotations/main/jackson-annotations-2.4.1.jar
com/fasterxml/jackson/core/jackson-core/main/jackson-core-2.4.1.jar
com/fasterxml/jackson/core/jackson-databind/main/jackson-databind-2.4.1.jar
javax/servlet/api/main/jboss-servlet-api_3.1_spec-1.0.0.Final
org/joda/time/main/joda-time-1.6.2.jar
Upon running the application, I get an error due to the databind dependency. My datatype dependency references a field in databind that did not appear in version 2.4.1. So I need to get the databind dependency up to 2.9.9.
Idea 1: Manually Include the Dependency
I tried manually including the updated dependency in my pom as follows (hoping it will override the WildFly version).
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
<version>2.9.9</version>
</dependency>
Result: Same error occurs.
Idea 2: Exclude the WildFly Version with jboss-deployment-structure.xml
I added a src/main/webapp/WEB-INF/jboss-deployment-structure.xml file with the following contents.
<jboss-deployment-structure>
<deployment>
<exclusions>
<module name="com.fasterxml.jackson.core.jackson-databind" />
</exclusions>
</deployment>
</jboss-deployment-structure>
Result: Same error occurs.
Idea 3: Change WildFly Module
I add jackson-databind-2.9.9.jar directly to the WildFly module and update the corresponding module.xml to use the new JAR.
Result: Works. However, I do not want to do this as I want other developers to be able to use a fresh WildFly install without having to change anything.
Idea 4: Revert to Previous Version
I revert my original dependency to be in line with the WildFly versions of 2.4.1 as follows.
<dependency>
<groupId>com.fasterxml.jackson.datatype</groupId>
<artifactId>jackson-datatype-joda</artifactId>
<version>2.4.1</version>
</dependency>
Result: Works. However, a bunch of pre-existing code relies on the version being at 2.9.9 so I don't want to go backwards in the versioning.
Why is WildFly ignoring my attempts to override it's module? Is it possible to force the use of databind version 2.9.9. Thanks in advance for any help.

Related

spring-security-core conflicting version issue in build tree

I am trying to install spring-security-core to my project and here's how I am doing it in my pom.xml
<dependency>
<groupId>org.springframework.security</groupId>
<artifactId>spring-security-core</artifactId>
<version>5.0.7.RELEASE</version>
</dependency>
The issue is that when I build the project I see org.springframework.security.spring-security-core with version 4.2.9.RELEASE in my artifacts instead of 5.0.7.RELEASE. My pom.xml is deep down in my build tree and it's a part of a big spring boot project. artifact spring-security-core is not present in any other pom.xml in my tree.
From what I've read so far it looks like this is happening because something in the parent tree is downloading spring-security-core 4.2.9.RELEASE as a dependency without explicitly mentioning it in their pom.xml. How to debug this problem ?
In one of the parent pom.xml there's a dependency like this :
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context-support</artifactId>
<version>4.3.22.RELEASE</version>
</dependency>
Would that explain why spring-security-core old version is getting downloaded ? Any help is appreciated.
Check the dependency tree with this command
mvn dependency:tree
If spring-context-support also has spring-security, you can exclude that from the dependency by adding exclusions
example
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context-support</artifactId>
<version>4.3.22.RELEASE</version>
<exclusions>
<exclusion>
<groupId> groupid of the jar to be excluded </groupId>
<artifactId>artifact id of the jar to be excluded</artifactId>
</exclusion>
</exclusions>
</dependency>
Go to the location of parent pom.xml file and as run the command
mvn dependency:tree >> tree.txt
It will create a file with dependency tree. Search for "spring-security-core" you will find which version is downloaded.
There are couple of work around:
You can repeat this to each pom.xml as well to know from where it gets the reference.
If one of the pom referring the version then your dependency will not consider if its got resolve earlier.
Check if any po.xml file referring to any spring security related libraries. If so, what is there version. And if you need then as mentioned by #Vinay, exclude it so your library version gets referred.
If you want to download this version of library then mentioned it at the top, so it gets referred and no other version will downloaded.
There is no relation for spring security with spring-context-code. Refer this maven link.

Maven: Resolve dependencies using container dependencies first

I have a plugin project which is added to other container projects as a dependency.
Now, this plugin project uses many frequent dependencies like spring-security, commons-lang, etc.
Usually, the container projects contain their own versions of such frequent dependencies. So, when we add our plugin dependency there are conflicts and the dependencies are resolved based on regular maven dependency resolver and depending on scopes and optional tags provided in the plugin project dependencies.
Is there a way where all the dependencies are resolved using the version in parent dependencies first and iff they are not available then use the version specified in plugin dependency.
Note: optional and scope runtime have a problem that these dependencies are provided by the container and thus beats the aim to provide a hassle-free single dependency to add plugin dependency.
In your plugins pom define the version of a dependency as range of the versions you know the plugin to be able to use. If a container-dependency overlaps this will be used. If no overlapping version, of the dependency both container and plugin need, can be found, an error will be produced, since the negotiation failed.
Use no special scope for the dependencies, since you want them to be included if necessary into the container,
See:
https://maven.apache.org/enforcer/enforcer-rules/versionRanges.html
And:
https://books.sonatype.com/mvnref-book/reference/pom-relationships-sect-project-dependencies.html#pom-relationships-sect-version-ranges
Assuming that your container and plugin projects use the same parent pom you could utilize the <dependencyManagement> section in the parent to define the common artifacts. This allows you to omit the version in the plugins <dependencies> section.
parent:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>group-a</groupId>
<artifactId>artifact-a</artifactId>
<version>1.0</version>
</dependency>
</dependencies>
</dependencyManagement>
plugin/module:
<dependencies>
<dependency>
<groupId>group-a</groupId>
<artifactId>artifact-a</artifactId>
</dependency>
</dependencies>
See https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html for further details.
you can exclude it when you build a plugin project and add a dependency to maven.
This is an example. Dependency and main project have conflicted due to logging library. Below is to exclude log4j in dependency project.
<dependency>
<groupId>org.apache.zookeeper</groupId>
<artifactId>zookeeper</artifactId>
<version>${zk.version}</version>
<exclusions>
<exclusion>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
</exclusion>
</exclusions>
</dependency>
P/S: Added from my comments:
I have also developed a system which has a similar architecture with yours. I separate this system into 3 main parts: 1. Commons which contains common code and required maven dependencies, 2. The main project, 3. plugin project. You can refer this.

Compatibility issue between the 'groovy-all' jars present in eclipse plugin and maven dependency

In my POM, there is a dependency: spock-core 1.0-groovy-2.3, which adds groovy-all 2.3.10 to my project. And, my eclipse groovy plugin contains groovy-all 2.3.7 jar. So, whenever I try to run my groovy spec file, following error is thrown:
groovy.lang.GroovyRuntimeException: Conflicting module versions. Module [groovy-all is loaded in version 2.3.7 and you are trying to load version 2.3.10
So, inorder to match the jars I am left with two options:
Downgrade the version of spock-core dependency
Upgrade eclipse plugin groovy-all jar to 2.3.10
First option is NOT possible as there is no such spock-core dependency which could provide me groovy-all 2.3.7 jar. So, please guide me as how I should upgrade my groovy eclipse plugin from 2.3.7 to 2.3.10.
P.S. I have set groovy compiler level as 2.3 for my project. And, I am facing the same issue on Luna, Kepler, Juno eclipse.
You can "downgrade" the Spock dependency. Simply add an exclude of "groovy-all" to your Spock dependency. Then explicitly add a dependency on groovy-all 2.3.7
The exclusion can be added as follows:
<dependency>
...
<exclusions>
<exclusion>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-all</artifactId>
</exclusion>
</exclusions>
...
</dependency>
Update your POM file by adding the below maven repos:
<!-- Below 3 GROOVY dependencies are MUST to waive the version conflict in runtime
https://mvnrepository.com/artifact/org.codehaus.groovy/groovy-all -->
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-all</artifactId>
<version>2.4.16</version>
</dependency>
<!-- https://mvnrepository.com/artifact/org.codehaus.groovy/groovy-xml -->
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-xml</artifactId>
<version>2.4.16</version>
</dependency>
<!-- https://mvnrepository.com/artifact/org.codehaus.groovy/groovy -->
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy</artifactId>
<version>2.4.16</version>
</dependency>

maven dependency without version

Recently I've been working on some improvements in a project developed some time ago, and here's what I found. A lot of dependencies in the pom files go without versions specified, and yet they are resolved. The project consists of 1 root module and 2 submodules. The Aggregator pattern is used, meaning there's no dependencyManagement section at all. The upper-project simply aggregates 2 modules and that's all it does. Subprojects don't refer to it as to a parent. They have a different parent. What I can't grasp is that neither subprojects themselves nor their parent(as a matter of fact, it doesn't have dependencyManagement either) specify versions for some of the dependencies. For instance:
<dependency>
<groupId>javax.mail</groupId>
<artifactId>javax.mail-api</artifactId>
</dependency>
<dependency>
<groupId>com.sun.mail</groupId>
<artifactId>javax.mail</artifactId>
</dependency>
<dependency>
<groupId>com.sun.mail</groupId>
<artifactId>imap</artifactId>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jcl-over-slf4j</artifactId>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jul-to-slf4j</artifactId>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
</dependency>
Can someone help me figure this out? Is maven handling versioning with some default strategy? What is that default strategy?
Ok, I think I'm gonna answer it myself. Of course I took a look at dependency:tree, but all the dependencies that I mentioned were first-level members of the tree. What I failed to notice right away, is that dependencyManagement is not present in the parent, but it is however present in the submodules, and what is more interesting it contains:
<dependency>
<groupId>io.spring.platform</groupId>
<artifactId>platform-bom</artifactId>
<version>1.0.2.RELEASE</version>
<type>pom</type>
<scope>import</scope>
</dependency>
I've never used Spring IO Platform before, so this is a totally new concept for me. As it turns out the platform includes quite a few preconfigured dependencies:
http://docs.spring.io/platform/docs/current/reference/htmlsingle/#appendix-dependency-versions
It is impossible for maven to work without defining versions of the artifacts. They should be defined somewhere in dependencyManagement tag either in the submodule or parent. Please check your pom hierarchy. Use mvn help:effective-pom in the submodule directory of the project. Also you can use mvn dependency:tree in order to find out which artifacts - along with full artifact information including version numbers - are resolved in the result of dependency management.
Use
mvn -P<my_profile_of_interest> help:effective-pom -Dverbose
Verbose mode (Since: 3.2.0) adds XML comments containing precise reference to a place where dependency declaration is coming from.
Each maven dependency defined in the pom must have a version either directly or indirectly for example, through dependencyManagement or parent. That being said, if the version is not given, then the version provided in the dependencyManagement or the parent pom will be used.
For example: in the pom (only important sections are mentioned) given below, no version is provided for the artifact jstl. However, in the "mvn dependency:tree", it shows that jstl version 1.2 is included. And looking at the spring-boot-starter-parent, for the version 2.3.3.RELEASE pom, it includes jstl version 1.2.
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>1.3.3.RELEASE</version>
</parent>
<dependencies>
....
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>jstl</artifactId>
</dependency>
....
</dependencies>
In my case if i was using Spring boot starter parent to manage all dependency and lombok version is managed by Spring boot , This problem was coming due to higher java version JAVA 11 . I exported JAVA 8 in to my compile time environment and after using JAVA 8 this problem was gone.

Incompatibilities between modules (spark and jetty) using maven

I'm creating a program that uses spark and jetty libraries. The dependencies are managed by maven.
The problem is that some Classes are not found if bot dependencies are defined. Specifically org.eclipse.jetty.server.ServerConnector. There are no problems with other classes. If I remove the spark-core dependency, all work correctly. Why can this happen?
My example is based on this repository and the error can be reproduced adding the spark-core dependency to the "javax.websocket-example" project
I have tried with different versions of spark-core and jetty- websocket:
spark-core (2.10 and 2.11): 1.2.0 and 1.2.1
Javax.websocket-example: 9.3.0.M1, 9.2.7.v20150116 and 9.1.5.v9.1.5.v20140505
Maven dependences:
<dependency> <!-- Spark dependency -->
<groupId>org.apache.spark</groupId>
<artifactId>spark-core_2.10</artifactId>
<version>1.2.0</version>
<!--<scope>provided</scope>-->
</dependency>
<dependency> <!-- Jetty dependency -->
<groupId>org.eclipse.jetty.websocket</groupId>
<artifactId>javax-websocket-server-impl</artifactId>
<version>9.2.7.v20150116</version>
<!--<scope>provided</scope>-->
</dependency>
EDIT:
More information: I have reproduced the error in an empty scenario using vagrant. The box used is this. I have installed maven, git and oracle Java using this manual. I have done the test with "javax.websocket-example" project of this repository.
In this test, the project runs without de spark-core dependency and it doesn't run with the dependence. The version used of the dependency is the last, and I have tried with the project jetty version and with the last of the 9.2.X (9.2.7.v20150116)
DEPENDECIES:
<dependency>
<groupId>org.apache.spark</groupId>
<artifactId>spark-core_2.10</artifactId>
<version>1.2.1</version>
</dependency>
This is a dependency problem between the same library with different versions. (spark uses 8.1.XXX and my module uses 9.XX). The dependency cannot be excluded because is used in the modules. Then, this problem is a Java dependency problem and there is not solution without other technologies like OSGi
I Asked similar question here

Categories

Resources