Maven build skips submodules which are dependency in another module - maven

I have nested multi module maven structure like this:
main_aggregator
|- submodule_A
| |- sub_submodule_1
| |- sub_submodule_2
|- submodule_B
|- submodule_C
pom.xml in main_aggregator has this in modules
<modules>
<module>submodule_A</module>
<module>submodule_B</module>
<module>submodule_C</module>
</modules>
pom.xml in submodule_A has this in modules
<modules>
<module>sub_submodule_1</module>
<module>sub_submodule_2</module>
</modules>
parent of main_aggregator's sub modules is something like this:
<parent>
<groupId>my.project</groupId>
<artifactId>main-parent</artifactId>
<version>0.0.1</version>
<relativePath/>
</parent>
parent of submodule_A's sub modules is something like this:
<parent>
<groupId>my.project</groupId>
<artifactId>specific-parent</artifactId>
<version>0.0.1</version>
<relativePath/>
</parent>
The important thing is that submodule_B has dependencies on sub_submodule_1 and sub_submodule_2
When I run build from main_aggregator, it fails and says it could not resolve depenencies for submodule_B - sub_submodule_1 and sub_submodule_2.
In reactor summary I see, that submodule_A was built first and built is success, but it's sub modules - sub_submodule_1 and sub_submodule2 are skipped. So I understand, why it fails on missing dependencies, but what I don't understand is why maven didn't built those dependencies first. Also I don't understand why build of submodule_A is marked as successful when it's sub modules wasn't even built.
Maven version is 3.5.2.
Update:
When I run build in one thread, there is no problem. Problem occurs only when doing parallel build.
Update2:
Running in single thread was only partial success. See my answer...

