To make the example as simple as possible, let's say I have classic Java EE 5 application.
Let's say I use x-lib in EAR module, and x-lib uses commons-io.
Also I use y-lib in WAR module, and y-lib uses commons-io too.
The EAR is set as provided in WAR.
The result I get is:
- app.ear
/lib
x-lib.jar
commons-io.jar
/app.war
/WEB-INF
/lib
y-lib.jar
commons-io.jar
I don't want commons-io to be packaged in app.war/WEB-INF/lib once it is packaged already in app.ear/lib.
In my war's pom.xml I have:
<dependency>
<groupId>my.group</groupId>
<artifactId>app</artifactId>
<type>ejb</artifact>
<scope>provided</scope>
<version>${project.version}</version>
</dependency>
<dependency>
<groupId>some.other.group</groupId>
<artifactId>y-lib</artifactId> <!-- This loads commons-io as compile dependency -->
<version>1.2.3</version>
</dependency>
Is there a way to tell maven that I want everything that is provided along with app ejb dependency should be set to provided and not included in WAR?
I do not want to track all those duplicated JARs and set them as provided or exclude explicitly one by one.
EDIT
I am aware of skinny-war solution. However I don't like the drwaback of duplicating dependencies in WAR and EAR. Maybe you know how to overcome this.
From the version 2.7 of the maven-ear-plugin, you can use SkinnyWars.
See here for specs: https://maven.apache.org/plugins/maven-ear-plugin/examples/skinny-wars.html
Basically, you can add the skinnyWars tag to your plugin configuration:
<plugin>
<artifactId>maven-ear-plugin</artifactId>
<version>2.10.1</version>
<configuration>
<defaultLibBundleDir>lib/</defaultLibBundleDir>
<skinnyWars>true</skinnyWars>
</configuration>
</plugin>
That SHOULD be automatic if you add the EJB module as a provided dependency to your war module and let all the dependencies of that EJB come transitively. So don't add the overlapping dependencies to your war pom, just let Maven deal with it.
Is there a way to tell maven that I want everything that is provided
along with app ejb dependency should be set to provided and not
included in WAR?
In this case a think the best option by now is to use wilcards in dependency exclusion.
It is only supported in maven 3.
Below is an example of how to declare the ejbmodule dependency from a war project:
<dependency>
<groupId>ejbModuleGroupId</groupId>
<artifactId>ejbModuleArtifactId</artifactId>
<scope>provided</scope>
<type>ejb</type>
<exclusions>
<exclusion>
<groupId>*</groupId>
<artifactId>*</artifactId>
</exclusion>
</exclusions>
</dependency>
You can use this same strategy when declaring a dependency to a ejb-client.
Depending on your maven 3 version, you'll get a nasty warning, but in newer versions it must be fine.
You need to add an exclusion like this:
<dependency>
<groupId>some.other.group</groupId>
<artifactId>y-lib</artifactId>
<version>1.2.3</version>
<exclusions>
<exclusion>
<groupId>commons-io</groupId>
<artifactId>commons-io</artifactId>
</exclusion>
</exclusions>
</dependency>
Related
I have a java spring boot application A that has dependency B which is a third party jar. B in turn has dependency C. When people need upgrade C (say from v1.0 to v2.0), a common approach is that in pom.xml of A, using Maven exclusion feature to exclude C from B, then either declare C-v2.0 as a direct dependency, or add C-v2.0 to dependencyManagement section.
This approach doesn't guarantee work in all situations. An example is org.glassfish.metro:webservices-rt:2.4.3 has dependency woodstox-core:5.1.0 which contains high security vulnerabilities and need to upgrade to 6.4.0.
My project A has (direct)dependency webservices-rt:2.4.3. Applying above approach doesn't exclude woodstox-core:5.1.0 from my project. Note: the maven dependency tree doesn't show woodstox-core:5.1.0 any more, but Aqua Scan still indicates that webservices-rt has dependency woodstox-core:5.1.0.
Below is part of my pom
<dependency>
<groupId>com.fasterxml.woodstox</groupId>
<artifactId>woodstox-core</artifactId>
<version>6.4.0</version>
</dependency>
<dependency>
<groupId>org.glassfish.metro</groupId>
<artifactId>webservices-rt</artifactId>
<version>2.4.3</version>
<exclusions>
<exclusion>
<groupId>com.fasterxml.woodstox</groupId>
<artifactId>woodstox-core</artifactId>
</exclusion>
</exclusions>
</dependency>
It seems to me that whether above approach working or not depends on how jar B is packaged. Dose anyone has knowledge to share?
The much better approach is to set the desired version in <dependencyManagement>, i.e.
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.fasterxml.woodstox</groupId>
<artifactId>woodstox-core</artifactId>
<version>6.4.0</version>
</dependency>
</dependencies)
</dependencyManagement>
Then you need no exclusions at all.
If the dependency tree does not show it, it will not be used, unless the dependency is a fat jar. So, avoid fat jars as dependencies (if at all possible), and furthermore check if your Aqua Scan maybe does it wrong.
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.
I sometimes see these following declaration in pom.xml...
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>jstl</artifactId>
</dependency>
<dependency>
<groupId>org.apache.tomcat.embed</groupId>
<artifactId>tomcat-embed-jasper</artifactId>
<scope>provided</scope>
</dependency>
....
as you can see, spring-boot-starter-web was declared as well
as tomcat-embed-jasper.
isn't it spring-boot-starter-web already have an embedded tomcat?
why some developers still declare tomcat-embed-jasper along with boot-starter-web? or is there any reason?
As you said, the spring-boot-starter-web includes the spring-boot-starter-tomcat. You could check it here
The spring-boot-starter-tomcat includes the tomcat-embed-core. You could check it here
But, seems like tomcat-embed-core doesn't include tomcat-embed-jasper. In fact, is tomcat-embed-jasper who includes dependency with tomcat-embed-core. Check it here
Anyway, the tomcat-embed-jasper is marked as provided, so indicates that you expect the JDK or a container to provide the dependency at runtime. This scope is only available on the compilation and test classpath, and is not transitive.
In conclusion, the spring-boot-starter-web includes the tomcat embedded dependency but it doesn't includes the jasper embedded dependency, so that should be the reason to declare it separately.
Also, remember that using Spring IO Platform as parent you are able to manage dependencies easily. To know more about this you could read my post
Hope it helps,
Extended from jcgarcia's answer.
Even it is provided, but when you build as war, spring-boot-maven-plugin will include two more jar :
ecj-3.12.3.jar
tomcat-embed-jasper-8.5.23.jar
To those who are still facing this error in 2022 with Java Version 17, Maven Version 3.0.0 and Package Jar. I also ran into the same issue just now, seems like even though we set <scope>Provided</scope> Maven is not picking up the jar. What you can do instead is just take that completely off while adding the dependency and run the Maven to install dependencies again. It will fix it for sure. So your pom.xml file will go:-
From
<dependency>
<groupId>org.apache.tomcat.embed</groupId>
<artifactId>tomcat-embed-jasper</artifactId>
<scope>provided</scope>
</dependency>
To
<dependency>
<groupId>org.apache.tomcat.embed</groupId>
<artifactId>tomcat-embed-jasper</artifactId>
</dependency>
I have 2 projects dependency-project, main, support. Currently, main and support requires dependency-project in its build path.
We plan on adding support as another dependency for main. Is there a way to build a jar for support, but not include in it any dependency (from dependency-project) and when support-jar is already added into main, all dependencies of support-jar will be resolved via the classpath of main (since they both have dependency-project as dependency.
You can do it as a compile-time scope. For example in pom.xml file for support
<dependency>
<groupId>org.something</groupId>
<artifactId>dependency-project</artifactId>
<version>1.2</version>
<scope>compile</scope>
</dependency>
And then in pom.xml for main:
<dependency>
<groupId>org.something</groupId>
<artifactId>dependency-project</artifactId>
<version>1.2</version>
</dependency>
<dependency>
<groupId>org.something</groupId>
<artifactId>support</artifactId>
<version>4.2</version>
</dependency>
This should solve your purpose.
I am new to Maven and am trying to set up one of my first POMs. My application will cache using EhCache. Going to Maven Central Repo (link here) I copy-n-pasted the <dependency> tag and copy it into my pom.xml like so:
...many dependencies above this point
<dependency>
<scope>compile</scope>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-entitymanager</artifactId>
<version>4.0.1.Final</version>
</dependency>
<dependency>
<scope>compile</scope>
<groupId>net.sf.ehcache</groupId>
<artifactId>ehcache</artifactId>
<version>2.5.0</version>
</dependency>
<dependency>
<scope>compile</scope>
<groupId>jasperreports</groupId>
<artifactId>jasperreports</artifactId>
<version>3.5.3</version>
</dependency>
...many dependencies below this point
When I save the changes, Eclipse builds the workspace and gives me an error on the opening <dependency> tag for EhCache 2.5:
Missing artifact net.sf.ehcache:ehcache:jar:2.5.0
So I figured that perhaps v.2.5.0 has something wrong with it, and repeated the same for 2.4.7 (the last 2.4.x release before 2.5.0). Same deal.
Since I'm so new to Maven, I don't even know where to begin looking. I tried Project >> Clean and even restarted Eclipse to see if it was just a typical Eclipse "quirk". Nope.
I am thinking:
Could EhCache be publishing bad JARs to the Maven repo?
Could Maven Repo have something wrong with it?
Could this be due to something else configured wrong in my pom.xml?
Could this be a "JAR hell" issue where I have a conflict somewhere on my dependency graph?
How would SO start tackling this problem? Thanks in advance!
It is usually safer to refer to search.maven.org. Dependency from there:
<dependency>
<groupId>net.sf.ehcache</groupId>
<artifactId>ehcache</artifactId>
<version>2.5.0</version>
<type>pom</type>
</dependency>
Mind type pom. From module's pom:
This is a pom artifact to pull in ehcache-core and ehcache-terracotta
for clustering. Make sure to set 'type' to 'pom' in your dependency.
Aparently when someone does not need terracotta, ehcache-core will do perfectly fine as other answer states.
They use ehcache-core in the official documentation. Maven Central does not have a jar artifact for ehcache 2.5 which explains your error message.
Using ehcache-core changes the dependency to:
<dependency>
<groupId>net.sf.ehcache</groupId>
<artifactId>ehcache-core</artifactId>
<version>2.5.0</version>
</dependency>
Which successfully downloads on my machine (ehcache does not).
I dropped this into IntelliJ and it found it. I suspect there is something wrong with your settings. Try creating a project with only this dependency in it. If it fails to download, I would check your setting. e.g. .m2/settings.xml Are you using a Nexus server or maven proxy/cache?
BTW: A simpler way to search for JARs is to use http://mvnrepository.com/ which will find all the available versions and show you the XML you need to add.