Howdy,
This is an interesting idea, but IMHO without some "mixin" support, it
would work only for "shallow" (or flat?) kinds of projects....
Forges like ASF (and Maven itself as part of ASF) have quite deep parent
POM hierarchy, and parents are not only about Java, as they also contain:
- deployment setup
- license
- team
- etc
So, if we assume there is some "forge X", their parent should contain some
common data regarding license (assuming they deliver the same licensed
stuff) and deployment (assuming the forge is unified regarding deploy).
For this forge would remain the only option to make forge parent use your
proposed Java parent as parent, but this also implies then _that everything
forge delivers_ would be aligned on the same Java version?
And many times this is not applicable.
With use of a javac release switch (so no animal sniffer needed), that is
parameterizable (so is in POM/properties) it becomes possible to target
different bytecode outputs.
And I wholeheartedly agree with following:
- require latest (LTS) Java for building
- require latest Maven for building
- and bytecode output is left to the child project (to override the release
property. if needed)
Thanks
T
On Wed, Jun 28, 2023 at 8:40 AM Geoffrey De Smet <ge0ffrey.s...@gmail.com>
wrote:
> *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
>
