I was going to migrate an old Ant project existing of multiple single java projects to a multi-module maven project. All the libraries for have been stored in one local folder.
For building up the dependency management I wanted to go the way to add all dependencies to the parent pom.xml (dependency management section) and also do my best by adding the correct ones to the children (Java Maven projects) until compilation is working.
I then want to streamline the pom.xmls by using "mvn dependency:tree -X" to see if I have added some transitive dependencies to the single Maven projects which aren't not needed to be explicitly added to the pom.xmls
Now when comparing the dependency hierarchy for a Maven project shown in Eclipse with that shown by using "mvn dependency:tree -X", there are some differences:
Maven will not show that "jetty-http" is actually a transitive dependency of jetty-server - mostly because I already added it as direct dependency in the pom.xml before.
While Eclipse does show that relationship and this is the correct result (also checked it manually using Maven central dependency list).
So in the end when using Maven I would have left "jetty-http" as direct dependency in my pom.xml, although I don't have to. This is kind of useless.
Does anyone know why the Maven dependency tree is so limited? I want to understand what is going on here. Is there any alternative using Maven commands?
Or is there even a better way to check for/identify transitive dependencies added to the pom.xml by mistake?
Best practise is to add all dependencies to the POM that are used directly in your source code (and at runtime).
So if X is used in your source code, but is already present as transitive dependency of Y, you should nevertheless add X as direct dependency.
You can check this with mvn dependency:analyze
https://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html
Related
suppose I have a project say A which is dependent on B. so when I build project A. does maven generates the artifact of A by bundling with project B artifact?
and suppose if project B is dependent on C. then when I build project A, will it by default takes the transitive dependency c to generate the artifact? and even if it takes, what will happen if I add C as a dependency in project A pom.xml? will maven takes the C artifact for two times to build A and generates a bigger artifact file?
what will happen if I add C as a dependency in project A pom.xml?
If C's dependency has already been resolved, maven will simply ignore it if it is declared elsewhere.
will maven takes the C artifact for two times to build A and generates a
bigger artifact file?
No.
Please check https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Transitive_Dependencies for more details.
Transitivity brings a very serious problem when different versions of the same artefacts are included by different dependencies. It may cause version mismatch issue in runtime. In this case, dependency:tree command is very useful in dealing with conflicts of JARs.
$ mvn dependency:tree
Check https://howtodoinjava.com/maven/maven-dependency-management/#dependency-tree for more details.
this question is a little bit broad, things can change a little with you start to talk about Maven multi-module projects (so there is a parent-child relationship between modules). I will assume that multi-module setups are off-topic for this question.
Also: IDEs have tight integration with Maven and might add additional automatic processes on top of it. I assume this is plain Maven as it would work from a shell.
finally: there is a big difference from working with dependencies you pull in from the internet and projects you are building yourself with Maven. I am going to limit this answer to only building your own projects when it comes to dependency management. Otherwise I'd be writing the Maven manual here.
suppose I have a project say A which is dependent on B. so when I
build project A. does maven generates the artifact of A by bundling
with project B artifact?
Maven will include whatever you put in the dependencies listing; if it cannot it will fail the build. If project B is your own project, it will not automatically build B for you when you are building project A, it will only try to include whatever jar is already in your local maven repository. If there is no jar in your local repository, it will try to download it from all the Maven repositories that are known within the project. This will fail if Project B is just a project living on your harddrive, the only way then to make the jar of Project B available for usage in Project A is to actually build and install Project B first so a copy of the jar is put in your local maven repository.
Similarly if project B changes but you do not change its Maven version number, it is your own responsibility to rebuild and install it so the existing jar in your local maven repository gets overwritten.
It is possible that the dependency jar of B is pushed to a remote repository; it could be that your company is hosting or licensing a Nexus or an Artifactory for example and development builds are pushed to a snapshot repository so it can be used by several developers on different machines without them having to checkout the project and build it on their own machine. Then it depends on how Maven is configured if it will eagerly download updated versions of the jar when building project A. If you are working with a remote repository and you suspect that during the build an older version of a dependent jar is being used, this existing question's answers detail a few ways to force dependency jars to be updated when they were already downloaded before. But you should hardly ever need to use that.
and suppose if project B is dependent on C. then when I build project
A, will it by default takes the transitive dependency c to generate
the artifact?
Yes it will walk the entire dependency tree and include all transitive dependencies.
and even if it takes, what will happen if I add C as a
dependency in project A pom.xml? will maven takes the C artifact for two times to build A and generates a bigger artifact file?
Well first of all: dependencies are not included in the jar of project A by default so the size of the jar does not depend on the number of dependencies the project has. You would have to specifically use a plugin that has this functionality, often called "one jarring", "creating a fat jar" or creating an "uber jar". The Maven Shade plugin is a common way to do this.
Regardless, Maven does not allow multiple copies of the same dependency groupId+artifactId pair to exist on the classpath and will filter out duplicate copies when it finds them. This also happens when you add the same artifact multiple times within the same pom, Maven will call you out on it and include only one copy.
So no, in the end there will be only one copy of C.jar. Even if the pom of A refers to C version 1.0 and the pom of B refers to C version 1.1.
How to properly set up maven-shade plugin in a multi-module maven project setup?
storyline
A (https://github.com/DataSystemsLab/GeoSpark) has a dependency on B (https://github.com/jiayuasu/JTSplus) is a fork of C (com.vividsolutions.jts)
Now for some tasks in my project I need to use D (http://www.geotools.org) which depends on another Version of com.vividsolutions.jts.
How can I use both jars in a single project? A simple dependency replacement unfortunately does not work here. Shading should be the solution.
first attempt - shading the parent pom
When I try to apply the maven-shadeplugin to the root pom of https://github.com/DataSystemsLab/GeoSpark/blob/master/pom.xml as outlined Using Maven shade plugin in a multi module project - NullPointerException a null pointer exception occurs
multi project setup
When following How to configure Maven shade plugin in a multi-module project? to set it up for a multi module build the maven build compiles at least. However, the generated jar is lacking the actual code of the geospark module. I can't see where this would be filtered.
My changes are available https://github.com/geoHeil/GeoSpark/commit/23d212aeeeacad8b7199da69366d583fc48edcf0
With the main changes being:
introducing a third module FinalModule
shading only enabled there replacing com.vividsolutions.jts with com.vividsolutions.jtsgeospark
Indeed, disabling magnification is the solution. Otherwise probably explicitly including desired artifacts would work as well.
I want to see the dependency tree of a project without actually downloading those dependencies.
I have a project whose build fails because there is some dependency which is not present in central repo, however it is not a direct dependency and I am not aware which one of my dependencies refers to it.
Now when I run mvn dependency:tree command, it builds the project and hence fails.
One way to do it is keep a dummy jar in local repo with the same name. It will not try to download the dependency and generate the entire tree. However is there any other way to do this ?
If you are using eclipse there is a "Maven POM Editor", which shows not only the maven XML, but also a dependency hierarchy view.
A working build is not necessary for it, just a correct POM XML file.
It should get installed, when you install the eclipse m2e plugin.
The update site is http://download.eclipse.org/technology/m2e/releases.
Maybe Maven dependency:analyze-only
mvn dependency:analyze-only
Analyzes the dependencies of this project and determines which are: used and declared; used and undeclared; unused and declared. This goal is intended to be used in the build lifecycle, thus it assumes that the test-compile phase has been executed - use the dependency:analyze goal instead when running standalone.
or dependency:resolve:
mvn dependency:resolve
mvn dependency:tree -DoutputFile=tree.txt
I have a java maven project that has another module as a dependency.
That dependency has "-sources.jar" in the repository (and I can download the sources with mvn dependency:sources)
I now need to do some little one-line changes in the module I am using as a dependency. The ideal way would be to somehow copy this dependency as another module, with all its current sub-dependencies. Then when I build the whole project, I want to build my newly copied dependency and use it instead of the current dependency. (I hope it's clear what I want to do.)
However, I don't know at all how to do that, and if it's even possible.
edit:
To be clearer.
I have my own project. I am also using let's say com.example.dependency from a repository. There are however small bugs in the com.example.dependency module, so I want to download the source to me and fix it locally and use it as a submodule.
edit2:
I will add that the dependency is not any public project on github, etc. It is a module in a private maven repository that only I have an access to. I cannot clone the source control project. I can only use maven, and its dependency tracking, and the "dependency:sources" thing.
what you may to to do is to checkout your dependency source as new project and do the changes. Then modify your project version and do the
mvn install
to install it in your local repository, then you this version in your project as one of the dependency, you will add this dependency in usual way you have done earlier, but change the version to new version you have installed.
In Eclipse, expand current project in project explorer,
click Java Resources -> libraries -> Maven Dependencies
And I found there are two jar files which in different version, i.e.:
commons-lang-2.1.jar
and
commons-lang3-3.1.jar
but from pom.xml, I cannot tell where commons-lang-2.1.jar come from as it must required by one of the artifacts. But it is too much trouble to check pom file from each artifact...
I heard of dependency-tree can work something similar but don't know how to make it work under this situation. Any hint is appreciated.
mvn dependency:tree
Look for the two instances of commons-lang and see what requires them.
That said, the two versions aren't compatible, and can live in the same application:
http://commons.apache.org/proper/commons-lang/article3_0.html
See this answer of mine regarding deciphering the tree output. The nutshell is that indented libraries are dependencies of the non-indented library above it: a dependency tree.
execute
mvn dependency:tree
if you have very giant dependency tree and hard to read you can use
mvn dependency:tree -Dincludes=org.apache.commons:commons-lang3
to just include occurrence of this artifact
from your pom.xml it will list out all the dependencies being pulled directly or indirectly, and put the <exclusion> to avoid consumption of non desired library