We Keep Coding

Spring boot multi module maven projects without repository

I have multiple spring boot projects, every project is independent and has its own CICD pipeline.
These projects need some common classes, I have created a separate project with common classes.
Parent
pom.xml (with packaging)
lib-project
pom.xml
project-1
pom.xml
project-2
pom.xml
I can build project easily from the parent directory, it builds all the projects
parent$ mvn clean package
it generates all the jar files and put them in their respective target folder of projects
My problem is I can't initiate this at the parent level, this has to be initiated from within each project from its own pipeline.
and
I cannot use any local or remote repository, to put the dependent jar in m2 using mvn clean install and then refer to it as dependency
I want to build it from the relavent project directory
parent/project-1$ mvn clean package
it shows following error:
Could not resolve dependencies for project com.test.multiple:project-1:jar:0.0.1-SNAPSHOT: Could not find artifact com.test.multiple:lib-project:jar:0.0.1-SNAPSHOT
My expectation stepwise on compilation of project-1
Check if there is a dependency for project-1
Go to ../lib-project
Compile and build it in target folder (or anywhere relative to our project)
Add this generated jar to "project-1" dependency
Compile and build the "project-1" jar file.
Parent Pom Configurations
<project ...>
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.4.3</version>
<relativePath/> <!-- lookup parent from repository -->
</parent>
<groupId>com.test.multiple</groupId>
<artifactId>parent</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>pom</packaging>
<modules>
<module>lib-project</module>
<module>project-1</module>
</modules>
</project>
** Lib project pom **
<project ...>
<parent>
<groupId>com.test.multiple</groupId>
<artifactId>parent</artifactId>
<version>0.0.1-SNAPSHOT</version>
</parent>
<groupId>com.test.multiple</groupId>
<artifactId>lib-project</artifactId>
<version>0.0.1-SNAPSHOT</version>
<name>lib-project</name>
<properties>
<java.version>11</java.version>
</properties>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
</dependencies>
</project>
Project-1 pom
<project ...>
<parent>
<groupId>com.test.multiple</groupId>
<artifactId>parent</artifactId>
<version>0.0.1-SNAPSHOT</version>
</parent>
<groupId>com.test.multiple</groupId>
<artifactId>project-1</artifactId>
<version>0.0.1-SNAPSHOT</version>
<name>project-1</name>
<properties>
<java.version>11</java.version>
</properties>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>com.test.multiple</groupId>
<artifactId>lib-project</artifactId>
<version>${project.version}</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
</plugins>
</build>
</project>

I have multiple spring boot projects, every project is independent and has its own CICD pipeline.
These projects need some common classes, I have created a separate project with common classes.
Congratulations, your projects are not independent any more!
Given the definitions above, here are the dependencies:
lib-project depends on parent;
project-1 depends on parent;
project-1 depends on lib-project.
Please check Introduction to the POM and Guide to Working with Multiple Modules for the discussion on the dependencies in Maven projects.
I cannot use any local or remote repository, to put the dependent jar in m2 using mvn clean install and then refer to it as dependency
Given this limitation, and dependencies listed above, the POMs and source files of all the projects have to be present on the disk for build purposes. The build process has to start from the parent folder. The build process has to build all modules at once.
Also, please consider using mvn clean verify instead of mvn clean install to avoid populating the local repository with the artifacts you are building.

A maven project isn't designed to build its dependencies on demand. However, jenkins can be configured to build downstream projects when changes are pushed to an upstream dependency.
I have also worked around this by using the -pl option on a parent pom in the relevant jenkinsfile to build a subset of the child projects
Jenkinsfile
clone parent project
mvn clean package -pl core,deployable

Build War with multi module project

I have a multi module maven project with three different modules Module-Data, Module-Domain, Module-Web. All three projects are spring boot projects, however Module-Web is the web component of the project that handles everything web oriented which I want to build a war file for. I have a parent project with the following pom file which contains no code.
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.somename</groupId>
<artifactId>My-Project</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>pom</packaging>
<modules>
<module>module-data</module>
<module>module-domain</module>
<module>modele-web</module>
</modules>
Module-Domain depends on Module-Data and Module-Web depends on both Module-Data and Module-Domain. The problem I'm having is that when I try to build the project using maven it fails when building the Module-Domain with the following erros:
package com.somename.data.model does not exist // class file with this error
Module-Domain class files that imports from the Module-Data project fails with this error. I suspect this is because maven is not adding the Module-Data jar to the Module-Domain when building although its referenced in its pom file. How can I solve this problem and generate a war file with all dependencies?
Module-Domain pom.xml:
<dependency>
<groupId>com.somename.data</groupId>
<artifactId>module-data</artifactId>
<version>0.0.1-SNAPSHOT</version>
<scope>compile</scope>
</dependency>
Module-Web pom.xml
<dependency>
<groupId>com.somename.data</groupId>
<artifactId>module-data</artifactId>
<version>0.0.1-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>com.somename.domain</groupId>
<artifactId>module-domain</artifactId>
<version>0.0.1-SNAPSHOT</version>
</dependency>

