best practice for making a maven parent project - java

I developped a multi-module project which is a kind of java web framework.
One of the submodules is a parent pom that I provide for the users of my framework. This parent configures plugins and dependencies for them.
My problem is that this parent pom must refers the sibling modules with their version, which is ${project.version}, and because of the maven project inheritance, the ${project.version} is not the one I want.
To illustrate, my framework projects structure looks like :
my-framework/
|_pom.xml
|_parent/
|_pom.xml
|_server/
|_pom.xml
|_ui/
|_pom.xml
and my parent pom looks like :
<project
....
<!-- General information -->
<modelVersion>4.0.0</modelVersion>
<artifactId>my-framework-parent</artifactId>
<packaging>pom</packaging>
<parent>
<groupId>my.framework</groupId>
<artifactId>my-framework</artifactId>
<version>1.0.0-SNAPSHOT</version>
</parent>
<properties>
<my.framework.version>${project.version}</my.framework.version>
</properties>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>my.framework</groupId>
<artifactId>my-framework-server</artifactId>
<version>${my.framework.version}</version>
</dependency>
<dependency>
<groupId>my.framework</groupId>
<artifactId>my-framework-ui</artifactId>
<version>${my.framework.version}</version>
</dependency>
</dependencyManagement>
...
</project>
Then, if a user uses this parent, as maven resolves ${project.version} in the context of the user's project, ${my.framework.version} will be the user's project version instead my framework's version.
To solve this I generated the parent pom I want thanks to the maven-resources-plugin and I overrided the maven-install-plugin behaviour to install the generated pom.
My solution looks tricky and I would like if someone who faced the same problem has a better solution?

I finally found a solution thanks to the flatten-maven-plugin.
But I had to post a pull request to support the pluginManagement section.
https://github.com/mojohaus/flatten-maven-plugin/pull/10
So the solution was to modify my parent pom thanks to this plugin before publishing it. As a result I can set the version I want instead of using ${project.version}.

Related

Maven child module in parent pom as dependency

I'm trying to create a maven spring-boot project with multiple modules. I have created a parent module with packaging type pom and many children submodules with packaging type jar.
So my parent's pom.xml looks like:
<groupId>Creator</groupId>
<artifactId>DPAI</artifactId>
<packaging>pom</packaging>
<version>1.0-SNAPSHOT</version>
<modules>
<module>starter</module>
<module>DatabaseApi</module>
...
</modules>
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.2.4.RELEASE</version>
</parent>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
</dependencies>
One of submodules: starter contains only starting class annotated with #SpringBootApplicatoion and in its pom.xml there is a section with other child artifacts like:
<parent>
<artifactId>DPAI</artifactId>
<groupId>Creator</groupId>
<version>1.0-SNAPSHOT</version>
</parent>
<artifactId>starter</artifactId>
<packaging>jar</packaging>
<dependencies>
<dependency>
<groupId>Creator</groupId>
<artifactId>DatabaseApi</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
...
</dependencies>
So I'm trying to do some refactoring and move Main.class and all dependencies to my parent's pom, but it doesn't compile with error with message that my dependencies referencing itself.
In my opinion, the problem is that my parent pom contains section with it's own submodules. Parent of that submoduls is the same pom, where I try to add described dependencies
The parent.pom can't contain any java code, only Maven specifics e.g. See: https://howtodoinjava.com/maven/maven-parent-child-pom-example/#parent-content
Maybe tell us, what you want to achieve.
In a Maven multi module project you usually have a parent Pom (with packaging Pom) and several modules at the same level as you already set your project up.
Build the modules without dependecies on your code first, the the dependent modules: In your parent Pom change the order of the modules to
<modules>
<module>DatabaseApi</module>
<module>starter</module>
...
</modules>
So I'm trying to do some refactoring and move Main.class and all
dependencies to my parent's pom
I dont think this is possible. Your parent pom is actually of type pom, meaning you're not actually supposed to have any java code in it. Its meant to hold the versions of jars used in your child modules. You can relate this to the spring-boot-parent module. When we declare the spring-boot-parent module in a spring boot project, your adding your project as a child of the spring-boot-parent. And the parent will manage the versions of all of your dependencies.
I think the best way forward would be to maintain all your service related code in your spring-boot module. Filters, controllers,etc. The other stuff like your jdbc, integration layers can be maintained in other child modules and then referred to the spring module as jar references similar to your example.
So I'm trying to do some refactoring and move Main.class and all
dependencies to my parent's pom,
I'm not 100% sure if Maven would support something like the following in the parent POM itself:
<dependencies>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>DatabaseApi</artifactId>
<version>${project.version}</version>
</dependency>
...
</dependencies>
But for sure it won't support Java classes in a Module with pom-packaging (such as parent modules or multi-module modules). The compiler:compile goal etc. are not bound to any phase for pom-packaging by default. In other words: Maven does not compile Java classes for pom-modules by default.
My recommendation:
Keep the SpringBootApplication in a Java-based module. For Spring MVC/ WebFlux application I usually create a "-web" module with:
SpringBootApplication
web service controllers
http/ web filters
global configs such as: security, swagger, async
application.yml
...
It's also the module where I configure the Spring Boot Plugin to create an executable JAR.

