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 > > >
