I have the maven project with five separate modules each of them have pom.xml with duplicated profiles. Is there any options to move all profiles from pom to separate file?
You can put the profiles into the parent pom. They get inherited during the build:
parent pom (with all common profiles)
- module1
- module2
- module3
- module4
- module5
You need to reference the modules correctly
from parent pom using the <modules> tag
from each module reference the parent using the <parent> tag
Related
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.
I have a maven project with the following structure
Project
- pom.xml
--- Module1
--- pom.xml for Module1
--- Module2
--- pom.xml for Module2
--- Module3
--- pom.xml for Module3
------- Module31
------- pom.xml for Module31
------- Module32
------- pom.xml for Module32
i.e. Project has it's pom.xml (packages as pom) and has modules. Each of the modules have a <parent> .. </parent> section in the individual ModuleX pom.xml file where it can be either set to artifact of "Project" (which is defined in root pom.xml) -- OR it can be set to any other project2/project3/projectN artifact.
Now, due to this, I see if Project1 root pom.xml is set to 0.0.1-SNAPSHOT and if I want to create a release candidate (non-snapshot) build "0.0.1", then I expect all the modules should generate artifact with the same version which is set in Project's root pom.xml.
I noticed, that Module2 pom.xml has a parent which is some other project (for ex: Project2) and version id of this parent is set to "0.0.7-SNAPSHOT" and Module2 pom.xml (under Project) also has some of the dependencies using Project2's artifacts.
The same case exists for Module3 and Module32 where <parent> section has a different parent (set to ProjectN where N can be any number) and has dependencies on those or any ProjectN project's artifacts.
My question:
1. If I creating a 0.0.1 (non-snapshot) build of Project, then what version id artifacts Maven will generate for the root pom, for Module1, Module2, Module3 and Module31/32?
2. How can I make sure, 0.0.1 release of Project -- generates same version# 0.0.1 for all of its modules (even though the <parent> section of those modules uses a different project**N** and have different / newer <version>..</version> value set in the <parent> section).
Thanks.
Have a look at the maven-release-plugin, it does exactly want you want. release:prepare is about verifying and updating poms, tagging the project and preparing it for the next development cycle. release:perform is about building the projects based on the tag and pushing the artifacts to a remote repository.
Consider the following scenario of a flat multi-module layout:
| parent-pom
| - pom.xml
| module1
| - pom.xml
Where parent-pom/pom.xml is the parent POM of all modules:
<groupId>my-group</groupId>
<artifactId>parent-pom</artifactId>
<version>1.0.0</version>
...
...
<module>../module1</module>
Now, the pom.xml of module1 contains the following parent section:
<parent>
<groupId>my-group</groupId>
<artifactId>parent-pom</artifactId>
<version>1.0.0</version>
</parent>
I'm starting with a clean local repository; none of the artifacts is pre-built, everything done from scratch. Trying to execute mvn install on parent-pom will result in an error, because the Maven reactor will look for my-group:base-pom in the local repository, fail (because it's not there) and then look for ../pom.xml.
Fine. My question is this: if the build of module1 is invoked through the build of parent-pom, why does Maven even have to look for the parent's pom.xml anywhere? when Maven comes to build module1, it already knows the following things:
The physical location, of the file system, of my-group:parent-pom:1.0.0.
The fact that module1 is rooted in my-group:parent-pom:1.0.0.
Why look elsewhere?
The Introduction to the POM:Project Inheritance:Example 2 told us as the following: -
The Scenario
However, that would work if the parent project was already installed in our local repository or was in that specific directory structure (parent pom.xml is one directory higher than that of the module's pom.xml).
But what if the parent is not yet installed and if the directory structure is
.
|-- my-module
| `-- pom.xml
`-- parent
`-- pom.xml
The Solution
To address this directory structure (or any other directory structure), we would have to add the <relativePath> element to our parent section.
<project>
<parent>
<groupId>com.mycompany.app</groupId>
<artifactId>my-app</artifactId>
<version>1</version>
<relativePath>../parent/pom.xml</relativePath>
</parent>
<modelVersion>4.0.0</modelVersion>
<artifactId>my-module</artifactId>
</project>
As the name suggests, it's the relative path from the module's pom.xml to the parent's pom.xml.
EDITED:
The getRelativePath told us as the following
Get the relative path of the parent pom.xml file within the check out. The default value is ../pom.xml. Maven looks for the parent pom first in the reactor of currently building projects, then in this location on the filesystem, then the local repository, and lastly in the remote repo. relativePath allows you to select a different location, for example when your structure is flat, or deeper without an intermediate parent pom. However, the group ID, artifact ID and version are still required, and must match the file in the location given or it will revert to the repository for the POM. This feature is only for enhancing the development in a local checkout of that project.
I hope this may help.
I don't understand what is the parent version and for what it should be good?
We use svn in our team and when I did update for the project the last time I notcied that the parent version is changed:
local pom.xml
<parent>
<artifactId>foo</artifactId>
<groupId>bar</groupId>
<version>0.42-SNAPSHOT</version>
</parent>
svn pom.xml
<parent>
<artifactId>foo</artifactId>
<groupId>bar</groupId>
<version>0.45-SNAPSHOT</version>
</parent>
When does parent version change and for what it should be good?
A parent POM contain settings that apply to all child modules. This may include declaring plugin settings or choosing dependency versions.
A parent POM is no different to any other Maven artifact. It can change and when it does the version number must increment. Typically you want to always be using the latest available version of your parent.
You can use the Maven versions plugin to help manage versions, including forcing an update to the latest available parent version.
Parent pom and child pom come into picture if you have a multi-module project. For example like the below
/myapp
|- pom.xml --> parent pom
|+ module1/
| - pom.xml --> child pom
| - src/
|- module2/
There can be several such hierarchies. There are 2 ways to define this inheritance
Add a xml block in parent pom to tell it which are the dependent modules. OR
Add a xml block in a module to tell whose is it's parent. (This is your case)
This means that, the child pom is dependent on parent and will try to find the the concerned artifact with 0.45-SNAPSHOT version. This version has changed probably due to a newer build of parent has taken place replacing the version.
In a multi module project structure as
myApp
|-moduleA
|---pom.xml
|-moduleB
|---pom.xml
|-pom.xml
If i have the following properties in the parent.pom
<properties>
<moduleA.version>4.67</moduleA.version>
<moduleB.version>4.68</moduleB.version>
</properties>
How can i access the properties in the parent pom from any of the child poms? I tried this on the child pom but it didnt work.
<groupId>com.test</groupId>
<artifactId>moduleA</artifactId>
<version>${moduleA.version}</version>
If you have a real multi-module build you should never define the modules to have different versions. They should have the same version which make releasing possible and other things as well. Otherwise you should not use the multi-module setup than use simple single modules which are separated.
This should work. One possible reason I can think of is that perhaps you don't actually inherit the pom where these properties are defined (i.e. it's not defined as your <parent> directly or indirectly), but you only have a main pom that aggregates your projects. It's a guess, though.