Module dependency vs artifactory

We have maven aggregated pom project as below
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.abc</groupId>
<artifactId>project</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>pom</packaging>
<modules>
<module>module-1</module>
<module>module-2</module>
<module>module-n</module>
</modules>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.xyz<groupId>
<artifactId>framework</artifactId>
<version>1.1.1-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>com.xyz</groupId>
<artifactId>dao</artifactId>
<version>1.1.1-SNAPSHOT</version>
</dependency>
</dependencies>
</dependencyManagement>
</project>
module-2 has dependency of module-1
AND module-n has dependency of module-1 & module-2.
The maven reactor can resolve all inter-module dependency (build order is module-1, module-2, module-n).
Some shared components from com.xyz is also used by the modules (e.g. framework). They are retrieved from the remote artifactory server, while the inter-module dependency artifacts (e.g. module-1.jar) are retrieved locally during maven build.
My question is what is the best way to associate the dependencies. By module or by the artifacts stored in artifactory server? This example has both usage. I could not figure out under which circumstance we should
1) group all inter-dependent modules under the same parent pom OR
2) always pull the depending artifacts from remote artifactory repo and let each of the module built independently
Any pros and cons? Sorry for my poor English. I hope my question is clear. Thank you!
The rule of thumb is:
Do you always build the jars at the same time? Then they should form a multi-module project.

How to add certain specific libraries in all the projects of the current workspace in Eclipse?

I have created 5 or 6 Java projects in Eclipse by now and will be creating some 20 more projects. I have to add the TestNG library and another library (including some specific jar files) in the project.
Is there any way such that the Eclipse will automatically include both of these libraries at the time of creating every new project?
I don't want to add these libraries on my own by navigating to ADD BUILD PATH -> ADD LIBRARIES.
First, you shouldn't use Eclipse dependency management (add libraries manually to build path using Eclipse) if you're already using Maven.
IMO, you should only rely on Maven dependency mangement.
I suggest you to create a Maven parent project that will handle your dependecies used across multiple projects as follow.
Project structure
- maven-parent-project
|-- project-a
|-- project-b
|-- ...
Define Maven parent project
I suggest you used <dependencyManagement> (documentation) to manage the versions of your dependencies.
pom.xml
<project>
<artifactId>maven-parent-project</artifactId>
<modules>
<module>project-a</module>
<module>project-b</module>
</modules>
<dependencyManagement>
<dependencies>
<!-- Here you can define the versions of your dependencies used accross multiple project -->
</dependencies>
</dependencyManagement>
<dependencies>
<!-- Here you can define the dependencies used accross multiple project -->
</dependencies>
</project>
Define Maven sub projects
Then, you can define in all your project the maven-parent-project
pom.xml
<project>
<parent>
<artifactId>maven-parent-project</artifactId>
<version>0-SNAPSHOT</version>
<groupId>group</groupId>
</parent>
<artifactId>project-a</artifactId>
<dependencies>
<!-- Here you can define the dependencies specific to the project a -->
</dependencies>
</project>
I hope this will help you.
Study about dependency management in Maven. That will solve your requirements. Read this thread to get the jist.

Maven version with a property

