Say I have two Maven dependencies defined in a project like below.
<dependency>
<groupId>com.thoughtworks.xstream</groupId>
<artifactId>xstream</artifactId>
<version>1.3.1</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>mycompany.library</groupId>
<artifactId>mylibrary</artifactId>
<version>1.0.1</version>
<scope>compile</scope>
</dependency>
Then, within mylibrary, I also have a dependency defined as below.
<dependency>
<groupId>com.thoughtworks.xstream</groupId>
<artifactId>xstream</artifactId>
<version>1.3.1</version>
<scope>compile</scope>
</dependency>
When I package my project, I don't see xstream packaged within it. I think the project's xstream dependency scope, 'test' is overriding the mylibrary's xstream dependency scope, 'compile'.
In this kind of situation, what's the best way to include the xstream for the whole project so the submodule can have access to it when packaged within the project?
I've read Apache Maven website's explanation on Transitive dependencies, but I'm struggling to understand what it means, and also to find out the best practice in this situation.
This feels really odd to me, and if it's "feature", I think it is a really dangerous one.
Anyway, it's not a Maven bug and it's in the maven documentation here.
Regarding best practices on this issue, I haven't heard of any, but the safest way to proceed ought to be to entirely remove xstream from your pom, relying on the transitive dependency. Doing this will result in a build failure if the dependency to mylibrary is removed. This will act as a notification to you that you need to fix something. You won't silently loose required dependencies, and you won't silently have dependencies you no longer need.
On a side note, mvn dependency:analyze can be used to check for dependencies that are included but not used.
As mattb's answer says, declaring the dependency as test scope overrides the transitive compile-scoped dependency declaration, and as a result the dependency is not included in your packaged war.
If you only need the dependency in your tests because 'mylibrary' needs it to execute, you shouldn't declare the dependency at all in your project's pom. Let the transitive dependency resolution process handle it.
If your project does use the xstream jar directly, you can still rely on the transitive dependency, as you will need a compatible version for your project and 'mylibrary' to both run against the xstream jar. You should have unit tests that exercise the functionality, and if mylibrary changes version of xstream to an incompatible version, your builds should fail, and you can address the issue at that point.
In general I'd say you should try to avoid declaring dependency versions directly in multi-module projects. I declare the versions in a dependencyManagement section of a parent POM so that the child need only declare the groupId/artifactId. Alternatively, from Maven 2.0.9 onwards there is an additional dependency scope of import:
This scope is only used on a dependency of type pom in the section. It indicates that the specified POM should be replaced with the dependencies in that POM's section. Since they are replaced, dependencies with a scope of import do not actually participate in limiting the transitivity of a dependency.
So using import scope you can define your common dependency versions in a single POM, import the dependencies of that POM into your dependencyManagement section, and just declare the groupId/artifactId of the dependency in your other POMs.
By declaring your own dependency on xstream, and setting the scope to test, you are overriding the dependencies declared by mylibrary.
This is actually a Maven feature - it allows you to do things such as depend on a later version of a transitive dependency within your own project, and not end up packaging two different versions of the same artifact. For example, you might depend on version 1.2.15 of log4j, but because you also use libraryX which depends on log4j-1.2.14 - you wouldn't want both log4j-1.2.15 and log4j-1.2.14 to be packaged with your project.
If you actually want xstream to be packaged within your project, you should not be declaring the scope as test. In fact if you remove your listed dependency on xstream, things will work out as you like, since mylibrary has a compile dependency on it..
If you want it packaged, why are you declaring scope? If it is required at compile and execution time, shouldn't you leave the scope blank? If you did that, then you would only need
<dependency>
<groupId>mycompany.modules</groupId>
<artifactId>submodule</artifactId>
<version>1.0.1</version>
</dependency>
in your pom. Unless there is a reason to descope it during compile but not during packaging?
Related
I came across this dependency in one project pom.xml:
<dependency>
<groupId>org.apache.maven</groupId>
<artifactId>maven-model</artifactId>
<version>3.3.9</version>
</dependency>
There is not much of detail on the page of maven-model project, but looks like it is just a definition (XSD) of pom schema and maven can obtain it without explicit declaration (as all other projects I've seen do not declare this dependency).
What could be the purpose of adding it explicitly?
It is a dependency which provides a Pojo model for maven files. You probably need it when you're writing a maven extension / plugin. I don't think it is useful for a "normal" project which happens to use maven.
I am running a java/spark project from IntelliJ idea (community 2019.2) on macbook pro.
I use maven.
The scope of dependencies of modules have four types:
compile
test
build
provided
When I build the modules, I always got the error:
Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/spark/api/java/JavaRDDLike
Or, other classes.
I have to change the scope of the dependency of the class from
provided
to
compile
But, there are so many dependencies, it is really boring to change them one by one.
Also, whenever I use
invalidate cache and restart
All setting for the scope will be reset, I have to repeat the scope setting.
How can I only need to change scopes for all dependencies only one time and make IntelliJ remember what I have changed for scopes?
Thanks
If you are using Maven you must not change the configuration of the dependencies and other project structure settings (like directories, compiler etc) in the IDE UI. You change it in Maven pom.xml file. So to set the dependency scope in Maven dependency configuration using <scope> element e.g.
<dependencies>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.14</version>
<scope>compile</scope>
</dependency>
</dependencies>
I have two Maven projects, A and B, where A depends on B at compile time, but at runtime B needs some classes of A.
What I did is:
A's pom.xml
<dependency>
<groupId>B</groupId>
<artifactId>B</artifactId>
<version>${B.version}</version>
</dependency>
B's pom.xml
<dependency>
<groupId>A</groupId>
<artifactId>A</artifactId>
<version>${A.version}</version>
<scope>runtime</scope>
</dependency>
When letting Jenkins compile the projects it fails to compile each other as a downstream project because it finds the circular dependency and avoid the infinite build loop.
So, what I thought is a way to add the A's runtime dependency only when packaging B (when Jenkins executes mvn package) so that Jenkins does not find the circular dependencies in the pom.xml files and configures the downstream compilation.
Is there any way to accomplish this with an existing Maven plugin or other way?
Thank you
I wrote this Maven plugin for the same reason.
It adds any listed JAR artifact to the WAR file where this plugin is used. JAR dependencies are resolved and added to the WAR file if not artifact with the same version is found.
The important thing is to define dependencies only inside the <dependency> POM section because that's the only configuration used by the Maven reactor.
If you fiddle with custom plugins to introduce your own dependency management ideas you will most likely break the reactor. Even if your custom approach works with regular mvn clean install it will usually explode when -T4 or similar option is used to enable multi threaded builds. There is simply no way to explicitly define the module build order in POM as it's governed by the reactor.
The usual way of sharing code between modules is to create a new module C which is depended on by both A and B.
I am not understanding what is the purpose of bom object? and I am working on Spring 3.2.8 version and with JBoss server, so which bom dependency I need to use? When I mention the following dependency in pom.xml:
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-framework-bom</artifactId>
<version>4.0.1.RELEASE</version>
<type>pom</type>
<scope>import</scope>
</dependency>
Does the jar file gets downloaded into my Maven Dependencies?
What is the purpose of bom object?
Maven parent-child relationship is very handy for managing dependencies of multiple projects in a single place. However, Maven projects can have only one (direct) parent. So imports were introduced for dependency management to allow using several projects for managing your dependencies. With an import you can define a single dependency like this and get multiple dependencies managed - handy! Although you could import any project, BOM is a special project designed to be used for imports like this. Usually a BOM project will have very little defined besides dependencyManagement section, and will not have any unrelated dependencies, to avoid affecting your main project too much.
Which bom dependency I need to use?
BOM is not a requirement, you don't need to use either. Instead, you could define all managed dependencies in dependencyManagement section yourself. These can include Spring, JBoss and any other dependencies. BOM, however, simplifies this for you significantly. You can add as many BOMs as you want, so add both! But as #Jesper mentions, don't forget to use correct versions. When using multiple BOMs their order will matter if they both reference a common dependency.
Does the jar file gets downloaded into my Maven Dependencies?
Notice BOM is <type>pom</type>, not the default jar. So there's no jar to be downloaded. A single pom.xml file will be downloaded and read by Maven.
I have a maven-java project (say Project A) with a parent defining modules in its pom.
I also have an external project (say Project B) that requires dependencies of two of the modules from Project A. For now, i have defined the dependency to pull each module individually.
When i replace these two with a dependency on the parent pom, it errors out on build. Is there some modification i need to make to my parent pom of Project A to make this work?
Can this be done in the first place?
Can this be done in the first place?
Declaring a dependency on an aggregating POM won't get the modules transitively. This is not going to work. It is possible to create a POM to group dependencies though.
For example, EHCache uses this technique. As mentioned in their documentation:
Maven Snippet
To include Ehcache in your project
use:
<dependency>
<groupId>net.sf.ehcache</groupId>
<artifactId>ehcache</artifactId>
<version>2.0.1</version>
<type>pom</type>
</dependency>
The net.sf.ehcache:ehcache artifact is precisely used to group dependencies (and is distinct from net.sf.ehcache:ehcache-parent).
References
The Maven Guide
3.6.1. Grouping Dependencies