GH-4107: jena-bom altered to include jena artifacts using flatten-maven-plugin

[Aklakan]

GitHub issue resolved #4107

Pull request Description: This proposal adds flatten-maven-plugin to jena-bom in order to produce a parent-free "jena-only" pom.

I think this should solve the reported issue that jena-bom overrides versions from a parent pom.

Minimal downstream project pom:

<?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>org.example.jena</groupId>
    <artifactId>jena-bom-test</artifactId>
    <packaging>jar</packaging>

    <properties>
      <jena.version>6.3.0-SNAPSHOT</jena.version>
    </properties>

    <parent>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-parent</artifactId>
      <version>4.1.0</version>
    </parent>

    <dependencyManagement>
      <dependencies>
        <dependency>
          <groupId>org.apache.jena</groupId>
          <artifactId>jena-bom</artifactId>
          <version>${jena.version}</version>
          <type>pom</type>
          <scope>import</scope>
        </dependency>
     </dependencies>
  </dependencyManagement>

</project>

Creating the effective pom with and without the jena dependency commented out, and then creating a diff shows that the only difference is the jena deps. This means that all non-jena dependency versions are taken from spring-boot-starter-parent, and adding jena-bom does not alter any versions.

mvn help:effective-pom > without-jena.txt # jena dep commented out
mvn help:effective-pom > with-jena.txt
diff without-jena.txt with-jena.txt

+       <groupId>org.apache.jena</groupId>
+         <artifactId>apache-jena-libs</artifactId>
+         <version>6.3.0-SNAPSHOT</version>
+         <type>pom</type>
+       </dependency>
+       <dependency>
+         <groupId>org.apache.jena</groupId>
+         <artifactId>jena-base</artifactId>
+         <version>6.3.0-SNAPSHOT</version>
+       </dependency>
+       <dependency>
+         <groupId>org.apache.jena</groupId>
+         <artifactId>jena-core</artifactId>
+         <version>6.3.0-SNAPSHOT</version>
+       </dependency>

---

• [ ] Tests are included.
• [ ] Documentation change and updates are provided for the Apache Jena website
• Commits have been squashed to remove intermediate development commit messages.
• Key commit messages start with the issue number (GH-xxxx)

By submitting this pull request, I acknowledge that I am making a contribution to the Apache Software Foundation under the terms and conditions of the Contributor's Agreement.

---

See the Apache Jena "Contributing" guide.

[afs]

My understand is that the issue is BOM-related.

apache-jena-libs isn't a BOM - it does not have a <dependencyManagement> section.

It's also been around a very long time!

[Aklakan]

Right, I removed the flatten plugin from apache-jena-libs.

[afs]

Thanks.

As I understand it, a regular <dependence> on an artifact does not pull in the artifacts parent dependency management, only the recursive dependency tree.

Eclipse Jetty uses flatten-maven-plugin. Some other projects I looked at do not take any special actions for BOMs.

[Aklakan]

According to the spring-boot-starter-parent documentation this is a legit way to kick start a spring boot project. I wasn't aware of this approach of using their parent pom (and the doc also mentions that there may be reasons to avoid it) - but getting all the versions of a spring/spring-boot based app right is frequently a pain - and if this flattened pom helps with it, then all the better.

[afs]

Let's put this into the codebase.

I can't recreate a problem using apache-jena-libs on its own, either as a direct <dependency> or in <dependencyMangement>. Only if jena-bom is present.

[afs]

I've removed the "GitHub issue resolved" - that's pending clarification of the use of apache-jena-libs on it's own.

[afs]

The .flattened-pom.xml is not great. It includes the parent <properties>.

The best I have come up with so far is remove some POM elements (by looking at the source code for flatten-maven-plugin). For example, this is a quite heavy trimming:

        <configuration>
          <flattenMode>bom</flattenMode>
          <pomElements>
            <properties>remove</properties>
            <distributionManagement>remove</distributionManagement>
            <mailingLists>remove</mailingLists>
            <scm>remove</scm>
            <issueManagement>remove</issueManagement>
          </pomElements>
        </configuration>

(We should separately tidy up the top Jena POM.)

[Aklakan]

The question is how the flattened pom behaves during release since it doesn't have a parent.

Looking at spring-boot-starter-parent and its parent spring-boot-dependencies neither declares a dependencyManagement section.
So it seems that a release can use this information from an original pom but then only attach and publish the trimmed/flattened one.

So it seems ok to add those trim settings.
Do you want to add them in your own commit?

A few further considerations:

• Sonatype may still demand presence of some of the metadata fields for the published pom.
• The flatten-maven-plugin doc also mentions settings for controlling behavior with profiles. I suppose the build of the flattened pom respects the settings of whatever active profiles - so it should be fine.
• The build-helper-maven-plugin could be used to attach the original/raw jena-bom pom.xml under some classifier in case it should be published anyway just in case.

[rvesse]

• Sonatype may still demand presence of some of the metadata fields for the published pom.

Yeah that's a gotcha and if a single module fails validation Sonatype rejects the entire release, at least for stuff published directly to central.

However not sure exactly how Apache releases get published and validated to Central these days, if they go to an Apache repository that central simply mirrors as-is without further validation it might be fine, may need to ask someone from Maven PMC on that point

[afs]

All I think we need to remove is <properties>remove</properties>.

We could do with updating the parent POM entries ... ("JIRA"??!!?) but that's a different matter.

[Aklakan]

All I think we need to remove is <properties>remove</properties>.

If you mean add (double negations 😆), I agree - I updated the PR and included <properties>remove</properties>

[afs]

• Sonatype may still demand presence of some of the metadata fields for the published pom.

Yeah that's a gotcha and if a single module fails validation Sonatype rejects the entire release, at least for stuff published directly to central.

Nexus (repository.apache.org) has checking rules before you can release. (and the apache release plugin?) .. not sure what the complete set is (checksum, signatures, ...) and Jena's 6.2 release has dropped off the list now

I thought it covered much the same as Sonatype but the path is central is direct with shorter polling times. There was a glitch a few months ago when ASF releases didn't get sync'ed as promptly as normal so likely it's direct.