*Summary
*
Specifying the Java version (11, 17, ...)
and latest maven plugin versions (compiler 3.11.0, surefire 3.1.2,
failsafe, ...)
in every pom is a tedious and brittle.
Existing parent poms are de-standarized and bloated.
This proposal solves that by introducing
a standardized parent pom for Java 17 (and Java 11)
that sets the latest maven plugins versions.
*Motivation
*Any professional Maven build:
- has reproducible builds
- uses the latest maven plugin versions
- uses a recent Java version (not Java 5 or 8)
- specify the minimum Maven version
To that do it, users have to add 50+ lines to their pom.xml:
<properties>
<maven.compiler.release>17</maven.compiler.release>
<maven.min.version>3.9.2</maven.min.version>
<version.compiler.plugin>3.11.0</version.compiler.plugin>
<version.surefire.plugin>3.1.2</version.surefire.plugin>
<version.source.plugin>3.3.0</version.source.plugin>
<version.javadoc.plugin>3.5.0</version.javadoc.plugin>
<version.dependency.plugin>3.6.0</version.dependency.plugin>
<version.enforcer.plugin>3.3.0</version.enforcer.plugin>
...
<build>
...
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>${version.compiler.plugin}</version>
...
**
*Existing implementations*
_Superpom_
- The superpom version is not specified in the pom.xml. It's not a
reproducible build.
- The superpom does not enforce a minimum Maven version (catch 22).
- The superpom uses java 8. To overwrite it, do it for the compiler
plugin, the javadoc plugin, ...
- The superpom is not released regularly to update to the latest maven
plugin versions of compiler, surefire, failsafe, etc.
- There is no documention on how to lock in the superpom version.
Therefore, the superpom is not a solution.
_JBoss parent and Spring parent_
The JBoss parent and Spring parent poms target only their own users (=
not every Maven user) and provide a much wider scope (= bloat).
They:
- Set url and mailing lists for springframework.org or jboss.org
- Set the license
- Specify non-standarized maven plugins (spring plugin, cobertura,
injection, ...)
- Add a whole bunch of "sane for them" default plugin configuration that
overwrite the defaults of the Maven plugins.
The JBoss parent pom:
https://central.sonatype.com/artifact/org.jboss/jboss-parent/39
The Spring boot starter parent pom:
https://central.sonatype.com/artifact/org.springframework.boot/spring-boot-starter-parent/3.1.1
More importantly, these groupId are not neutral territory.
Ideally, the Jboss parent and spring parent have a parent with their
common properties.
Therefore, a 3th party parent pom is not a solution.
*Proposal
*Create a standarized, neutral parent for Java 17 that can be used as such:
<parent>
<groupId>org.apache.maven.parents</groupId>
<artifactId>parents-java-17</artifactId>
<version>2023.06.28</version>
</parent>
(Think "FROM ...:17-jre-alpine" in a Docker file.)
Similarly, there's a org.apache.maven.parents:parents-java-11 pom.
This parent pom has:
- Plugin versions defined for only and all Maven plugins of groupId
org.apache.maven.
- A compatible set of Maven plugin versions
- The latest Maven plugin versions as of 2023.06.28 (not withstanding
the previous line)
- Java set to 17
- The minimum maven set to the latest Final maven release as of 2023.06.28
*GroupId, ArtifactId and Versioning
*The groupId, artifactId and versioning are open for debate:
Proposal A: org.apache.maven.parents:parents-java-17:2023.06.28
The artifactId contains the Java number.
The version contains the release-cut-off date, so it's easy to see how
old it is.
Proposal B: org.apache.maven.parents:parents-java:17.2023.06.28
The version starts with the Java number.
The version contains the release-cut-off date, so it's easy to see how
old it is.
Proposal C: org.apache.maven.parents:parents-java-17:1.0.0
The artifactId contains the Java number.
Every release increases the major version number.
This is Apache version guidelines compatible.
Proposal D: org.apache.maven.parents:parents-java:17.1.0
The major version number is the Java number.
Every release increases the minor version number.
This is Apache version guidelines compatible.
(More proposals welcome.)
What do you think?
--
With kind regards,
Geoffrey De Smet
