In my pom.xml I have this excerpt to override lift's default mailer:
<dependency>
<groupId>javax.mail</groupId>
<artifactId>mail</artifactId>
<version>1.4.4</version>
</dependency>
<dependency>
<groupId>net.liftweb</groupId>
<artifactId>lift-util_2.9.0-1</artifactId>
<version>${lift.version}</version>
<exclusions>
<!--Using mail 1.4.4 instead-->
<exclusion>
<groupId>javax.mail</groupId>
<artifactId>mail</artifactId>
</exclusion>
</exclusions>
</dependency>
Works fine, the dependency tree shows no sign of javax.mail 1.4.1. But I'm still getting javax.mailer of version 1.4.1 in my m2 repository, when I start it with mvn jetty:run. I suppose, jetty uses 1.4.1. How do I override it? Complete pom.xml is here.
Ok, I've found the solution. Needed to add required version of javax mail to the <dependencyManagement> section:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>javax.mail</groupId>
<artifactId>mail</artifactId>
<version>1.4.4</version>
</dependency>
</dependencies>
</dependencyManagement>
Related
Trying to update log4j2 for legacy spring boot application (using Spring-boot-parent-1.5.6.RELEASE) - using multi module
Tried all the ways spring suggested in recent docs but none of them worked.
Options tried:
option 1 - Adding to properties
<properties>
<log4j2.version>2.17.0</log4j2.version>
</properties>
option 2 - adding starter-log4j2 and excluding core, later adding log4j core (latest)
<dependency>
<groupid>org.springframework.boot</groupid>
<artifactid>spring-boot-starter-log4j2</artifactid>
<version>2.6.1</version>
<exclusions>
<exclusion>
<groupid>org.apache.logging.log4j</groupid>
<artifactid>log4j-core</artifactid>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupid>org.apache.logging.log4j</groupid>
<artifactid>log4j-core</artifactid>
<version>2.15.0</version>
</dependency>
option 3 - just the above one along with log4j2 api
<dependency>
<groupid>org.springframework.boot</groupid>
<artifactid>spring-boot-starter-log4j2</artifactid>
<exclusions>
<exclusion>
<groupid>org.apache.logging.log4j</groupid>
<artifactid>log4j-core</artifactid>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupid>org.apache.logging.log4j</groupid>
<artifactid>log4j-api</artifactid>
<version>2.16.0</version>
</dependency>
<dependency>
<groupid>org.apache.logging.log4j</groupid>
<artifactid>log4j-core</artifactid>
<version>2.16.0</version>
</dependency>
But still the dependencies imported were slf4j-over-log4j(1.7.25), log4j(2.7, 2.11.1). Is there something else i could do.
Option 1 should work.
Build your project using mvn clean install
Check the contents of your jar file: go to your_project/target directory and run jar tf your-project.jarcommand. There should be only log4j-core-2.17.0.jar and no other versions of log4j-core
Edit: also update log4j-core version in your child modules
I am converting our Jenkins Freestyle build to Declarative Pipeline mode. I am using the same POM files.
But whenever i run the pipeline build, i see that the desired war is missing a transitive dependency. The Freestyle build includes that missing dependency however.
The Main parent POM includes:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>net.sf.dozer</groupId>
<artifactId>dozer</artifactId>
<version>5.5.1</version>
<exclusions>
<exclusion>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
</exclusion>
<exclusion>
<groupId>org.slf4j</groupId>
<artifactId>jcl-over-slf4j</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
</dependencyManagement>
The second parent includes section below, :
<dependencies>
<dependency>
<groupId>net.sf.dozer</groupId>
<artifactId>dozer</artifactId>
</dependency>
</dependencies>
For both build processes, the dozer artifact is contained in the war file. But dozer contains a dependency of its own:
<dependencies>
<dependency>
<groupId>commons-beanutils</groupId>
<artifactId>commons-beanutils</artifactId>
<version>1.9.1</version>
<exclusions>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
It is this commons-beanutils that I am missing from my final war when i do the Pipeline build. Since I am using the same POM files for both build processes, how can this be possible?
Please help
I am building a spring-boot application using an alternative to tomcat related stuff (jetty instead of tomcat and hikariCP instead of tomcat-jdbc) and want to exclude them from my dependencies written in pom.xml
I did that for 2 of the packages as shown below -
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
<exclusions>
<exclusion>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-tomcat</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-jetty</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-jpa</artifactId>
<exclusions>
<exclusion>
<groupId>org.apache.tomcat</groupId>
<artifactId>tomcat-jdbc</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>com.zaxxer</groupId>
<artifactId>HikariCP</artifactId>
<version>2.6.0</version>
</dependency>
But there is some dependency which is including tomcat-jdbc as part of it.
Is there a way to debug that and find out which dependency is including tomcat jdbc as part of it?
mvn dependency:tree
If you run mvn dependency:tree, you will see that there are now a number of additional dependencies.
I have below plugin in my pom:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jasperreports-maven-plugin</artifactId>
<version>1.0-beta-2</version>
<dependencies>
<dependency>
<!-- The dependency specified by the plugin doesn't work so we must provide our own -->
<groupId>net.sf.jasperreports</groupId>
<artifactId>jasperreports</artifactId>
<version>${jasperreports.version}</version>
<exclusions>
<exclusion>
<groupId>jfree</groupId>
<artifactId>jcommon</artifactId>
</exclusion>
<exclusion>
<groupId>com.lowagie</groupId>
<artifactId>itext</artifactId>
</exclusion>
</exclusions>
</dependency>
<!-- Groovy compiler seems to be required but not part of JasperReports' specified dependencies-->
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-all</artifactId>
<version>${groovy.version}</version>
</dependency>
<dependency>
<groupId>com.lowagie</groupId>
<artifactId>itext</artifactId>
<version>${itext.version}</version>
</dependency>
</dependencies>
</plugin>
The 1.0-beta-2 version of the above plugin points to jasperreports artifact of version 1.2.0, which in turn points to an open-ended commons-collections of [2.1, )
In 1.0-beta-2 pom:
<dependency>
<groupId>jasperreports</groupId>
<artifactId>jasperreports</artifactId>
<version>1.2.0</version>
</dependency>
And in jasperreports 1.2.0 pom:
<dependency>
<groupId>commons-collections</groupId>
<artifactId>commons-collections</artifactId>
<version>[2.1,)</version>
<scope>compile</scope>
</dependency>
In my case, there has been an push by someone else to a nexus repostiory, an artifact called 3.2.1-redhat-7 commons-collections.
jasperreports-maven-plugin is pointing to the above collections version which happens to be a corrupt one. There is a valid 3.2.1 version of commons collection. I need to exclude the jasperreports artifact and force the jasperreports-maven-plugin to use net.sf.jasperreports.
I have alread tried adding
<dependency>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jasperreports-maven-plugin</artifactId>
<version>1.0-beta-2</version>
<exclusions>
<exclusion>
<groupId>jasperreports</groupId>
<artifactId>jasperreports</artifactId>
</exclusion>
</exclusions>
</dependency>
to the above plugin, but it still points to the same 1.2.0 jasperreports that points to an open-ended commons-collections, and the build fails.
However if i comment out the dependency "jasperreports" in the jasperreports-maven-plugin.pom, it uses the jasperreports from net.sf.jasperreports and builds fine.
Please let me know.
Sorry for not really answering (can't comment yet due to lack of reputation), but:
1.
in case you are in a hurry the way i was,
here is a workaround, from
http://community.jaspersoft.com/questions/967926/issue-maven-plugin-codehaus-dec-9-2015:
You need to add
https://maven.repository.redhat.com/nexus/content/groups/product-ga
as one of your remote repos.
thanks a lot to joel.witham
2.
I think that this answer to
Maven dependency management for plugin dependencies
is most promising..i.e. don't exclude jasper-1.2 but make sure it's using the correct dependency version.
Try this configuration :
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jasperreports-maven-plugin</artifactId>
<version>1.0-beta-2</version>
...
<dependencies>
...
<dependency>
<groupId>commons-collections</groupId>
<artifactId>commons-collections</artifactId>
<version>3.2.1</version>
</dependency>
<dependency>
<groupId>jasperreports</groupId>
<artifactId>jasperreports</artifactId>
<version>1.2.0</version>
<exclusions>
<exclusion>
<groupId>commons-collections</groupId>
<artifactId>commons-collections</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
</plugin>
I'm building a parent POM for several modules. They are using Spring and Log4j2, so I want to define relevant configuration in section of parent POM and make use of new Spring BOM feature to avoid a mess with versions of Spring components.
According to documentation, this is the correct use of Spring BOM:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-framework-bom</artifactId>
<version>4.2.0.RELEASE</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
.......
</dependencyManagement>
Now, I need to exclude dependency on commons-logging from spring-core. This is the right way to do it, according to Spring docs:
<dependencyManagement>
.......
<!-- Remove JCL from Spring deps -->
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>4.2.0.RELEASE</version>
<exclusions>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
<!-- Add Log4j2 with JCL bridge -->
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-api</artifactId>
<version>${log4j2.version}</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>${log4j2.version}</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-jcl</artifactId>
<version>${log4j2.version}</version>
</dependency>
.......
</dependencyManagement>
Removing version number from the definition of spring-core dependency causes missing spring-core version error during compilation phase ('dependencies.dependency.version' for org.springframework:spring-core:jar is missing). Effectively, it requires me to re-specify Spring version number - something that Spring BOM was supposed to solve.
Do you know any way to make this work based on BOM version only?
Why don't you put the exclusion directly into the bom declaration:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-framework-bom</artifactId>
<version>${spring.version}</version>
<type>pom</type>
<scope>import</scope>
<exclusions>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
</dependencyManagement>
Or you could add commons-logging to dependencyManagement as well, if you want to directly control its version. This is what I did in a recent project:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-framework-bom</artifactId>
<version>${spring.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>${commons-logging.version}</version>
</dependency>
</dependencies>
</dependencyManagement>
The log4j jcl bridge does not replace the commons-logging jar. Leave it in. It just creates a binding between commons logging and log4j2.