Apache Velocity needs commons-collections-3.2.1.
In my pom file I have added a velocity dependency. Everything works, but when I look in the overall pom file:
$ mvn help:effective-pom
I do not see an commons-collections entry.
I had expected it should be there. Or not?
No, not if you don't specify it directly. effective-pom shows the pomfile factored in with the eventually inherited definitions from the parent pom (ie. dependencyManagement, pluginManagement, properties and so on) and the profile.
To see the full list of dependencies, including transitive dependencies, you need maven-dependency-plugin, and
mvn dependency:tree
The effective-pom does not show you all the transitive dependencies, only the POM as it will be, given whatever parents, profiles etc. you have.
You may want to try mvn dependency:tree, which will show you the projects' direct and transitive dependencies as a tree, and notice that commons-collections will be somewhere under Velocity.
Cheers,
Related
Impact of exclusion in the context of jar packaging(simple/fat jar using shade plugin). What i mean here, how can it be verified by extracting the jar.
When a dependency is excluded, it is removed from the dependency tree at that point. You can check this with mvn dependency:tree. It might still come in through other ways (e.g. as transitive dependency of some other dependency). You can check that with mvn dependency:list.
I have a parent project(has its own pom.xml) in which I import the child project as a jar with its own pom.xml.
In the parent pom.xml I have specified my child jar as a dependency - this gets resolved, but i want maven to resolve the dependencies required by my child jar.
My Use case to replicate :
When I include spring-web-mvc.jar the transitive dependencies are resolved automatically.
I have a similar requirement where I include my child.jar into a main framework project and expect the transitive dependencies to get resolved (Notw: the child.jar is not hosted it is packaged as jar and present on the local file system)
Current Structure:
Child Project:
|----/src/main/java
|----/src/main/resources
|----child-pom.xml
>This child project will be a jar as dependency in the parent project
Parent Project
|----/src/main/java
|----/src/main/resources
|----/src/main/webapp/WEB-INF/lib/child.jar
|---- parent-pom.xml
The problem:
When i create a war from parent project i want all the dependecy including transitive ones to show in WEB-INF lib.
Currently this is not happening.
First when talking of parent/ child Maven projects normaly you have your"childs" specified as modules in a common parent project which itself is beeing packed with the packaging type pom rather than make them a dependency of the parent project.
When it comes to the dependencies of your "childs" or generally "dependencies of your dependencies" those are called transitive dependencies and are pretty well explained in the official documentation found here: http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
The resolving of those transitive dependencies is one of Mavens core strenghts and guaranteed by default unless they lead to conflicts that make the build fail.
Two things to help here are having a closer look into the enforcer plugin (http://maven.apache.org/enforcer/maven-enforcer-plugin/) and the shader plugin (http://maven.apache.org/plugins/maven-shade-plugin/) .... well and the official documentation of corse (reading the whole thing takes less than a day - then supports you further for specific topics whereas we gladly further support you too if you already have pom.xml files and you are stuck somewhere.
While the enforcer-plugin covers certain conflicts regarding different versions of the same artefacts the shader plugin will just pack everything you specified to a single jar for reverseengineering (its not the normal use case but i sometimes use it that way if i am not absolutly sure what ends in my final archives).
Also worth a look at is the dependency-plugin already available in the maven distributions - mvn dependency:tree -Dverbose will give you pretty detailed information on the resolved dependencies (and probably version conflicts).
I have a situation where in my EAR file I have 'N' number of JAR files[modules] present. In these JAR files, there are certain artifacts which are duplicate. By duplicate, I mean the artifact name is same but with different versions.
Ex:
adapter-base-59.0-20141219-311675-3.jar
adapter-base-60.0-20141223-678915-68.jar
I would like to get help on how to find the source pom file location for these JAR files.
Any help on this is highly appreciated.
Regards,
Deepan
that might be a bit painful but the dependency can be in a parent pom.xml, a transitive dependency or a profile. Profiles can be in a settings.xml as well.
What I would do is execute mvn dependency:tree on the pom.xml where the dependencies are copied and then search where it comes from. Then follow that path.
It is a little weird you have the same jar twice with a different version. Usually maven takes the first one (or closest one) it find. So adding the correct version to your pom.xml has a distance of 1, that would always win - any transitive dependency will have a greater distance.
It might be the dependency uses a different groupId and maven cannot detect its the same artifact.
You could also try to open the jar files - maven usually adds some information into the META-INF directory (if you're lucky and the jar was release with the maven-release-plugin).
Could somebody explain to me, what are are differences between the file pom.xml and the file effective pom.xml in an apache maven project?
The Super POM
All Maven project POMs extend the Super POM, which defines a set of defaults shared by all projects.
The Simplest POM
All Maven POMs inherit defaults from the Super POM. If you are just writing a simple project that produces a JAR from some source in src/main/java, want to run your JUnit tests in src/test/java, and want to build a project site using mvn site, you don’t have to customize anything. All you would need, in this case, is the simplest possible POM shown in The Simplest POM. This POM defines a groupId, artifactId, and version: the three required coordinates for every project.
The Effective POM
It is the merge between The Super POM and the POM from The Simplest POM.
NOTE: This info was extracted from the following link (in the link the explanation is very complete)
Maven: The Complete Reference - 3.2. The POM
You can see the difference of a pom.xml and the effective pom.xml using
mvn help:effective-pom
which is describe here.
In a multi module project you'll use a parent pom.xml for defining general settings for all modules and then in each module there will only be specific settings.
The above goal will help you analyze the resulting pom that you could of course actually use instead of the parent reference.
The whole idea is by using the generalization (super-pom) / specialization (module pom) approach there is a central place where you can specify the general configuration. This is much more efficient then having to cut&paste the general parts.
Please also note that the effective pom will add the default behavior e.g. for the jar plugin so that you can debug issues like
Maven JAR Plugin 3.0.2 Error: You have to use a classifier to attach supplemental artifacts to the project instead of replacing them
with this approach. See also Maven `help:effective-pom` only generating for a single project, not all projects
I'd like to mvn install:install-file artifact A excluding artifact X.
A does not depend directly on X, yet down the dependency tree there are several dependencies for X.
What would be the command to perform this?
If you just run install:install-file on a jar file without -DpomFile=something, it will create a pom with no dependencies, so there's nothing to exclude. The 'X' dependency won't be represented at all.
If you pass in a pom file via -DpomFile=POMFILE, then you have the dependency structure in there, and it can include whatever exclusions you need. If you put in a dependency on X, and it in turn depends on Y, you can add an exclusion to the X dependency.
A comment from the OP suggests that this has nothing to do with install:install-file.
There is some artifact 'A' with a rich and complex dependency tree, which transitively reaches some artifact 'B' at many points. How do cope with B not being available if, in fact, it's not actually needed in the classpath?
The only solution here is to add exclusions to the POMs that reference A. Instead of trying to change the pom of A to exclude B, you have to add the exclusion of B in your own poms as part of the dependency on A. There's no other way.