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
Related
I have maven multi-modules project. At the parent level, i have some java files. And in the parent pom.xml, at the package phase i do some stuff.
Usually, when i run mvn package at parent level, the package phase of parent pom will be run and all the modules will be packaged as well.
I am looking for a way that allow me to do these (when i run mvn package):
allow me to run only paren pom.xml (the script at the package phase), not the modules. This is the 1st priority.
allow me to run paren pom.xml and some particular modules (like module 1, module 2 BUT not module 3 , module 4).
Can i use profile for those issue?
Thanks.
While I agree with the fact that you may not have optimal project structure, the answer is that Maven 2.2.1 has an option "--non-recursive" which satisfies your first requirement:
-N,--non-recursive Do not recurse into sub-projects
So something like this:
mvn --non-recursive clean compile
Why do you want to have java code on the top level? In my opinion this is not a very good idea. Have your code in the subprojects and let the top-level project be responsible for holding the general information and configuration of the entire project.
If you have some base-library code in the top-level project now, you can put it in a sub-project and set up dependencies between the projects.
Take a look at Maven parent pom vs modules pom
The nature of your question indicates that your project structure may not be optimal.
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've got a project with Maven in which one subproject (A) wants to depend on another subproject (B) which uses "pom" packaging.
If I do this the straightforward way, where A specifies a dependency on B with <type>pom</type>, things work perfectly if I do "mvn install", but if I run any phase earlier than install, such as mvn compile or mvn package, then it fails while trying to build A: it goes looking for B's pom in the repository, and doesn't find it.
I don't really want this pom in the repository, because it's part of our active source code and changes frequently.
For all the jar-packaged projects we build, it seems to work fine to keep them out of the repository, build with mvn package, and Maven knows how to find all the dependencies in the source and build trees it manages without resorting to the repository; however for the pom-packaged project it always wants to go to the repository.
A couple things I learned while trying to understand this:
Maven best practices encourage you to use pom-packaged projects to group dependencies, but with the added step of "mvn install" on the POM project
Maven lifecycle documentation says "a project that is purely metadata (packaging value is pom) only binds goals to the install and deploy phases"; maybe this is why the POM project is invisible as a dependency target unless I invoke the install phase? I tried binding the compiler plugin to the compile phase and this didn't seem to help.
Is there a way that I can specify the POM subproject as a dependency of another subproject in the same parent project, without installing the POM project to the repository?
It isn't purely a question of which goals are bound to which lifecycle phases for POM projects. If it were, then binding the "package" goal would solve the problem.
When building a multi-module project, Maven reads the POMs of all modules to determine dependencies between modules, so that it can build the depended-upon modules before the depending modules. It's able to achieve this even when running the "package" goal (such that the depended-upon modules are not yet in the local repository).
Therefore, the code that constructs the classpath for builds must be managing several cases, notably:
extra-project jar dependency, where it looks for the POM in the local repository, handles its dependencies, and adds the POM's jar to the classpath
extra-project pom dependency, where it looks for the POM in the local repository and handles its dependencies
intra-project jar dependency, where it looks for the POM within the project tree, handles its dependencies, and adds that module's target/classes folder to the classpath
intra-project pom dependency, where for some reason it doesn't look for the POM within the project tree, and therefore doesn't handle it's dependencies.
Notice the asymmetry in the last two cases, as compared to the first two.
I can see two solutions to your problem. One is to file a bug report, or rather a request to change the behaviour (since it's obviously intentional), perhaps only for the case of intra-project dependencies on multi-module projects. Or indeed propose a patch. But since the behaviour is intentional, you might meet a refusal. In the best of cases, you're in for a long wait. (I'd vote for your bug report though - I've been stung by that same behaviour, in a different context.)
The other solution is simply to run an install on your project. I don't really understand why you don't want the POM project in your repository: if needs be, you can use a snapshot repository, where it doesn't matter if things change frequently, to avoid polluting your main repository.
Configuring maven-install-plugin to run during the compile phase, and copy the relevant pom.xml to the repository, seems to accomplish what I wanted as far as Maven itself is concerned, though m2eclipse still is not happy (it throws "failed to read artifact descriptor" errors with no additional description for the pom.xml that has a dependency on the other POM 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.
Is it possible to do?
The environment: Multimodule pom consists of 3 modules: mm1, mm2, mm3. Module mm2 has mm1 as dependency. It is possible to build parent pom without any errors.
The question: Is it possible to build single module mm2 (i.e., run maven from mm2 base directory) without installing mm1 into local repository?
Thanks.
I'm not sure what you mean exactly by "without installing mm1 into local repository". Do you mean previously to building mm2 or never?
In doubt, maybe one of the new build options announced in the Maven Tips and Tricks: Advanced Reactor Options blog post can help:
Starting with the Maven 2.1 release,
there are new Maven command line
options which allow you to manipulate
the way that Maven will build
multimodule projects. These new
options are:
-rf, --resume-from
Resume reactor from specified project
-pl, --projects
Build specified reactor projects instead of all projects
-am, --also-make
If project list is specified, also build projects required by the list
-amd, --also-make-dependents
If project list is specified, also build projects that depend on projects on the list
I was specifically thinking to the -pl and -am options. To build a subset of the modules, run the following from the root directory
$ mvn --projects mm2 --also-make install
However, I'm not sure this answers your question (which is not totally clear for me).
Without automatic installing not, but it's possible to build only choosen projects. You need to have multi module build (I'm assuming you do). In reactor mode every command need to be run from the root of reactor.
So in your case:
mvn reactor:make -Dmake.folders=mm2
In this case you build mm2 module and modules on which it depends (mm1).
Useful links:
Maven reactor plugin reference
Maven book reactor chapter
From book examples I build only project persist and his dependency project model. Others projects are untouched with
mvn reactor:make -Dmake.folders=sample-persist
alt text http://www.sonatype.com/books/maven-book/reference/figs/web/running_aro-dependencies.png
Other useful command is reactor:make-dependents which build projects that depend on X.
This goes against the principle of dependencies of Maven2. What is the interest of doing that exactly?
However, we can imagine to define the mm1 dependency of mm2 as a system dependency:
<dependency>
<groupId>...</groupId>
<artifactId>mm1</artifactId>
<version>...</version>
<scope>system</scope>
<systemPath>../mm1/target/</systemPath>
</dependency>