I have big Maven (Tycho) project witch about 400 plug-ins.
We have specified version of application in each POM file.
Is there a way how to specify the version for all POM:s only on one place?
I would expect some think like:
<properties>
<buildVersion>1.1.2-SNAPSHOT</buildVersion>
</properties>
....
<version>${buildVersion}</version>
We have parent pom.xml:
<modelVersion>4.0.0</modelVersion>
<groupId>company</groupId>
<artifactId>build.parent</artifactId>
<version>1.1.2-SNAPSHOT</version>
<packaging>pom</packaging>
Then in each POM is reference to parent POM:
<parent>
<artifactId>build.parent</artifactId>
<groupId>company</groupId>
<relativePath>../build.parent/pom.xml</relativePath>
<version>1.1.2-SNAPSHOT</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<groupId>company</groupId>
<artifactId>artifact</artifactId>
<version>1.1.2-SNAPSHOT</version>
<packaging>eclipse-plugin</packaging>
If you have a parent project you can set the version in the parent pom and in the children you can reference sibling libs with the ${project.version} or ${version} properties.
If you want to avoid to repeat the version of the parent in each children: you can do this:
<modelVersion>4.0.0</modelVersion>
<groupId>company</groupId>
<artifactId>build.parent</artifactId>
<version>${my.version}</version>
<packaging>pom</packaging>
<properties>
<my.version>1.1.2-SNAPSHOT</my.version>
</properties>
And then in your children pom you have to do:
<parent>
<artifactId>build.parent</artifactId>
<groupId>company</groupId>
<relativePath>../build.parent/pom.xml</relativePath>
<version>${my.version}</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<groupId>company</groupId>
<artifactId>artifact</artifactId>
<packaging>eclipse-plugin</packaging>
<dependencies>
<dependency>
<groupId>company</groupId>
<artifactId>otherartifact</artifactId>
<version>${my.version}</version>
or
<version>${project.version}</version>
</dependency>
</dependencies>
hth
The correct answer is this (example version):
In parent pom.xml you should have (not inside properties):
<version>0.0.1-SNAPSHOT</version>
In all child modules you should have:
<parent>
<groupId>com.vvirlan</groupId>
<artifactId>grafiti</artifactId>
<version>0.0.1-SNAPSHOT</version>
</parent>
So it is hardcoded.
Now, to update the version you do this:
mvn versions:set -DnewVersion=0.0.2-SNAPSHOT
mvn versions:commit # Necessary to remove the backup file pom.xml
and all your 400 modules will have the parent version updated.
Using a property for the version generates the following warning:
[WARNING]
[WARNING] Some problems were encountered while building the effective model for xxx.yyy.sandbox:Sandbox:war:0.1.0-SNAPSHOT
[WARNING] 'version' contains an expression but should be a constant. # xxx.yyy.sandbox:Sandbox:${my.version}, C:\Users\xxx\development\gwtsandbox\pom.xml, line 8, column 14
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
[WARNING]
If your problem is that you have to change the version in multiple places because you are switching versions, then the correct thing to do is to use the Maven Release Plugin that will do this for you automatically.
See the Maven - Users forum 'version' contains an expression but should be a constant. Better way to add a new version?:
here is why this is a bad plan.
the pom that gets deployed will not have the property value resolved, so
anyone depending on that pom will pick up the dependency as being the string uninterpolated with the ${ } and much hilarity will ensue in your
build process.
in maven 2.1.0 and/or 2.2.0 an attempt was made to deploy poms with
resolved properties... this broke more than expected, which is why those
two versions are not recommended, 2.2.1 being the recommended 2.x version.
With a Maven version of 3.5 or higher, you should be able to use a placeholder (e.g. ${revision}) in the parent section and inside the rest of the POM, you can use ${project.version}.
Actually, you can also omit GAV properties outside of <parent> which are the same, as they will be inherited. The result would look something like this:
<project>
<modelVersion>4.0.0</modelVersion>
<parent>
<artifactId>build.parent</artifactId>
<groupId>company</groupId>
<version>${revision}</version> <!-- use placeholder -->
<relativePath>../build.parent</relativePath>
</parent>
<artifactId>artifact</artifactId>
<!-- no 'version', no 'groupId'; inherited from parent -->
<packaging>eclipse-plugin</packaging>
...
</project>
For more information, especially on how to resolve the placeholder during publishing, see Maven CI Friendly Versions | Multi Module Setup.
If you're using Maven 3, one option to work around this problem is to use the versions plugin
http://www.mojohaus.org/versions-maven-plugin/
Specifically the commands,
mvn versions:set -DnewVersion=2.0-RELEASE
mvn versions:commit
This will update the parent and child poms to 2.0-RELEASE. You can run this as a build step before.
Unlike the release plugin, it doesn't try to talk to your source control
I have two recommendation for you
Use CI Friendly Revision for all your artifacts. You can add -Drevision=2.0.1 in .mvn/maven.config file. So basically you define your version only at one location.
For all external dependency create a property in parent file. You can use Apache Camel Parent Pom as reference
I have successfully resolved the issue thus:
In parent pom.xml I have sited the version as usual (not inside properties):
<version>0.0.1-SNAPSHOT</version>
In all child modules I used:
<parent>
<groupId>com.example</groupId>
<artifactId>parent-module</artifactId>
<version>0.0.1-SNAPSHOT</version>
</parent>
Then I changed the parent to:
<version>0.0.2-SNAPSHOT</version>
Now, to update the version I executed in the command line:
mvn -N versions:update-child-modules
The children have been updated automatically to:
<parent>
<groupId>com.example</groupId>
<artifactId>parent-module</artifactId>
<version>0.0.2-SNAPSHOT</version>
</parent>
In other words I have used the versions:update-child-modules goal.
I have found this solution here.
The version of the pom.xml should be valid
<groupId>com.amazonaws.lambda</groupId>
<artifactId>lambda</artifactId>
<version>2.2.4 SNAPSHOT</version>
<packaging>jar</packaging>
This version should not be like 2.2.4. etc

