Version of a module POM from parent POM

[Ron McLeod]

Is there any way to reference the version property of a module POM from the parent POM?  Ideally something like: ${project.modules[0].version}
<?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>    <!-- parent pom (me) -->    <groupId>net.example.rsp</groupId>    <artifactId>auth-service-builder</artifactId>    <packaging>pom</packaging>    <version>1.0.0</version>    <!-- sub modules -->    <modules>        <module>../auth-service</module>        <module>../common</module>        <module>../auth-common</module>        <module>../auth-interface</module>    </modules> ... </project>

[Stephan van Hulst]

No, and this is also not a good idea. You're going to set yourself up for no end of trouble when you let parent projects know too much about sub-modules. Trust me, I've been there.

Keep your Maven projects simple. Parent projects should only act to provide default settings for sub-modules, or act as aggregators.

If you tell us why you want to do this, maybe we can offer you a better approach.

[Ron McLeod]

I am trying to automate and simplify the process of building a service application and packaging it into a shippable form.

The application that I am building has a number of shared local dependencies:
+----------------+ +---------->| auth-interface | | +----------------+ | +--------------+ +--------+ | auth-service |--------------------------->| common | +--------------+ +--------+ | ^ | +-------------+ | +---------->| auth-common |-------------+ +-------------+
The source code is checked-out in a flat structure:
. +-- auth-common   (gRPC interceptors for authentication service provider and clients) ¦   +-- pom.xml ¦ +-- auth-interface   (gRPC stubs and base implementations for authentication service) ¦   +-- pom.xml ¦ +-- auth-service   (authentication service application) ¦   +-- pom.xml ¦ +-- auth-service-builder   (builds and packages auth-service as shippable container image) ¦   +-- pom.xml ¦ +-- common   (commonly used utilities)    +-- pom.xml
Originally, the process was:
1. Build and install auth-interface
2. Build and install common
3. Build and install auth-common
4. Build auth-service
5. Create container image for auth-service
6. Transform container image to shippable form

I wanted to improve the process by:
- Eliminating the need to separately build dependencies
- Not storing dependencies in local Maven repository
- Having a single command to build and package container image

What I did:
- Created aggregation project with dependent projects as sub modules
- Created shell scripts for container image processing tasks
- Used maven-antrun-plugin to call the scripts (there may be a better plugin for this)

This works well, but I still have one issue - I want to tag the image and image file with the version in the auth-service project.
For example:
      image tag: auth-service:1.0.0
      shippable image file name: auth-service_1.0.0.gz

Currently, I am defining the image version in the builder POM adding a dependency for that specific version of auth-service, and then using that version property to tag the image.  If the version in the builder POM does not match the version in the auth-service POM, the build will fail, triggering me to manually update the version in the builder POM to match the version in the auth-service POM.

What I would really like is that the builder POM is not the authority for the auth-service version, but could discover/use the version defined in the auth-service POM.

[Tim Holloway]

Not only can't you pass version information into a child POM, you will find that Maven doesn't like the injection of other information such as absolute filesystem paths into POMs.

There are very good reasons for that.

First and foremost is portability. As I've said many a time, one of Maven's virtues is that I can do a "mvn clean", zip up a project, send it to Ulan Bator, and someone there can completely replicate the executable armed only with a JDK and Maven, no missing files, no "version hell". If you don't think that's important you've never worked in a shop where you were mandated to use stuff from another department where their directories were set up completely different than yours and/or different versions of libraries were installed on different systems.

Related to that is the concept of being self-contained. As I said, to faithfully re-construct a project all you need is Maven and a compatible JDK. Period.

Now let's consider your situation where you have a master version number that you want to apply across the POM tree. Nope. That's not the Maven Way. Each Maven artefact version is an indicator of a unique set of changes to the project it was built from. You don't just create duplicate artefacts with different version numbers. That not only can lead to confusion, it also doesn't allow for things like gradual migration of the sub-components of a project.

You should build your POMS - all of them - to install into your local repository, and in an Enterprise environment, I further recommend installing to a shared in-house repository so that people don't have to pass stuff back and forth by hand. This is also where you'd usually want your overnight build-and-test runs to work from if you're into Continous Integration.

You probably need to be doing snapshot builds. They're what's generally done for things like what you are describing. Maven's snapshot building is quite good.

[Ron McLeod]

Thanks for the feedback.

Maybe I can clarify what I am trying to do.  I was not trying to pass/inject anything to into a child/sub-module project, I was wanting to extract version information from a child.  Also, I don't think I am failing the Ulan Bator test - all the projects (common, auth-interface, auth-common, and auth-service in my case) can be built in any generic environment with Maven and JDK 11 installed.

What I am trying to do, is use Maven as a generic build tool, where in addition to building the Java projects, is also used to create a container image, and then export the container image as a compressed file, which can then be delivered-to and imported-into a target platform.  To do this, I created a Maven builder (aggregation) project which besides building the application (and its dependencies), also performs additional processing using the maven-antrun-plugin plugin to execute some bash scripts included in the project.  This builder project does have platform dependencies such as bash, gzip, podman, etc., but the builder project is used in a engineering/dev-ops function, not a software development function.



I want to tag the container image and name the compressed image with the version of the application (auth-service in my case), regardless of which version it is.  That is why I wanted to try and peek into the child project.  For example:
    podman build -f ./src/main/docker/Dockerfile.jvm --tag auth-service:1.0.2 --label profile:jvm .
    podman save auth-service:1.0.2 | gzip -c > ./target/auth-service_1.0.2.gz

Using Maven, the build process only requires a single command line: mvn package -P jvm or mvn package -P native , which is convenient, but maybe Maven is the wrong tool for this job?  If there are any suggestions (maybe tools which can help with the whole build-deliver-install-configure-activate-monitor cycle), I would really appreciate hearing what tools are commonly being used and related best practices.

Regarding departmental/corporate Maven and container image repositories, the use of snapshots, and continuous integration: those are all end goals which I am working towards.

[Tim Holloway]

A laudable goal indeed.

I've used Maven to build RPM packages, but I'll confess that I do my Docker stuff via Ansible.

It's also possible that either Gradle or a build system like Jenkins might be more comfortable, but I can't be certain.

And if you haven't looked https://dzone.com/articles/build-docker-image-from-maven that looks like a good option.

But again, making Maven "peek" to find versions isn't the Maven Way. Maven builds at all levels should be determinate.

Now at a rough evaluation, I'd expect the top-level POM to be building the deployable Java component AND having the Docker goal(s), and thus it should know both its own version and the dependency versions of the sub-projects. I don't think Maven will want any sort of substitutable version numbers at any level, meaning that if you wanted to maintain 2 different production versions of the image, you'd need to clone the POM and put in the different dependency versions. And you could play git branch games if it helped.

But the upshot is that it's made deliberately manual. Sorry.