You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Alex Herbert <al...@gmail.com> on 2022/09/29 09:27:20 UTC
[rng] Release 1.5 with Bill Of Materials (BOM)
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
Re: [rng] Release 1.5 with Bill Of Materials (BOM)
Posted by Alex Herbert <al...@gmail.com>.
I tried a RC1 for RNG and it failed on validation of the BOM within nexus.
The BOM was staged but the GPG signature file did not match the artifact.
I have updated the project to sign and deploy the BOM and will try again
when the change is verified to work for snapshots by the CI builds.
Alex
Re: [rng] Release 1.5 with Bill Of Materials (BOM)
Posted by Gary Gregory <ga...@gmail.com>.
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 <al...@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 <al...@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 <xe...@gmail.com> wrote:
> >
> >> even better if we have a BOM for whole apache commons.
> >> ________________________________
> >> From: Gary Gregory <ga...@gmail.com>
> >> Sent: Thursday, September 29, 2022 8:05:14 PM
> >> To: Commons Developers List <de...@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 <al...@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
> >> >
> >>
> >
>
Re: [rng] Release 1.5 with Bill Of Materials (BOM)
Posted by Alex Herbert <al...@gmail.com>.
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 <al...@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 <xe...@gmail.com> wrote:
>
>> even better if we have a BOM for whole apache commons.
>> ________________________________
>> From: Gary Gregory <ga...@gmail.com>
>> Sent: Thursday, September 29, 2022 8:05:14 PM
>> To: Commons Developers List <de...@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 <al...@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
>> >
>>
>
Re: [rng] Release 1.5 with Bill Of Materials (BOM)
Posted by Alex Herbert <al...@gmail.com>.
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 <xe...@gmail.com> wrote:
> even better if we have a BOM for whole apache commons.
> ________________________________
> From: Gary Gregory <ga...@gmail.com>
> Sent: Thursday, September 29, 2022 8:05:14 PM
> To: Commons Developers List <de...@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 <al...@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
> >
>
Re: [rng] Release 1.5 with Bill Of Materials (BOM)
Posted by Alex Herbert <al...@gmail.com>.
On Thu, 29 Sept 2022 at 13:21, Xeno Amess <xe...@gmail.com> wrote:
> even better if we have a BOM for whole apache commons.
>
A BOM specifies what versions are expected to work together. All commons
components are low level and have few dependencies. Ideally a BOM is not
required as we try to ensure binary and functional compatibility, bugs
fixes excluded, between releases. So all versions of commons components
should work together.
This changes when one component imports another using a specific version
number to obtain a specific class/method implementation. Perhaps the best
we could do is have a BOM with all the latest versions. Each time a release
is made then the BOM must be rereleased with updated versions. This would
require a project to deploy a BOM that imports all the commons components
as dependencies and tracks the latest versions. It would ensure versions
are up-to-date but would do nothing to ensure they are compatible. To
verify it would require (a lot of) integration testing.
In the case of a multi-module component this process is simplified. All
modules are built using the same Java target version. All versions are
released using the same version number. All versions are tested to work
together by the current test suite. The BOM becomes a simple list of what
versions to use together for the release of all the modules.
I am not against a Commons BOM. But it requires more work than I am willing
to do. I think it would require:
- Creating a pom that imports all top-level components
- Viewing the current dependency tree (e.g. 'mvn dependency:tree')
- Looking for transitive dependencies that are not the latest versions
- Updating the pom to explicitly resolve transitive dependencies (but which
version do we wish to guarantee works with the rest of the items in the BOM)
Here the JBoss plugin to create a BOM may help to collate dependencies. But
it would do nothing to guarantee they all work together.
This process becomes more complicated when non-commons components are in
the tree. I would not wish to maintain a BOM which has non-commons
components that are not exercised directly in our tests.
Alex
Re: [rng] Release 1.5 with Bill Of Materials (BOM)
Posted by Xeno Amess <xe...@gmail.com>.
even better if we have a BOM for whole apache commons.
________________________________
From: Gary Gregory <ga...@gmail.com>
Sent: Thursday, September 29, 2022 8:05:14 PM
To: Commons Developers List <de...@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 <al...@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
>
Re: [rng] Release 1.5 with Bill Of Materials (BOM)
Posted by Gary Gregory <ga...@gmail.com>.
That sounds like a good idea!
Gary
On Thu, Sep 29, 2022 at 5:27 AM Alex Herbert <al...@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
>