I am trying to build a project containing multiple modules, one of which is a maven plugin which we use to generate sources further down the tree as such:
Module A: generator-plugin
Module B: uses generator-plugin
But when I try to build the parent project (doing a mvn clean deploy) during the clean phase, it tries to resolve the generator-plugin, which is obviously before it's built it.
Is there a way for this to be done without separating out the modules and building it first manually?
With Maven, I would suggest doing the most straightforward thing which would work and I think you know what that is--just make these two things separate Maven projects.
Related
I have a question about how the Maven dependency resolving mechanism is working in a multi module project.
Normally I only use 'mvn clean install' when I build my multi module projects and my assumption was that if any module in the project needs a previous module, dependency will be resolved by going local repository and loading the corresponding 'jar'.
For project internal reason, I have to use 'mvn clean compile,' this command naturally does not create any 'jar' while 'install' is not there. So here I started wondering, how the dependency resolution for a multi module project works, while jar' is not created but project still able to see the changes from the previous builds. Does the target directories used for dependency management?
Or for 'mvn clean compile' target directory used but for 'mvn clean install' the local repository.
Can anybody explain me how the dependency resolution works in a 'multi module' project.
Thx for answers.....
I think you will understand better if you look at https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
There is a life cycle in the process of building the jar. The compile target will compile the code and create a complete classes folder in your target directory. This target will resolve all your dependencies in your poms and download any dependencies to your local repo, not already there.
The install target will create the jar from the classes directory and install it in your local repository.
I really think you will need to run the install target to get anything useful.
Maven is made of separate components.
There a component that deal with a given module and among other things try to get its dependencies. It ALWAYS get the dependencies from the local repository, eventually after having downloaded such dependencies. If the dependencies are not there and can't be dowloaded, it will fail. Eventually the module will create its own artifact that it will publish to the local repo.
Then there a compoment that when you ask it to build several maven modules, for example calling mvn at the root of a project does order the various module use the dependencies to find the best ordering for the build so that if a given module depend on another, it will be build after the module it depend on. It then call the previous compoent I described, building each module in order.
In all cases, a given module dependencies are always taken from the local repo. The expectation is that the previous modules that were built before actually pushed their artifact to the local repo typically with the mvn install but you could force it do it at any step thanks to proper configuration (may not be a good idea).
In all case if the previous component jar was not built and put into the repo, there no way such jar can be added in the classpath for the next module to be compiled.
Doing compile only on multiple projets isn't going to be any useful.
After working with Maven for a while, I am thrilled by the many features that Maven brings into the build architecture, particularly the dependency management. However, I have run into one issue again and again - how Maven resolves dependencies between multi-module projects. I am wondering if this is the big flaw of the current Maven implementation and/or if there is any satisfactory workaround.
Let's say I have a multi-module Maven project. The Parent pom contains three modules -- moduleA (jar), moduleB (jar), and moduleC(war). B depends on A and C depends on B. Simple enough? Now that I want to run the mvn dependency:go-offline at the parent project, which is supposed to resolve all the dependencies and bring them into the local .m2 directory. It fails because Maven complains that it cannot solve dependency for moduleA when it is acting on moduleB. Because all these modules belong to one groupId, I even try to use -DexcludeGroupIds=x.y.z to exclude these module dependencies, but it still fails at the same point.
I understand why Maven is complaining - moduleA is not built yet and thus there is no moduleA:jar artifact in my local or internal repository when go-offline goal is executed. But IMHO the plugin should treat these inter-module dependencies differently. In this case, it should simply ignore it. One might argues that I can simply do mvn clean install, which will install moduleA:jar into the local repository. After that, running mvn dependency:go-offline will work for sure. But that workaround defeats the purpose of this go-offline goal. This plugin allows us to resolve and pull dependencies into our local repository without building the whole project. I used dependency:copy-dependencies goal in another case and it has the same issue.
I also ran into similar issue in other scenarios: "mvn clean generate-source" could not resolve dependencies. When I ran mvn clean compile, everything works fine, but when I ran mvn clean generate-source, it fails because Maven cannot resolve inter-module dependency. In that case, the was caused by #requiresDependencyResolution in the antrun plugin.
Since both antrun plugin and dependency plugin are very popular in the Maven world, I am sure I am not the only one who have run into this issue. Anyone finds any solution/workaround?
Maven has the concept of a "reactor" where artifacts that have been built in a single run (e.g. maven package) are available for dependency resolution during the build. For example, if your dependency graph yields the build order moduleA moduleB moduleC, and you do mvn package, Maven will build moduleA, package its artifact and add it to the reactor, then build moduleB, package it and add it to the reactor, then the same for moduleC. This means moduleB has access to moduleA's artifact for dependency resolution, and moduleC has access to moduleA and moduleB. This only works if artifacts are actually built, i.e. when you run the package goal.
The problem is that when you don't run the package goal because you're not interested in the artifacts (as for your dependency:go-offline example), artifacts for modules that have been processed don't get built and thus not added to the reactor. I find this annoying as well; I think Maven should look at the POM files in its list of modules to build and look there as well; but it doesn't.
In short, the solution to your problem is to do mvn package dependency:go-offline . This will not install artifacts in your local repository (which I believe is very bad practice) but it will put them in the reactor for the duration of the build, meaning that Maven will be able to resolve dependencies from your moduleB to the moduleA that has already been built. The downside is every module will be tested and packaged, which is a lot of work when all you wanted is to do dependency:go-offline.
Either way, hope this helps.
This has been finally been resolved with Maven Dependency Plugin version 3.1.2.
You can make sure it's used by pinning the version in your pom.xml:
<build>
<pluginManagement>
<plugins>
<plugin>
<artifactId>maven-dependency-plugin</artifactId>
<version>3.1.2</version>
</plugin>
</plugins>
</pluginManagement>
</build>
I have created a JIRA ticket with a sample project here:
https://issues.apache.org/jira/browse/MDEP-516
Please vote for it.
You explained why it doesn't work so you understand the issues. The problem for you is that it stops when it can't find A.jar but that will only happen when you get to building B. So there is a sort of, sometimes useful strategy.
You have to mess with A by itself. Just build A. Use your plan of loading dependencies and then building it.
Once it builds, you can move on to doing the same thing with B and then C. Step by step.
One thing to remember here is that its sometimes ok to build B with an old snapshot of A in the local repo. You only need the new snapshot of A build in the repo if there are signature changes or new stuff required by B.
There are some discussions here too: Maven Modules + Building a Single Specific Module
One final not that usually these sort of questions come up when people have builds that take too long. There are several ways to make builds go faster:
Get faster hardware. The build computer, the disk storage or the network speed are typical components that are cheaper to upgrade than waste the time taken in slow builds.
Make the build go faster by not building stuff that doesn't need rebuilding. (For example, I had a build that rebuilt all the generated code every time. I added some stuff into the build that kept it from doing that except when dependencies to the generated code changed.)
Speed up the tests. Sometimes this means breaking the tests into two parts. Part 1 is fast tests and part 2 is slow tests. Run the fast tests on every build and the slow tests before any checkin of code or release of artifacts.
Break a multi-module build into 2 or more separate builds and use human intelligence to decide when to rebuild things. This works well when some jars are stable and don't change much any more.
Fill in your own method to make the build go faster.
I doubt such functionality would ever be possible with Maven. Whilst your projects share a common parent and depend upon each other, Maven cannot possibly know where to find these projects in order to build them. It also cannot determine whether the projects just need to be built, or whether you've specified the wrong version number for your dependency.
That's going to be supported by dependency:go-offline goal starting from Maven Dependency Plugin v3.1.2. Related jira ticket MDEP-204 and patch 23b7ca8790ae14175ed8e3a20c75c6274efe5ad8 with fix.
I am building a multi-module project where one of the modules is also a multi-module project. When I try to build the nested multi-module independently using -pl <multi-module child>, Maven only builds the pom(the top-level module of the child) and does not build the rest of the modules specified in the multi-module project.
If I don't use the -pl and build all the modules, everything work fine, the project builds as intended.
Any ideas why this might be happening, I can't get Maven to build the entire project if I single it out individually?
The -pl option builds exactly the projects that you specify. Maven treats a parent POM as a regular project that happens to be the first in the hierarchy.
What you can do is browse into your "sub-multimodule" project and execute Maven from there. The option -rf (resume from) might also work.
There is no good reason for Maven behaving that way, other than this is how Maven always behaved for -pm. The -am option could include the modules listed of any module listed in -pl, because the parent "depends on them" in a way, but because they are not dependencies in the strict sense, Maven does not.
If Maven were an active project, a new -amm also-make-modules option might help.
I think the better way to achieve that is to use -pl to refer to one of the grandchild submodules. As it probably depends on its siblings, will can possibly achieve the same result.
This project is a great example on how to do that:
https://github.com/andyglick/maven-multi-level-modules-project
In short, you can do:
mvn test -pl com.example:my-grandchild-module -am
I have a multi module maven project. One of the modules is a reusable part which is packaged into a jar, and the other is a war web-app which depends on the first module. When I use jetty:run-exploded on the second module, the packaged jar is taken from local maven repository whereas I want the first module to be rebuild and packaged into the resulting war. Is there any way to force such behavior instead of the default one?
From everything I can tell from reading documents about Maven's design and using Maven myself this cannot be done in the projects own directory.
Maven will not follow module paths UP a hierarchy. Using -amd (also make dependencies) will only work at the top level module that ties all the other multi-module pom's together. So what you can do is this:
At the TOP level directory
mvn -amd -pl jetty_module jetty:run-exploded
I think you can use maven Advanced Reactor Options to archive this.
http://www.sonatype.com/people/2009/10/maven-tips-and-tricks-advanced-reactor-options/
The -pl or –projects option allows you to select a list of projects from a multimodule project. This option can be useful if you are working on a specific set of projects, and you’d rather not wait through a full build of a multi-module project during a development cycle.
Maven -amd(also-make-dependents ) also help to build multi module project once. Using that you can build a project and any project that depends on that project.
I have a strange issue and I don't know if my conclusion is correct. I have a multi module project with two children:
Rector build order:
mvn-project-test
mvn-project-core
core depends on test (so the build order is correct). Of course, running 'mvn test' doesn't install any artifacts locally. When running it, maven complaints (correctly) that ~/.m2/respositories/...../mvn-project-test-1.0-SNAPSHOT.jar is missing and the core build fails.
Shouldn't maven use the dependencies from the target folder of other multimodule children? Or must I always use 'mvn test install' on multi module projects? (Or third, I'm completely wrong and my whole project configurationis somehow broken)
Finally, the test project hasn't any content, yet, just dependencies so the jar is empty. But that shouldn't be a problem, right?
Cheers,
Jan
There were ideas for Maven 3 to allow the various mojos to see the whole build and do magic like "if none of my upstream projects changed, skip my tests" and things like that.
But as it is, each module is independent. Dependencies will only be resolved from the local repository. So if you don't mvn install, your tests won't work.