I don't see the point of a Commons wide BOM POM. I also can't see someone wanting to import all of Commons. Is there a use case I am missing?
Gary On Mon, Oct 3, 2022, 07:31 Alex Herbert <alex.d.herb...@gmail.com> wrote: > 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 > >> > > >> > > >
