I have added a BOM project to RNG. I decided to not generate the BOM using the JBoss plugin and to use a manually curated BOM. The difference is that instead of adding all dependencies to the project pom (for the JBoss plugin to collect), they are added directly to a BOM template. Thus the maintenance overhead is the same. However use of a template BOM ensures we can distribute the exact BOM artifact we would like to use. Notably this can include the ASL 2.0. I do not think we would want to distribute any artifact without an Apache license. The JBoss plugin does not support this feature so for me that was a no-go.
The template BOM has all the properties populated from the current project pom. This includes the version number which is typically changed across all the modules using 'mvn versions:set'. Thus it should work without any changes to the existing release process. The new module is successfully deployed to snapshots by the Jenkins CI build. I updated the [Statistics] project to use the snapshot BOM for dependency management and all CI builds are working. Alex On Thu, 29 Sept 2022 at 18:35, Alex Herbert <alex.d.herb...@gmail.com> wrote: > I have managed to get this to work. However it is not an ideal solution. > > Creating the bom is very simple. It has artifact details and then a > dependencyManagement section. I have created one, installed locally and > verified it works on some of my projects. > > However deploying the bom is a problem in the commons release process. > This requires: > > 1. SNAPSHOTS are deployed to > https://repository.apache.org/content/repositories/snapshots > 2. Non-SNAPSHOTS are deployed to > https://repository.apache.org/service/local/staging/deploy/maven2 > 3. Use of profile test-deploy, irrespective of SNAPSHOT suffix, deploys > locally to file:target/deploy > > The maven deploy plugin has two goals: deploy; deploy-file. > > The deploy goal targets the current project artifact. When used in an > apache based pom this will switch between the two target repositories if it > is a snapshot. But a profile in commons-parent is used to achieve test > deploy support. > > The deploy-file goal requires you explicitly provide the repo details. It > does not provide a switch between snapshot and release versions > automatically. > > If I create a simple BOM it cannot be deployed to the required > repositories as it does not have a distributionManagement section. So this > can be added to the bom but it pollutes the bom. IIUC this will have no > effect on the use of the bom using the pom import scope. It will affect > using it as a parent pom. This also requires a profile to respect the > test-deploy option from commons-parent. > > Extending either the latest apache pom or commons-parent (CP) is not > possible. These have a dependencyManagement section and the two are merged. > So for example the commons RNG bom would specify the junit version brought > in from CP. The last apache pom without a dependencyManagement section is > apache-24 (Jul 2021). This can be extended but a profile still needs to be > added to respect the test-deploy option. All that is gained is not having > to include the distributionManagement section. > > The alternative is to have a project that attempts to use the deploy-file > target to deploy a bom to the correct location. This bom could be > auto-generated or manually curated. I am currently not able to satisfy all > 3 conditions of the commons release process with my test project. Detection > of the snapshot version and changing plugin execution logic is problematic > using maven's configuration. I am looking for a plugin that may help with > this. Currently I have tried the build-helper plugin without success [9]. > > I would not wish to require deployment to be based on user-selected > profiles. This is subject to user error and could send a release build > (non-SNAPSHOT) to the snapshots repo. So currently the only solution I have > is a non-commons project module that has a few additions to the bom to make > it work as a pom that controls its own deployment. > > Details: > > The maven documentation on the dependency mechanism suggests putting the > bom pom at the top of the project hierarchy [1]. The standard multi-module > pom would be next. However for the commons build the bom pom would have to > inherit from commons-parent. That has a dependency management section for > junit. So if the bom is imported you also receive the junit dependency > management. > > Ideally the bom should be as simple as possible with artifact coordinates > and the dependency management section. See examples [3,4]. These are > generated by the gradle maven publish plugin [5], which typically for > gradle requires very little configuration (see [6]). > > There is a JBoss plugin to auto-generate a bom [2]. It produces a nice > simple bom. It is missing some sections that could be useful (url, license, > scm). However I could not find a plugin to deploy the generated bom. Using > the maven deploy:deploy-file goal does not have a mechanism to switch > between targeting a snapshot repo and a release repo (unlike the > deploy:deploy goal). So my solution is a simple bom pom that has no parent. > It explicitly contains all the RNG dependencies and must be manually > maintained. It could be auto-generated with the JBoss plugin but that omits > a final requirement. I had to add a distributionManagement section to the > pom for the Apache repos. With this configuration I am able to run 'mvn > deploy' in the module and it deploys to the snapshot repo. > > I do not know if this will stage correctly when running the deploy goal > with a release version. It should target the apache release staging repo > [7]. However since the pom does not extend either the Apache parent pom or > the commons parent pom (due to their inclusion of a dependencyManagement > section) I cannot be sure that the standard maven configuration is going to > work in our build release process. > > The alternative is to find a way to add deploy:file selection logic based > on the SNAPSHOT suffix and the test-deploy profile. > > Note: It is not possible to add a dependencyManagement section in the > local maven settings.xml file [8] and activate with a profile. The > settings.xml supports a subset of the entire pom. It is possible to add > properties in a profile that define the target repo (namely > altDeploymentRepository). This property is used by the commons-build-plugin > for a test-deploy dry run. So this could be used to minimise additions to > the actual bom. > > If using auto-generation then the management of the dependencies has to be > done in the generate-bom module. If manually curating the bom then it has > to be done in the bom itself. So management of the dependencies for the > final bom has to be done somewhere. Note that it cannot be done in the > current dist-archive module which already includes these dependencies. This > is because it also includes sources and javadoc dependencies which breaks > the JBoss generated bom. > > Currently I would like to get this to work with a standard commons module > that deploys a separate bom file to the correct location. That would ensure > we produce the minimal bom possible. The alternative is a non-standard > commons module that is the bom itself, with added sections to support the > commons release process. > > Alex > > [1] > https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html > [2] https://github.com/jboss/bom-builder-maven-plugin > [3] > https://search.maven.org/artifact/org.springframework/spring-framework-bom/5.3.23/pom > [4] https://search.maven.org/artifact/org.junit/junit-bom/5.9.1/pom > [5] https://github.com/gradle-bom/gradle-bom-generator-plugin > [6] > https://github.com/junit-team/junit5/blob/main/junit-bom/junit-bom.gradle.kts > [7] https://repository.apache.org/service/local/staging/deploy/maven2 > [8] https://maven.apache.org/settings.html > [9] > https://www.mojohaus.org/build-helper-maven-plugin/regex-property-mojo.html > > > On Thu, 29 Sept 2022 at 13:21, Xeno Amess <xenoam...@gmail.com> wrote: > >> even better if we have a BOM for whole apache commons. >> ________________________________ >> From: Gary Gregory <garydgreg...@gmail.com> >> Sent: Thursday, September 29, 2022 8:05:14 PM >> To: Commons Developers List <dev@commons.apache.org> >> Subject: Re: [rng] Release 1.5 with Bill Of Materials (BOM) >> >> That sounds like a good idea! >> >> Gary >> >> On Thu, Sep 29, 2022 at 5:27 AM Alex Herbert <alex.d.herb...@gmail.com> >> wrote: >> >> > I think RNG is ready for a release. >> > >> > In 1.5 the multi-module project rearranges a few methods to default >> > interface methods in a different module. This is binary compatible. >> However >> > it requires that all versions of the modules are matched. If the other >> > modules are explicitly imported by a transitive dependency as a lower >> > version then this will cause a runtime error due to missing methods. >> > >> > I suggest we create a Bill of Materials (BOM) as a separate artifact to >> be >> > deployed to maven for dependency management. Downstream users can then >> > include this in their POM and all versions of the RNG modules would be >> > matched. >> > >> > <dependencyManagement> >> > <dependencies> >> > <dependency> >> > <groupId>org.apache.commons</groupId> >> > <artifactId>commons-rng-bom</artifactId> >> > <version>1.5</version> >> > <type>pom</type> >> > <scope>import</scope> >> > </dependency> >> > </dependencies> >> > </dependencyManagement> >> > >> > Alex >> > >> >
