The tile pretty much says it all.
I often deal with a project which depends on libraries A and B,
where A wants to pull in C version 1.0.0 and B wants to pull in C version 1.5.6.
Maven's default behavior seems to be that mvn package succeeds, including one or the other version of C on the classpath.
I would like to specify in my pom.xml that maven should refuse to build the project until one of the two C dependencies has been excluded.
Can this be done without first writing a new plugin?
The maven enforcer plugin should be able to check that, see Dependency Convergence here
Related
I'm trying to run some unit tests with Apache Maven. I hoped this would be as simple as running the test "goal". But when I did that, maven complained that it could not download some dependencies and thus can't run my tests. This sounds fine, except that I have no idea why it decided I need those dependencies; they are not in my pom.xml, and I doubt they're in my transitive dependencies either. (I'm not sure about that last part; they very well might be in my transitive dependencies.)
Luckily, maven has the perfect tool for this: dependency:tree will tell us exactly which dependency is getting pulled in by what. Except for the small problem that maven thinks to itself "in order to build the tree, I have to resolve the dependencies first" so it tries (and fails) to download those very same dependencies so that it can build the part of the tree that's under them.
So now I don't have a tree, and I have no idea how to proceed from here.
How exactly would you think that maven could resolve transitive dependencies (= dependencies of dependencies) without resolving the dependencies first? Escpecially for the goal "test" also the dependency scope "test" has to be used, which is more then the default scope "compile".
You can use the goal dependency:go-offline to prepare for the offline mode. Maven downloads then all required dependencies. Find the detailed docs for that on https://maven.apache.org/plugins/maven-dependency-plugin/go-offline-mojo.html
You could also have a look at this answer to get another opinion on going online.
The main problem is maven downloads dependencies by demand, you may just check that by triggering different lifecycle phases like mvn initialize, mvn validate, mvn compile, mvn package and checking what maven is trying to download. Sometimes it is possible to figure out project dependencies via analysing project object model (pom), sometimes it is not, especially when plugins define their own dependencies either implicitly or explicitly, some examples below:
we may ask maven-dependency-plugin to download something via dependency:copy-dependencies
exec-maven-plugin has similar functionality: Running Java programs with the exec goal
maven-invoker-plugin may run poms which are part of project but not a part of reactor.
In short: neither maven plugin will able to download all required dependencies. The only "reliable" way to go offline is to run target goal and only then go offline, unfortunately even in this cases some weird things may happen, especially when you or dependency authors are using snapshot versions, version ranges, third-party repositories, etc (my own preference is to run maven with -llr flag to make it more reliable).
I have several gradle projects in my eclipse workspace. For the sake of simplicity I'm only really interested in 2 of them, let's just use A and B for this.
So the problem I'm having is that Project A has an included dependency on JBoss, which pulls in javax validation-api 1.0.0.GA, and Project B has a dependency on javax validation-api 1.1.0.Final. Since Gradle itself resolves the conflict by using the newer library first, B is happy when built by gradle. But Eclipse itself includes errors which are very distracting while editing.
The correct version of the validation-api jar ends up in B's class path but the problem is that the Gradle IDE plugin changes the project(':A') dependency to a project reference, and Eclipse seems to give the project reference precedence over the external jar. So the old jar is preferred by extension.
I tried adding { exclude module: 'validation-api' } in B's build.gradle for the dependency on A which works according to the output of 'gradle dependencies', however since Eclipse just gets as far as making it a project reference, it won't exclude the jar and the problem remains.
Also per this question I tried adding { transitive = false } and the same thing happens. I don't think even the hack posed there would work for me since the .classpath contains a single reference to the Gradle container so there's nothing to remove.
I've managed to get around this by explicitly including a reference to the correct version of the jar from my gradle cache and then moving it above the Gradle Classpath Container so that eclipse sees that version first.
My question is: Is there a better/more generic way to do this? Preferably one that I can commit to source control without breaking other people's builds or requiring them to manually modify paths or properties somewhere? There is another project with what appears to be a similar issue so something I can fix in the build.gradle file would be awesome.
Worst case scenario, I could probably switch to IntelliJ if that behaves itself better than the Eclipse-Gradle integration?
These kind of transitive dependency issues are long-standing problem with Gradle Eclipse integration (both in STS tooling and also commandline generated .classpath metadata from Gradle's Eclipse plugin. The problem is the way that Eclipse computes transitive classpaths.
Only recently we found a reasonable solution to this problem. Actually there are now two solutions, one better than the other but depending on your situation you might want to use either of them.
The first solution is a bug fix that changes the classpath order of project dependencies so that they are no longer 'preferred' over jar dependencies PR-74. To get this fix you may need to install gradle tooling from a snapshot update site because the fix went in after 3.6.3.
This solution doesn't fix the real problem (you still have the 'wrong' stuff on the classpath) but just makes it less likely to cause real problem in your projects.
The second solution is to enable use of the 'Custom Tooling API model' PR-55 introduced in STS 3.6.3. This is a bit experimental and only works for recent version of Gradle, at least 1.12 but probably better to use 2.x. It also only works for projects that have 'Dependency management' enabled (if not enabled you are using the .classpath generated by Gradle's eclipse plugin which has the same 'broken' classpath issues as the STS tooling).
The 'custom tooling model' is really the better solution in principle as it fixes the way gradle classpath get mapped to eclipse projects so that project dependencies are no longer exported and each project gets its own classpath considering dependencies conflict resolution.
To enable this go to "Window >> Preferences >> Gradle" and enable checkbox "Use Custom Tooling Model".
Yes, this is a real question.
I want to cater for the following workflow in a multi module Maven based project:
Make a change in module X
Run a Java application in module Y
Module Y may directly or indirectly depend on module X, I need all modules affected by a change to another to be compiled, recursively. I do not want tests to be run.
How, in Maven, do I do this without having to compile and install everything every time?
Why do you have to make and install everytime? The easiest solution I've found is mvn install one time. Then you can go into individual projects and build them whenever you want. If you need to ensure the chain is picked up just do the build from the top and use mvn -amd -pl projectname
This says to build a specific project and it's dependencies.
Development stage
I don't think you could do it easily with the maven only. During development however you could skip tests adding -DskipTests.
The maven cannot do incremental compilation properly. The right way to do it is to use IDE which will import maven projects into IDE's projects and then you could have fast and easy development. IntelliJ IDEA works quite well with the maven.
Production stage
For release build you could use explicit versions in the target artifact. So after changes in module X if you building the final release artifact module Y you could add explicit dependency in it. In this case all modules between X and Y will have older version (but you should assume they will work with the new X which is always not true).
I have a strange situation. In jar A, I explicitly bring in version 1.3 of commons-dbcp. In jar B, I have a dependency on jar A. However, when I bring in the jar A dependency in jar B, my maven dependency hierarchy shows that jar B is now using 1.4. If I remove that dependency, commons-dbcp is gone from my maven dependency hierarchy so I feel certain it's not being pulled in elsewhere. And when I'm in jar A's maven dependency hierarchy, it only shows 1.3.
Does anyone have any idea why this might be happening?
Maven automatically determines the version to bring in for transitive dependencies. You may have more than one dependency on commons-dbcp (perhaps you're test wouldn't show it if they are in different scope). Use the Maven dependency plugin via mvn dependency:tree to see the other dependencies.
I'm in the process of learning maven (and java packaging & distribution) with a new oss project I'm making as practice. Here's my situation, all java of course:
My main project is ProjectA, maven-based in a github repository. I have also created one utility project, maven-based, in github: ProjectB. ProjectA depends on a project I have heavily modified that originally was from a google-code ant-based repository, ProjectC.
So, how do I set up the build for ProjectA such that someone can download ProjectA.jar and use it without needing to install jars for ProjectB and ProjectC, and also how do I set up the build such that someone could check out ProjectA and run only 'mvn package' for a full compile?
(Additionally, what should I do with my modified version of ProjectC? include the class files directly into ProjectA, or fork the project into something that could then be used by as a maven dependency?)
I've been reading around, links such as this SO question and this SO question, but I'm unclear how those relate to my particular circumstance. So, any help would be appreciated. Thanks!
So, how do I set up the build for ProjectA such that someone can download ProjectA.jar and use it without needing to install jars for ProjectB and ProjectC
Assuming ProjectA is a JAR, you can create an executable JAR that bundles the dependencies with the Maven Assembly Plugin (and the predefined jar-with-dependencies descriptor) or with the Maven Shade Plugin.
how do I set up the build such that someone could check out ProjectA and run only 'mvn package' for a full compile?
You have to deploy the dependencies to a repository that can be read over HTTP and to declare this repository in your pom.xml. AFAIK, git-hub doesn't offer any facility for that. But any web hosting service with FTP access (or better, scp) should do the trick. If your project is open source, another option would be to use Sonatype's OSS Repository Hosting service.
Just in case, you might want to read this blog post but you won't learn much more things.
The easiest would still be to organize the 3 projects as a multi-modules maven project and to build all modules.
Additionally, what should I do with my modified version of ProjectC?
From a modularization point of view (assuming you found a solution for the above part about repository), it would certainly make sense to have it as a separate module, especially if there is an opportunity someone can use ProjectC outside your project.
You have to publish the code from the additional dependencies. Two options:
Use the maven-shade-plugin to create a maven artifact containing all the content of the B and C jars, and publish that under your own G/A/V coordinates.
Publish copies of B and C under your own G/A/V coordinates using the maven-deploy-plugin to your forge just as you will publish your own code. Different forges have different policies; but if you abide by the licenses of B and C you should be OK.