This is a simple straight-forward approach that you are using. Should not cause a problem.
Module-Domain pom.xml:
<parent>
<groupId>com.somename</groupId>
<artifactId>My-Project</artifactId>
<version>1.0-SNAPSHOT</version>
</parent>
<dependencies>
<dependency>
<groupId>com.somename.data</groupId>
<artifactId>module-data</artifactId>
<version>0.0.1-SNAPSHOT</version> <!-- Make sure this version is correct -->
</dependency>
</dependencies>
Module-Web pom.xml:
<parent>
<groupId>com.somename</groupId>
<artifactId>My-Project</artifactId>
<version>1.0-SNAPSHOT</version>
</parent>
<dependencies>
<dependency>
<groupId>com.somename.domain</groupId>
<artifactId>module-domain</artifactId> <!-- pulls "module-data" as well : transitive dependency -->
<version>0.0.1-SNAPSHOT</version> <!-- Make sure this version is correct -->
</dependency>
</dependencies>
Do maven clean compile on the parent project that would build all the modules.
If you still see any compilation issues, you would need fix the source code.

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

How to use Maven Release Plugin with Multiple Maven Projects

I'm using Maven 3.
I have multiple maven projects, namely: the 'data model', the 'service', and the 'presentation', split into 3 different projects. They are configured separately (ie. not using maven parent pom).
I have maven release plugin setup on my project correctly, such that when I run mvn release:clean release:prepare release:perform on each individual project, it updates the project version (ie: from 3.4.5-SNAPSHOT to 3.4.5) as well as all the other things.
The problem here is, 'presentation' is dependent on 'service' is dependent on 'data model', and I refer to the projects in the pom files with the version number.
While I develop, say for example I would refer to 'service' in 'presentation' as 3.4.5-SNAPSHOT. But during deploy, I have to release 'service' to change the version to 3.4.5, then I have to update my version reference of 'service' in 'presentation', before I can run a release on 'presentation'.
Is there an automated way of doing this such that I don't need to update the reference of dependent projects during release?
What I have so from thanks to below comments: Updated: 25/03/2013
Run maven with:
versions:use-releases -Dmessage="update from snapshot to release" scm:checkin release:clean release:prepare release:perform
Outcome: version updated, but release build failed.

The Versions Maven Plugin may help you to achieve requirement, especially the goal versions:use-releases. You may be interested in the goal versions:use-next-releases and versions:use-latest-releases as well.
Side Note:
Normally, the good practice is define them as a Maven Multiple Module( here and here). This allow us to manage the version easier as the following example.
The parent
<groupId>my-group</groupId>
<artifactId>my-parent</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>pom</packaging>
.....
<modules>
<module>my-model</module>
<module>my-service</module>
<module>my-ui</module>
</modules>
The my-model
<parent>
<groupId>my-group</groupId>
<artifactId>my-parent</artifactId>
<version>0.0.1-SNAPSHOT</version>
</parent>
<artifactId>my-model</artifactId>
The my-service
<parent>
<groupId>my-group</groupId>
<artifactId>my-parent</artifactId>
<version>0.0.1-SNAPSHOT</version>
</parent>
<artifactId>my-service</artifactId>
<dependencies>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>my-model</artifactId>
<version>${project.version}</version>
</dependency>
</dependencies>
The my-ui
<parent>
<groupId>my-group</groupId>
<artifactId>my-parent</artifactId>
<version>0.0.1-SNAPSHOT</version>
</parent>
<artifactId>my-ui</artifactId>
<dependencies>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>my-service</artifactId>
<version>${project.version}</version>
</dependency>
</dependencies>
Regarding to the above example when we release, the related version will be updated based on the parent version automatically.

How to define organization specific parent pom

Env: Maven 2.2.1
I have two java projects under svn (projectA, projectB). My maven structure is as follows..
For projectA
pom.xml (contains ProjectA parent pom definitions)
module moduleA
module moduleB
For projectB
pom.xml (contains ProjectB parent pom definitions)
module moduleC
module moduleD
projectA/pom.xml and projectB/pom.xml contain common definitions like junit, selenium, compiler, eclipse plug-ins which are common to both projects. (e.g. given below)
<dependency>
<groupId>commons-lang</groupId>
<artifactId>commons-lang</artifactId>
<version>2.4</version>
<type>jar</type>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.7</version>
<scope>test</scope>
</dependency
How should I create / organize a organization specific project pom which includes such common definitions, so that individual projects don't have to re-create / maintain one. Can someone provide some snippets or projects which have already done this before?
EDIT1:
company/pom.xml
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany</groupId>
<artifactId>company</artifactId>
<packaging>pom</packaging>
<name>parent</name>
<version>1.0.0</version>
<build>
<defaultGoal>install</defaultGoal>
</build>
<dependencies>
<dependency>
<groupId>commons-lang</groupId>
<artifactId>commons-lang</artifactId>
<version>2.4</version>
<type>jar</type>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.5</version>
<scope>provided</scope>
</dependency>
</dependencies>
projectA/pom.xml
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>com.mycompany</groupId>
<artifactId>company</artifactId>
<version>1.0.0</version>
</parent>
<groupId>com.mycompany</groupId>
<artifactId>projectA</artifactId>
<packaging>pom</packaging>
<name>projectA</name>
<version>1.0.0</version>
<modules>
<module>moduleA</module>
<build>
<defaultGoal>install</defaultGoal>
</build>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
projectA/moduleA/pom.xml
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>com.mycompany</groupId>
<artifactId>projectA</artifactId>
<version>1.0.0</version>
<relativePath>../pom.xml</relativePath>
</parent>
<groupId>com.mycompany</groupId>
<artifactId>moduleA</artifactId>
<version>1.0.0</version>
<packaging>jar</packaging>
<name>moduleA</name>
<build>
<finalName>moduleA</finalName>
<defaultGoal>install</defaultGoal>
</build>
<dependencies>
<dependency>
<groupId>commons-lang</groupId>
<artifactId>commons-lang</artifactId>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
</dependency>
</dependencies>
Throws the following error:
Project ID: com.mycompany:moduleA
POM Location: c:\temp\maven\projectA\moduleA\pom.xml
Validation Messages:
[0] 'dependencies.dependency.version' is missing for commons-lang:comm
ons-lang:jar
[1] 'dependencies.dependency.version' is missing for javax.servlet:ser
vlet-api:jar