So I found out what was the problem. The problem was some kind of "copy paste exception". In submodule_A which is an aggregator, I have copied pom from main_aggregator. Of course I changed main things like group id and artifact id, but I didn't change plugins.
Plugin which caused that problems was javadoc. Particularly it's agregate goal. When I deleted it, I could build whole project (but not in parallel).
Problem was, that evidently during parallel builds, aggregators projects are build "out of order" because it has no dependencies (submodule_A start build before it's submodules were build). Now javadoc aggregate comes to play.
Javadoc aggregate forked every submodule build (maybe this is wrong terminology). But this was not ordered by dependencies, so it fails.
There still is problem with parallel builds, because aggregate goal of javadoc in main_aggregator cause the same problem. But that is for another question.
There is one more lesson I learned from that. If I would put content of whole pom.xml of each module in my question, somebody probably would see the problem.
So when you are asking something, don't hide details even when you think they does not matter :)...

Related

Maven - import / group all modules of project

I have a parent project with around 20 child modules:
<project>
<modules>
<module>module-1</module>
<module>...</module>
<module>module-20</module>
</modules>
</project>
I would like to use this project as one single entity, with all 20 modules included, in other projects. What is the convenient way to do this in Maven?
Should I make a new child module which imports the other 20 modules and refer to this project? Should this be a JAR or a POM project?
<project>
<packaging>jar</packaging>
<dependencies>
<dependency>... module-1 ...</dependency>
<dependency>...</dependency>
<dependency>... module-20 ...</dependency>
</dependencies>
</project>
I think the way you mentioned in your question is a good idea. It is actually mentioned as a best practice in the Maven book, quoting:
If you have a set of dependencies which are logically grouped together. You can create a project with pom packaging that groups dependencies together.
You can create a new module called module-all, which would be of pom packaging, that simply has a dependency on each of the modules. The packaging should be pom because the primary artifact of this module will only be the pom.xml (there will be no sources to compile, no JAR...). Then, in your external projects, you can simply add a dependency to this new module (as <type>pom</type>) and every module-i dependencies will be included transitively.
There would be a cave-at if all of your modules did not share the same version: there would need to be a reference to a specific version of a specific module and you would have to update the module-all version each time a module's version changes. However, if they all share the same version, module-all release cycle would be in line with module-i's.

Maven multiple parent-child hierarchy

I have a project that is built in the next manner:
parent module named Production, it holds two modules named apps and libs, each of them holds various projects.
Production
apps
common
utils
libs
api
dev
Production pom
<groupId>com.prod</groupId>
<packaging>pom</packaging>
<modules>
<module>libs</module>
<module>apps</module>
</modules>
Apps pom
<parent>
<groupId>com.prod</groupId>
<artifactId>apps</artifactId>
</parent>
<modules>
<module>common</module>
<module>utild</module>
</modules>
Where packaging of Production, apps and libs is pom.
While the packaging for the rest is war/jar.
When I try to run mvn install on Production (or any other module/project) I get Non-resolvable parent POM: Failure to find
Only when I run mvn install -N on Production, apps and libs, I can finally start working with the projects.
Is there a better way to accomplish successful modules and projects alignment without running mvn install -N? some pom definition or some other solution?
Without seeing your POMs, I am guessing that you are missing <module> elements naming the children in Production, apps and libs POMs.
Once you have that, if everything else is in order, you can build from the Production folder with mvn install and have the reactor figure out what the right order to build the various modules are, subject to inter-module dependencies. Note that the <module> elements are relative paths to the child projects, not anything to do with the GAV of the project.
See http://books.sonatype.com/mvnex-book/reference/multimodule.html for more information about proper setup for multi-module projects.

Maven - How/Why/Should it work to set the parent version to be based on a property defined in the parent pom?

I have the following POM structures:
/home/projects/parent/pom.xml
<project>
<groupId>com.my.group</groupId>
<artifactId>project-super-parent</artifactId>
<version>${major.version}.${minor.version}</version>
<packaging>pom</packaging>
<properties>
<major.version>7</major.version>
<minor.version>5</minor.version>
<current.release.version>${major.version}.${minor.version}-SNAPSHOT</current.release.version>
...
</properties>
....
</project>
/home/projects/module1/pom.xml
<project>
<groupId>com.my.group</groupId>
<artifactId>module1</artifactId>
<version>${current.release.version}</version>
<packaging>jar</packaging>
<parent>
<groupId>com.my.group</groupId>
<artifactId>project-super-parent</artifactId>
<version>${major.version}.${minor.version}</version>
<relativePath>../parent</relativePath>
</parent>
...
</project>
Notice that the module does not know the version of it's parent - it uses a property defined in the parent, so this is a kind of a chicken & an egg problem.
The weird thing is - that this works - so when I want to change the major version of the product - I only change a single pom file (the parent).
The limitations to this solution is that I have to have all POM files on the file system.
My questions are: should this even work? How exactly does it work? Is it likely to stop working when I upgrade to maven 3? Is this a commonly used solution or an abuse of the system?
Currently using Maven 2.2.1 and Java 7.
Is this a commonly used solution or an abuse of the system?
That is not common, at least I have never seen it before. The versioning you have in parent/pom.xml and module1/pom.xml will cause a confusion. The parent has a RELEASED version of 7.5, while module1 has a SNAPSHOT version of 7.5. You should not be developing 7.5-SNAPSHOT if 7.5 is already released.
The simplest way to avoid duplication is to maintain the version only in the parent. You can just omit the version declaration in module1. Take a look another project, e.g. maven-3 source code for example. You will be able to see the the version is only declared in the parent pom, and not in any of its child poms.
maven-release-plugin will help you handle the version upgrade and release them for you.
Omitting the version element from the child pom gives error.
Property can be used in Main pom and the same can be inherited by child pom's. When you run the Main pom, build will result in success. Problems are
That you can not build the child pom independently
This does not work in case of transitive dependencies
if you upgrade to Maven 3 in future than it will give error "Non-resolvable parent pom
These problems can be resolved if we are able to update the project pom file as part of the build process before it gets installed in local repository

How to resolve the parent POM of a dependency that uses the dynamic version

I am building a multiple modules project. The project structure likes:
-Build
-Local
-POM.xml (Master)
-Main Project
-Module A
-Libs Project
-Libs Project A
The Libs Project A has the POM has the dynamic version from it's parent's POM
<parent>
<groupId>com.myproject</groupId>
<artifactId>libs</artifactId>
<version>${release.version}</version>
</parent>
<!-- this POM -->
<groupId>com.myproject.libs</groupId>
<artifactId>http</artifactId>
<packaging>bundle</packaging>
<version>1.0.0</version>
When I run maven build and pass the version parameter to build "module A", the maven can not find the POM of the libs project.
Reason: Cannot find parent: com.myproject:libs for project:
com.myproject.libs:http:bundle:1.0.0 for project
com.myproject.libs:http:bundle:1.0.0
STOP NOW
There are a number of XPath locations within the POM where property substitution is never going to work in any way that is useable.
/project/parent/groupId
/project/parent/artifactId
/project/parent/version
/project/groupId
/project/artifactId
/project/version
/project/packaging
The reason for this is that the reactor build must be deterministic.
When you try to use properties in these locations it will appear to work, in other words Maven will not shoot your foot off immediately.... but when you try to do anything further on Maven will kindly shoot your foot off.
Perhaps we should change Maven to shoot your foot off initially... perhaps that would stop people thinking that putting property expansion in those elements is supported.

Maven: Selecting Parent Project Based On Profile

I have a maven project - it is a plugin for jenkins. It's parent should be a:
<parent>
<groupId>org.jenkins-ci.plugins</groupId>
<artifactId>plugin</artifactId>
<version>1.414</version>
</parent>
But at the same time this plugin can be also used for hudson, without changing any line of code. But the parent project for it should be:
<parent>
<groupId>org.jvnet.hudson.plugins</groupId>
<artifactId>hudson-plugin-parent</artifactId>
<version>2.0.1</version>
</parent>
Can I specify 2 different profiles for that and use them to build plugin for jenkins or hudson accordingly? So that I call something like that:
mvn package -P jenkins
or
mvn package -P hudson
I have tried to specify properties in profiles, but those are not replaced by their values inside the <parent> tag. So is there any other possibility to build plugin for both, but with as much as possible common code and files?
Added: So, if I cannot do that, what should I do then? How to refactor? What the new structure should be?
As already mentioned, this is not possible.
Also, it is not possible to set a property for the parent's version as the interpolation for that happens a lot earlier than the handling of the profiles.
I would suggest that you create a masterbuild project as follows:
master
|-plugin-jenkins
|-plugin-hudson
|-plugin-assembly
The master should build all three as usual. However, in the assembly, you could add each of the two plugins as dependencies in separate profiles. And... each of these plugins can have the parent you like.
This is obviously somewhat a deviation from the Maven convention, but I believe it is a solution to your problem.
It's not possible because the tag "parent" is not available in the profiles section of the pom.
Currently we decided to stick with 1 repository and 2 separate pom.xml files, giving maven key which pom.xml use to build the project.
mvn package -f pom-jenkins.xml
mvn package -f pom-hudson.xml
No you cannot do that. you will have to refactor somehow to avoid the necessity.
As mentioned already not possible. I would suggest to make separate projects for jenkins plugin and hudson plugin. I assume that in not that far future that will not work anymore cause Hudons and Jenkins will diverge.
In general, you should be able to set the {group,artifact}Id and version of the parent POM via Java System Properties or Environment Variables, but it seems there is a Bug in Maven which will only be fixed in 4.x:
https://issues.apache.org/jira/browse/MNG-624
Another solution is to delegate the inclusion of the parent POM to your own parent POMs which you reference in the relativePath element, and change the content of the target e.g. via a symlink or cp command.
So in the main POM you would write:
<parent>
<groupId>org.mycompany.project</groupId>
<artifactId>foo-artifact</artifactId>
<version>1.0.0</version>
<relativePath>./my-parent.pom</relativePath>
</parent>
And in my-parent-jenkins you would just put:
<groupId>org.mycompany.project</groupId>
<artifactId>foo-artifact</artifactId>
<version>1.0.0</version>
<parent>
<groupId>org.jenkins-ci.plugins</groupId>
<artifactId>plugin</artifactId>
<version>1.414</version>
</parent>
The same project information with the block for hudson you put in my-parent-hudson.pom.
No you can either use
ln -s my-parent-jenkins.pom my-parent.pom
or
ln -s my-parent-hudson.pom my-parent.pom
to include the respective parent POM without the need to maintain two different main POM files for your project.
In case POM does not exist at the place referenced in relativePath, Maven will look up the POM in the remote repository[1], which is also an easy way to overwrite a parent POM locally.
[1] http://maven.apache.org/components/ref/3.3.9/maven-model/maven.html#class_parent

Resources