I am updating an old code and I need to set the version in the pom.xml using the version tag and then from there set different files with the version:

1. Manifest file when building the jar
2. I need to create a version.txt to be packaged in jar to get the version at runtime
3. Deploy the same version.txt file in a server, so, I can compare both versions and know when the client is running an older version from the cache files

I tried to create version.properties and then set the pom.xml but I see a warning from maven that should be that other way around

I am updating an old code and I need to set the version in the pom.xml using the version tag and then from there set different files with the version:

1. Manifest file when building the jar
2. I need to create a version.txt to be packaged in jar to get the version at runtime
3. Deploy the same version.txt file in a server, so, I can compare both versions and know when the client is running an older version from the cache files

I tried to create version.properties and then set the pom.xml but I see a warning from maven that should be that other way around

• maven
• version
• pom.xml
• versioning

2 Answers 2

In the following I'm assuming that the information needs to be available at runtime. You haven't specified if that is required.

I've found that for this scenario - static build information - the solution to put it into the JAR's manifest isn't optional. In theory this is indeed what the JAR Manifest is designed for. In practice, however, it is really hard to get hold of that Manifest in real life .. in a consistent way. You cannot just load META-INF/MANIFEST.MF from the classpath as the one you get back will be random. Also, you have to take into account that the class may be loaded by a custom ClassLoader. In any case, don't hesitate to utilize the Manifest as a place to put this type of information, just don't expect that you can get hold of it from within the application.

The other idea: To create a text file which is then packaged in your JAR. This is a good idea .. assuming that you really need a text representation and that it is not just an intermediary that you'll load at runtime from the classpath.

If your aim is to have this information available at runtime then I've found the Templating Maven Plugin to a better option. It is designed for exactly this purpose. With this approach the information, such as ${project.version}, becomes part of your Java source code, for example as fields on a class. For example, such class may look like this:

public class BuildInfo {

    // Values '${...}' will be replaced by Maven at build time
    public final String version = "${project.version}";

    private BuildInfo() {}
}

The plugin is made and maintained by the Maven folks. It claims to solve the problem the right way. It saves you from doing filtering on all of your regular .java files which I won't recommend. (there's a reason why Maven doesn't do filtering on src/main/java by default)

I had to add the mave jar plugin to add the version to the manifest file out of the version from pom.xml

 <plugin>
    <!-- Build an executable JAR -->
    <groupId>.apache.maven.plugins</groupId>
    <artifactId>maven-jar-plugin</artifactId>
    <version>3.4.2</version>
    <configuration>
        <archive>
            <manifestEntries>
                <Trusted-Library>true</Trusted-Library>
                <permissions>all-permissions</permissions>
                <Application-Name>Project</Application-Name>
                <Codebase>*</Codebase>
                <Trusted-Only>true</Trusted-Only>
                <Main-Class>com.project.LoadClass</Main-Class>
                <Specification-Title>${project.artifactId}</Specification-Title>
                <Specification-Version>${project.version}</Specification-Version>
                <Implementation-Title>${project.artifactId}</Implementation-Title>
                <Implementation-Version>${project.version}</Implementation-Version>
                <Implementation-Vendor-Id>${project.groupId}</Implementation-Vendor-Id>
                <Build-Time>${maven.build.timestamp}</Build-Time>
            </manifestEntries>
        </archive>
    </configuration>
</plugin>

Then I used the maven resources plugin

 <plugin>
    <artifactId>maven-resources-plugin</artifactId>
    <version>3.3.1</version>
    <executions>
        <execution>
            <id>generate-version-file</id>
            <phase>process-resources</phase>
            <goals>
                <goal>copy-resources</goal>
            </goals>
            <configuration>
                <outputDirectory>${project.build.directory}/classes</outputDirectory>
                <resources>
                    <resource>
                        <directory>src/main/resources</directory>
                        <filtering>true</filtering>
                        <includes>
                            <include>version.txt</include>
                        </includes>
                    </resource>
                </resources>
            </configuration>
        </execution>
    </executions>
</plugin>

I created the version.txt file in src/main/resources folder with the following content

version=${project.version}
buildTimestamp=${maven.build.timestamp}

When I run the maven commands mvn package or mvn site, that will copy the version.txt to folder target/classes and replace the values in the version.txt out of the values from pom.xml

P.S.

I added the following https://maven.apache./maven-ci-friendly.html

I think is the best solution without adding a plugin and make compatible with CI tool pipeline

I just simply set:

<project>
   <version>${revision}</version>

(revision is a maven reserved property)

The idea is that the version is no longer in the pom.xml. You have to set it as a maven arg :

mvn -Drevision=what.you.want …

The value for revision can be pickup up from anywhere : for example, if your build environment is gitlab-ci, you can use the CI_COMMIT_TAG environment variable to get the version from the git tag.

mvn -Drevision=$CI_COMMIT_TAG …

When running locally in intellij, I added the revision as VM argument