Clean up Maven dependency management

In a big Maven 2 project it is nice to have the dependency management to make sure that only one version of a dependency is used in the whole system. That makes the system consistent.
But when I generate effective POMs I have no chance to see where the dependency versions came from. Likewise in a POM at the top of the hierarchy I have no idea where in the child POMs the defined versions of the dependency management section are really used.
So how do I keep the dependency management cleaned up? When I remove a dependency in one project, I always check in all other projects if it is still needed at all, so that I can also remove in from the dependency management at the top?
Also, how do I build up the dependency management, making sure it is not duplicated somewhere in the child POMs? When I add dependencies I always check all other projects to see if it possibly could be aggregated on top in the dependency management? Or would you just always move all dependency versions to the top from the beginning so they are always in only one place?
Thanks for any thoughts.
You could create one or more boms (bill of materials) for your project. These pom.xmls will declare all the dependencies used in your project within dependencyManagement section.
In each child pom, you would import these boms and use those dependencies that are required for the project.
In this way, dependency versions are managed centrally, while at the same time, each child pom uses only those dependencies that it needs.
See Importing Managed Dependencies
BOM project
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>my.group</groupId>
<artifactId>My-Project-Bom</artifactId>
<version>1.0</version>
<packaging>pom</packaging>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>commons-beanutils</groupId>
<artifactId>commons-beanutils</artifactId>
<version>1.7.0</version>
</dependency>
...
</dependencies>
</dependencyManagement>
</project>
Child project
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>my.group</groupId>
<artifactId>child1</artifactId>
<packaging>jar</packaging>
<name>Child1</name>
<version>1.0</version>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>my.group</groupId>
<artifactId>My-Project-BOM</artifactId>
<version>1.0</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>commons-beanutils</groupId>
<artifactId>commons-beanutils</artifactId>
</dependency>
</dependencies>
...
</project>
maven dependency plugin has a few goals to help you get the dependency hierarchy.
mvn dependency:list
mvn dependency:tree
mvn dependency:analyze
If you are using eclipse, the m2eclipe plugin allows you to view the Dependency Hierarchy for you pom. This can be very useful when trying to determine where dependencies are brought into your project and where conflicts are occurring.
You should explicitly declare the dependencies in the projects in which they are used, unless it is being used in ALL of the projects. If, for example, Spring is used for all of your projects, then put that in the parent POM. If it is only used in some projects, declare it in each one and put a spring.version property in the parent which each child pom can use for its version.
Moving all dependencies to the parent removes the responsibility from each project to manage its own dependencies. I would consider this a misuse of maven as it makes things more difficult to maintain instead of easier. It now adds dependencies to projects that doesn't need them. Often the scope of a dependency is different for projects as well, and you cannot manage that unless you declare your dependencies locally.
You can get the POM to POM dependencies, and the code-references that cause them, using the Structure101 composition perspective. Create a new s101 project, type Maven, specify the root pom.xml file, finish (use defaults for the rest of the wizard), then select the composition perspective (2nd button down on the vertical toolbar top left of the UI) and you will see something like this:

Categories