I would seriously reconsider adding dependencies into a "super" POM, this unnecessarily couples the projects (but may hint that if the projects aren't disparate then they should be merged anyway).
I think the last comment by #lexicore is poignant too, to expand on the OOP analogy it also feels like "mixing levels of abstraction".
Alex Gitelman provides the correct answer, you need to use dependencyManagement as shown here Dependency Scope
Maven3 is supposed to be supporting POM fragments see How to use Maven 3 mixins? which I've long been waiting for.
We have an organisation Über POM but this just contains:
<organization>
<name>...</name>
<url>...</url>
</organization>
<developers>
<developer>
<id>...<id>
<name>...</name>
<email>...</email>
<roles>
<role>...</role>
</roles>
</developer>
<distributionManagement>
...
</distributionManagement>
<repositories>
<!-- your proxy repo here -->
</repositories>
These are things that change very rarely (if we change our repository/distribution-management then all projects must change, if a developer leaves or joins we can update the project POMs at any time convenient).
Dependencies belong specifically to the module under consideration, just because two independent project happen to share dependencies now doesn't mean they always will. I completely understand the annoyance of having to copy 'n' paste reams of XML for each project (compiler plugin, reporting plugins, junit etc), but differing levels of activity in each project will surely mean they diverge at some point.
WRT cascade builds in Continuous Integration, if project A demands a change in the super dependencies POM, then all you other projects will be forced to rebuild - maybe fine if you've only 2 projects but even then did you checkout and build both before committing the change?

If it's only dependencies that you need to reuse, create another project with packaging pom and specify dependencies there. Let's call it OrgDependencies Then include it as dependency in your projectA and projectB. It will transitively pull all dependencies from OrgDependencies project.
In your example, in projectA, instead of
<parent>
<groupId>com.mycompany</groupId>
<artifactId>company</artifactId>
<version>1.0.0</version>
</parent>
Try putting
<dependencies>
<dependency>
<groupId>com.mycompany</groupId>
<artifactId>company</artifactId>
<version>1.0.0</version>
</dependency>
</dependencies>
And remove dependencies to commons-lang etc from modules.
Update.
While my previous solution with transitive dependencies should work, actually what you need
is <dependencyManagement> section in your company wide pom.xml
That's where you define versions.
Note: Anything in dependencyManagement section is not really a dependency but just a descriptor that allows to specify version and exclude transitive dependencies (if necessary) in case normal dependencies section specifies that dependency. So you can put as many items in dependencyManagement as you want, it will not make all descendants dependent on them.
I tested it and it works:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany</groupId>
<artifactId>company</artifactId>
<packaging>pom</packaging>
<name>parent</name>
<version>1.0.0</version>
<build>
<defaultGoal>install</defaultGoal>
</build>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>commons-lang</groupId>
<artifactId>commons-lang</artifactId>
<version>2.4</version>
<type>jar</type>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.5</version>
<scope>provided</scope>
</dependency>
</dependencies>
</dependencyManagement>
</project>

In OS projects I am normally using 3+ levels of POMs:
"Company-wide POM" contains dev-wide definitions like distribution management, individual plugin versions etc. Very stable, normally has one-number version. Example: Sonatype OSS Parent.
"Project POM" contains project-wide definitions: Java compiler version, dependency management etc. Parent is company-wide POM. Example :JAXB2 Basics Project. Version is updated with each release.
"Module POMs" on different levels. List individual dependencies (versions of dependencies are inherited from the project POM), add "special" build steps. Example: JAXB Basics.
I saw a similar pattern an other OS projects (like Apache's) as well.
A few more comments:
You may also have the "department POM" or "product POM" depending on the company size and product organization.
Think of POM inheritance pretty much as of OOP inheritance. What would you put into which abstract class so that class hierarchy is stable but dynamic? For instance, it would not make sense to define versions of dependencies in the company-wide POM since versions change too often. On the contrary, defining distribution management in earch of the projects would hurt the DRY principle.