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/23 10:24:59 UTC
[rng] simplify pom version management
The pom for RNG has many plugins that explicitly manage a version. IIUC
this was done to surpass the version in commons parent. However this is no
longer required. The following plugins all have a higher version in CP 54
(version shown at the end of the line):
<rng.pmd.version>3.14.0</rng.pmd.version> 3.19.0
<rng.pmd.dep.version>6.37.0</rng.pmd.dep.version> 6.49.0
<rng.checkstyle.version>3.1.2</rng.checkstyle.version> 3.2.0
<rng.checkstyle.dep.version>8.45</rng.checkstyle.dep.version> 9.3
<rng.antrun.version>1.8</rng.antrun.version> Managed in
org.apache:apache parent as 3.1.0
<rng.surefire.version>3.0.0-M5</rng.surefire.version> 3.0.0-M7
<rng.junit5.version>5.7.2</rng.junit5.version> 5.9.0
I propose to update to CP 54 and then drop this version management.
The drawback is that any upgrade of the project to CP will be hit with many
changes, some of which may require code changes or rule exceptions. This
can be mitigated by explicit management of the respective properties in CP
back to versions that do work. However keeping inline with CP takes
advantage of the latest versions maintained by dependabot.
Alex
Re: [rng] simplify pom version management
Posted by Alex Herbert <al...@gmail.com>.
>
> By the way (but totally unrelated): the [RNG] build fails because RAT
> stumbles
> on a ".gitattributes" file.
>
Another bug I noted when testing CP 54. I have added the suppression to the
apache-rat config in the CP 55-SNAPSHOT.
Alex
Re: [rng] simplify pom version management
Posted by Alex Herbert <al...@gmail.com>.
>
> On Sat, Sep 24, 2022, 14:40 Alex Herbert <al...@gmail.com> wrote:
> >
> > I will set up a Jenkins CI build to deploy commons-parent to snapshots.
> > Then I can test the build of RNG using the latest CP snapshot. This may
> > help feedback whether changes made in CP will be problematic for
> > dependent projects trying to keep up with CP. If the idea works then we
> can
> > extend it to some other child projects (lang, etc).
>
>
I have tried this idea. The deployment of CP is working. So any project can
now just update to the latest snapshot version in their pom for testing
purposes.
However the Jenkins build of a child project using the snapshot fails. I
created an action to update to the latest snapshot in the pom which runs
and is successful. The next step of the Jenkins CI build is to scan the
project pom dependencies. This errors on the commons-parent snapshot
version. See for example the build log here [1].
This Jenkins specific step of 'Parsing POMs' occurs before the maven build
command. So it does not seem possible to modify the pom to use the parent
snapshot when running a Jenkins build.
I have disabled the project but left it as there may be some settings I
have not discovered that will allow it to work.
Alex
[1]
https://ci-builds.apache.org/job/Commons/job/commons-rng__jdk11_parent_snapshot/lastBuild/console
Re: [rng] simplify pom version management
Posted by Gary Gregory <ga...@gmail.com>.
Note that I do not plan on maintaining any other builds than GitHub. I'm
sure there is a way to deploy from GitHub using GitHub secrets, I've heard
it discussed, but I have not researched it.
Gary
On Sat, Sep 24, 2022, 14:40 Alex Herbert <al...@gmail.com> wrote:
> On Sat, 24 Sept 2022 at 19:29, Gary Gregory <ga...@gmail.com>
> wrote:
>
> > I sometimes deploy components from the command line, I never use our
> > Jenkins instance for anything so I can't speak to any builds there, I
> only
> > rely on GitHub actions for validating PRs and changes.
> >
>
> Thanks Gary. I checked and the CP version in the snapshots build for
> 55-SNAPSHOT is not the latest version from master. Is it possible you
> deployed this when testing for the recent release?
>
> I will set up a Jenkins CI build to deploy commons-parent to snapshots.
> Then I can test the build of RNG using the latest CP snapshot. This may
> help feedback whether changes made in CP will be problematic for
> dependent projects trying to keep up with CP. If the idea works then we can
> extend it to some other child projects (lang, etc).
>
> Alex
>
Re: [rng] simplify pom version management
Posted by Alex Herbert <al...@gmail.com>.
On Sat, 24 Sept 2022 at 19:29, Gary Gregory <ga...@gmail.com> wrote:
> I sometimes deploy components from the command line, I never use our
> Jenkins instance for anything so I can't speak to any builds there, I only
> rely on GitHub actions for validating PRs and changes.
>
Thanks Gary. I checked and the CP version in the snapshots build for
55-SNAPSHOT is not the latest version from master. Is it possible you
deployed this when testing for the recent release?
I will set up a Jenkins CI build to deploy commons-parent to snapshots.
Then I can test the build of RNG using the latest CP snapshot. This may
help feedback whether changes made in CP will be problematic for
dependent projects trying to keep up with CP. If the idea works then we can
extend it to some other child projects (lang, etc).
Alex
Re: [rng] simplify pom version management
Posted by Gary Gregory <ga...@gmail.com>.
I sometimes deploy components from the command line, I never use our
Jenkins instance for anything so I can't speak to any builds there, I only
rely on GitHub actions for validating PRs and changes.
Gary
On Sat, Sep 24, 2022, 14:25 Alex Herbert <al...@gmail.com> wrote:
> I have updated RNG to the latest CP and reverted the plugin versions to
> those from CP. The entire build (including examples) is stable and only a
> few non-POM changes were required.
>
> Perl code to replace the current CP with the next increment up:
>
> perl -n -i -e '$on = m/commons-parent/ if m/artifactId/; $on &&
> s/(<version>)(\d+)(<)/$1.($2+1)."-SNAPSHOT".$3/e; print;' pom.xml
>
> This makes some assumptions about the structure of the pom (version must be
> after artifactId, only one occurrence of commons-parent in artifactIds,
> version numbers are major only: 54, 55, 56, etc).
>
> I have set-up a provisional Jenkins build to build RNG with the latest
> commons-parent [1]. This is as yet untested. The script execution details
> state that #!/bin/perl would execute perl and so I assume perl is on the
> command line. I do not know if this script will execute after SCM checkout
> or before.
>
> However I cannot find a build for commons parent on Jenkins. So I do not
> know how that is being deployed to the snapshots repository [2]. I could
> create a Jenkins build to do this. But first I would like to find out what
> is currently deploying to snapshots. I thought all old CI jobs have
> migrated to ci-builds.apache.com. The GH actions build for commons-parent
> does not use the deploy goal (and I believe would not have permissions).
>
> Alex
>
> [1]
>
> https://ci-builds.apache.org/job/Commons/job/commons-rng__jdk11_parent_snapshot/
> [2]
>
> https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-parent/
>
Re: [rng] simplify pom version management
Posted by Alex Herbert <al...@gmail.com>.
I have updated RNG to the latest CP and reverted the plugin versions to
those from CP. The entire build (including examples) is stable and only a
few non-POM changes were required.
Perl code to replace the current CP with the next increment up:
perl -n -i -e '$on = m/commons-parent/ if m/artifactId/; $on &&
s/(<version>)(\d+)(<)/$1.($2+1)."-SNAPSHOT".$3/e; print;' pom.xml
This makes some assumptions about the structure of the pom (version must be
after artifactId, only one occurrence of commons-parent in artifactIds,
version numbers are major only: 54, 55, 56, etc).
I have set-up a provisional Jenkins build to build RNG with the latest
commons-parent [1]. This is as yet untested. The script execution details
state that #!/bin/perl would execute perl and so I assume perl is on the
command line. I do not know if this script will execute after SCM checkout
or before.
However I cannot find a build for commons parent on Jenkins. So I do not
know how that is being deployed to the snapshots repository [2]. I could
create a Jenkins build to do this. But first I would like to find out what
is currently deploying to snapshots. I thought all old CI jobs have
migrated to ci-builds.apache.com. The GH actions build for commons-parent
does not use the deploy goal (and I believe would not have permissions).
Alex
[1]
https://ci-builds.apache.org/job/Commons/job/commons-rng__jdk11_parent_snapshot/
[2]
https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-parent/
Re: [rng] simplify pom version management
Posted by Alex Herbert <al...@gmail.com>.
On Fri, 23 Sept 2022 at 17:24, Gilles Sadowski <gi...@gmail.com> wrote:
>
> Oops sorry, I had modified the wrong line.
> Within the <parent> section, it doesn't work. :-(
>
Good to know. I could not reproduce. I think I may have to hack a single
line perl program to perform the replacement. It would at least allow a
trial of a jenkins build dependent on CP to run with the latest CP snapshot.
Alex
Re: [rng] simplify pom version management
Posted by Gilles Sadowski <gi...@gmail.com>.
Le ven. 23 sept. 2022 à 18:18, Gilles Sadowski <gi...@gmail.com> a écrit :
>
> Le ven. 23 sept. 2022 à 18:08, Alex Herbert <al...@gmail.com> a écrit :
> >
> > On Fri, 23 Sept 2022 at 16:02, Alex Herbert <al...@gmail.com>
> > wrote:
> >
> > >
> > >
> > > I wonder if we can set up a Jenkins build to use the current CP snapshot
> > > for a project. The mvn:versions command can change the project parent.
> > > However this does not work for RNG:
> > >
> > > mvn versions:update-parent -DallowSnapshots=true
> > >
> > > This only updates to 54, not 55-SNAPHSOT. I presumed the snapshots for CP
> > > are not deployed anywhere. However they do seem to be in the correct
> > > location with a 55-SNAPSHOT recently deployed there [1]. Running with the
> > > -X flag shows that the apache snapshots repo is being used for remote
> > > artifacts. So something is not working with this command. If it can be made
> > > to work then the Jenkins CI build can be configured using a pre-build step
> > > to execute the shell command.
>
> In the POM, if changing
> ---CUT---
> <version>54</version>
> ---CUT---
> to
> ---CUT---
> <version>LATEST</version>
> ---CUT---
>
> Then running
> $ mvn -Dversions:parentVersion=55-SNAPSHOT
> -Dversions:allowSnapshots=true -Dversions:forceUpdate=true
> versions:update-parent
> did change the line to
> ---CUT---
> <version>1.5-SNAPSHOT</version>
> ---CUT---
Oops sorry, I had modified the wrong line.
Within the <parent> section, it doesn't work. :-(
Gilles
>
> By the way (but totally unrelated): the [RNG] build fails because RAT stumbles
> on a ".gitattributes" file.
>
> Best,
> Gilles
>
> >
> > This seems to be a long standing bug in mvn:versions. I found a bug report
> > from 2017 with the same use case: a project wishes to update the parent to
> > the latest snapshot deployed to the snapshots repo (see [1]).
> >
> > Without a simple mvn command to resolve the latest CP I do not see how this
> > can be easily maintained. A one line program would be required to inject
> > the latest version into the POM based on incrementing the current version
> > number by 1 and adding the SNAPSHOT suffix.
> >
> > Alex
> >
> > [1] https://github.com/mojohaus/versions-maven-plugin/issues/233
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [rng] simplify pom version management
Posted by Gilles Sadowski <gi...@gmail.com>.
Le ven. 23 sept. 2022 à 18:08, Alex Herbert <al...@gmail.com> a écrit :
>
> On Fri, 23 Sept 2022 at 16:02, Alex Herbert <al...@gmail.com>
> wrote:
>
> >
> >
> > I wonder if we can set up a Jenkins build to use the current CP snapshot
> > for a project. The mvn:versions command can change the project parent.
> > However this does not work for RNG:
> >
> > mvn versions:update-parent -DallowSnapshots=true
> >
> > This only updates to 54, not 55-SNAPHSOT. I presumed the snapshots for CP
> > are not deployed anywhere. However they do seem to be in the correct
> > location with a 55-SNAPSHOT recently deployed there [1]. Running with the
> > -X flag shows that the apache snapshots repo is being used for remote
> > artifacts. So something is not working with this command. If it can be made
> > to work then the Jenkins CI build can be configured using a pre-build step
> > to execute the shell command.
In the POM, if changing
---CUT---
<version>54</version>
---CUT---
to
---CUT---
<version>LATEST</version>
---CUT---
Then running
$ mvn -Dversions:parentVersion=55-SNAPSHOT
-Dversions:allowSnapshots=true -Dversions:forceUpdate=true
versions:update-parent
did change the line to
---CUT---
<version>1.5-SNAPSHOT</version>
---CUT---
By the way (but totally unrelated): the [RNG] build fails because RAT stumbles
on a ".gitattributes" file.
Best,
Gilles
>
> This seems to be a long standing bug in mvn:versions. I found a bug report
> from 2017 with the same use case: a project wishes to update the parent to
> the latest snapshot deployed to the snapshots repo (see [1]).
>
> Without a simple mvn command to resolve the latest CP I do not see how this
> can be easily maintained. A one line program would be required to inject
> the latest version into the POM based on incrementing the current version
> number by 1 and adding the SNAPSHOT suffix.
>
> Alex
>
> [1] https://github.com/mojohaus/versions-maven-plugin/issues/233
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [rng] simplify pom version management
Posted by Alex Herbert <al...@gmail.com>.
On Fri, 23 Sept 2022 at 16:02, Alex Herbert <al...@gmail.com>
wrote:
>
>
> I wonder if we can set up a Jenkins build to use the current CP snapshot
> for a project. The mvn:versions command can change the project parent.
> However this does not work for RNG:
>
> mvn versions:update-parent -DallowSnapshots=true
>
> This only updates to 54, not 55-SNAPHSOT. I presumed the snapshots for CP
> are not deployed anywhere. However they do seem to be in the correct
> location with a 55-SNAPSHOT recently deployed there [1]. Running with the
> -X flag shows that the apache snapshots repo is being used for remote
> artifacts. So something is not working with this command. If it can be made
> to work then the Jenkins CI build can be configured using a pre-build step
> to execute the shell command.
>
This seems to be a long standing bug in mvn:versions. I found a bug report
from 2017 with the same use case: a project wishes to update the parent to
the latest snapshot deployed to the snapshots repo (see [1]).
Without a simple mvn command to resolve the latest CP I do not see how this
can be easily maintained. A one line program would be required to inject
the latest version into the POM based on incrementing the current version
number by 1 and adding the SNAPSHOT suffix.
Alex
[1] https://github.com/mojohaus/versions-maven-plugin/issues/233
Re: [rng] simplify pom version management
Posted by Alex Herbert <al...@gmail.com>.
On Fri, 23 Sept 2022 at 15:19, Gilles Sadowski <gi...@gmail.com> wrote:
> Hello.
>
> Le ven. 23 sept. 2022 à 15:18, Alex Herbert <al...@gmail.com> a
> écrit :
> >
> > On Fri, 23 Sept 2022 at 13:53, Gilles Sadowski <gi...@gmail.com>
> wrote:
> >
> > > Hello.
> > >
> > > Le ven. 23 sept. 2022 à 12:25, Alex Herbert <al...@gmail.com>
> a
> > > écrit :
> > > >
> > > > The pom for RNG has many plugins that explicitly manage a version.
> IIUC
> > > > this was done to surpass the version in commons parent. However this
> is
> > > no
> > > > longer required. The following plugins all have a higher version in
> CP 54
> > > > (version shown at the end of the line):
> > > >
> > > > <rng.pmd.version>3.14.0</rng.pmd.version> 3.19.0
> > > > <rng.pmd.dep.version>6.37.0</rng.pmd.dep.version> 6.49.0
> > > > <rng.checkstyle.version>3.1.2</rng.checkstyle.version> 3.2.0
> > > > <rng.checkstyle.dep.version>8.45</rng.checkstyle.dep.version> 9.3
> > > > <rng.antrun.version>1.8</rng.antrun.version> Managed in
> > > > org.apache:apache parent as 3.1.0
> > > > <rng.surefire.version>3.0.0-M5</rng.surefire.version> 3.0.0-M7
> > > > <rng.junit5.version>5.7.2</rng.junit5.version> 5.9.0
> > > >
> > > > I propose to update to CP 54 and then drop this version management.
> > >
> > > The more is managed globally the better. However, I never understood
> > > the rationale for an upgrade (to "shared" files) that is known to break
> > > one or more components...
> > >
> >
> > It is impossible to tell if it will break something until the upgrade is
> > performed. So managing the latest version in commons parent using
> > dependabot will not find build errors, only update to what the plugin
> > developer believes is the best version. Perhaps what is really needed
> here
> > is dependabot to build selected derived projects as part of the version
> > update process of a parent POM.
>
> Indeed.
> We'd block releases of components that fail their build, yet we release a
> new CP version known to break things (cf. SBOM issue which you raised),
> on the rationale that components that would break with the new version
> should stay with the old bugs (IOW not benefit from the fixes that
> justified
> the new CP).
>
> > Commons lang overrides a lot of the commons parent properties for the
> > validation plugins. These seem to be replicas of the same version.
> However
> > it does mean dependabot will open PRs and the build is tested before
> > versions are updated in the project. Since dependabot is not used (by
> > consensus) on RNG then this is not an option.
> >
> > I think I will just try to update to CP 54 and then serially drop each
> > managed dependency, resolving any issues along the way. My aim is to
> > simplify the RNG pom and then do the same for others with the same
> > structure (Statistics, Numbers, Math, Geometry). Each of the other
> > components have versions for these plugins that have drifted apart over
> > time. Ideally all the builds should work with the same versions, and
> > ideally the latest ones as maintained in CP.
>
> +1
> Thanks for the work. but this seems a lot of "manual" work that has to
> be repeated each time a plugin is upgraded without checking whether
> it negatively impacts some component that relied on the "current" CP.
>
You have to do the work at some point when you update plugin versions. At
least if they are managed in one place then you should be repeating the
same work (if you update CP in dependent projects at the same time). Having
to piecemeal update versions in all these child projects is what I am
trying to avoid. I would rather be on the same versions for all these
projects.
>
> My question is whether we'd not be better off requiring that any
> upgrade to CP either passes all the dependent (components) builds,
> or raises awareness for each broken build that will result from it.
>
I wonder if we can set up a Jenkins build to use the current CP snapshot
for a project. The mvn:versions command can change the project parent.
However this does not work for RNG:
mvn versions:update-parent -DallowSnapshots=true
This only updates to 54, not 55-SNAPHSOT. I presumed the snapshots for CP
are not deployed anywhere. However they do seem to be in the correct
location with a 55-SNAPSHOT recently deployed there [1]. Running with the
-X flag shows that the apache snapshots repo is being used for remote
artifacts. So something is not working with this command. If it can be made
to work then the Jenkins CI build can be configured using a pre-build step
to execute the shell command.
>
> > Since these are build dependencies then the maintenance benefit of a
> common
> > management of versions should outweigh any upgrade issues between CP
> > versions.
>
> I'm not sure I understand; certainly the advantages *should* outweigh
> the drawbacks, but IMO, the current process (blindly accepting all
> "dependabot" suggestions) does not fulfill the promise.
>
Automated checking of upgrades will be a help here.
Alex
[1]
https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-parent/
Re: [rng] simplify pom version management
Posted by Gilles Sadowski <gi...@gmail.com>.
Hello.
Le ven. 23 sept. 2022 à 15:18, Alex Herbert <al...@gmail.com> a écrit :
>
> On Fri, 23 Sept 2022 at 13:53, Gilles Sadowski <gi...@gmail.com> wrote:
>
> > Hello.
> >
> > Le ven. 23 sept. 2022 à 12:25, Alex Herbert <al...@gmail.com> a
> > écrit :
> > >
> > > The pom for RNG has many plugins that explicitly manage a version. IIUC
> > > this was done to surpass the version in commons parent. However this is
> > no
> > > longer required. The following plugins all have a higher version in CP 54
> > > (version shown at the end of the line):
> > >
> > > <rng.pmd.version>3.14.0</rng.pmd.version> 3.19.0
> > > <rng.pmd.dep.version>6.37.0</rng.pmd.dep.version> 6.49.0
> > > <rng.checkstyle.version>3.1.2</rng.checkstyle.version> 3.2.0
> > > <rng.checkstyle.dep.version>8.45</rng.checkstyle.dep.version> 9.3
> > > <rng.antrun.version>1.8</rng.antrun.version> Managed in
> > > org.apache:apache parent as 3.1.0
> > > <rng.surefire.version>3.0.0-M5</rng.surefire.version> 3.0.0-M7
> > > <rng.junit5.version>5.7.2</rng.junit5.version> 5.9.0
> > >
> > > I propose to update to CP 54 and then drop this version management.
> >
> > The more is managed globally the better. However, I never understood
> > the rationale for an upgrade (to "shared" files) that is known to break
> > one or more components...
> >
>
> It is impossible to tell if it will break something until the upgrade is
> performed. So managing the latest version in commons parent using
> dependabot will not find build errors, only update to what the plugin
> developer believes is the best version. Perhaps what is really needed here
> is dependabot to build selected derived projects as part of the version
> update process of a parent POM.
Indeed.
We'd block releases of components that fail their build, yet we release a
new CP version known to break things (cf. SBOM issue which you raised),
on the rationale that components that would break with the new version
should stay with the old bugs (IOW not benefit from the fixes that justified
the new CP).
> Commons lang overrides a lot of the commons parent properties for the
> validation plugins. These seem to be replicas of the same version. However
> it does mean dependabot will open PRs and the build is tested before
> versions are updated in the project. Since dependabot is not used (by
> consensus) on RNG then this is not an option.
>
> I think I will just try to update to CP 54 and then serially drop each
> managed dependency, resolving any issues along the way. My aim is to
> simplify the RNG pom and then do the same for others with the same
> structure (Statistics, Numbers, Math, Geometry). Each of the other
> components have versions for these plugins that have drifted apart over
> time. Ideally all the builds should work with the same versions, and
> ideally the latest ones as maintained in CP.
+1
Thanks for the work. but this seems a lot of "manual" work that has to
be repeated each time a plugin is upgraded without checking whether
it negatively impacts some component that relied on the "current" CP.
My question is whether we'd not be better off requiring that any
upgrade to CP either passes all the dependent (components) builds,
or raises awareness for each broken build that will result from it.
> Since these are build dependencies then the maintenance benefit of a common
> management of versions should outweigh any upgrade issues between CP
> versions.
I'm not sure I understand; certainly the advantages *should* outweigh
the drawbacks, but IMO, the current process (blindly accepting all
"dependabot" suggestions) does not fulfill the promise.
Best,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [rng] simplify pom version management
Posted by Alex Herbert <al...@gmail.com>.
On Fri, 23 Sept 2022 at 13:53, Gilles Sadowski <gi...@gmail.com> wrote:
> Hello.
>
> Le ven. 23 sept. 2022 à 12:25, Alex Herbert <al...@gmail.com> a
> écrit :
> >
> > The pom for RNG has many plugins that explicitly manage a version. IIUC
> > this was done to surpass the version in commons parent. However this is
> no
> > longer required. The following plugins all have a higher version in CP 54
> > (version shown at the end of the line):
> >
> > <rng.pmd.version>3.14.0</rng.pmd.version> 3.19.0
> > <rng.pmd.dep.version>6.37.0</rng.pmd.dep.version> 6.49.0
> > <rng.checkstyle.version>3.1.2</rng.checkstyle.version> 3.2.0
> > <rng.checkstyle.dep.version>8.45</rng.checkstyle.dep.version> 9.3
> > <rng.antrun.version>1.8</rng.antrun.version> Managed in
> > org.apache:apache parent as 3.1.0
> > <rng.surefire.version>3.0.0-M5</rng.surefire.version> 3.0.0-M7
> > <rng.junit5.version>5.7.2</rng.junit5.version> 5.9.0
> >
> > I propose to update to CP 54 and then drop this version management.
>
> The more is managed globally the better. However, I never understood
> the rationale for an upgrade (to "shared" files) that is known to break
> one or more components...
>
It is impossible to tell if it will break something until the upgrade is
performed. So managing the latest version in commons parent using
dependabot will not find build errors, only update to what the plugin
developer believes is the best version. Perhaps what is really needed here
is dependabot to build selected derived projects as part of the version
update process of a parent POM.
Commons lang overrides a lot of the commons parent properties for the
validation plugins. These seem to be replicas of the same version. However
it does mean dependabot will open PRs and the build is tested before
versions are updated in the project. Since dependabot is not used (by
consensus) on RNG then this is not an option.
I think I will just try to update to CP 54 and then serially drop each
managed dependency, resolving any issues along the way. My aim is to
simplify the RNG pom and then do the same for others with the same
structure (Statistics, Numbers, Math, Geometry). Each of the other
components have versions for these plugins that have drifted apart over
time. Ideally all the builds should work with the same versions, and
ideally the latest ones as maintained in CP.
Since these are build dependencies then the maintenance benefit of a common
management of versions should outweigh any upgrade issues between CP
versions.
Alex
Re: [rng] simplify pom version management
Posted by Gilles Sadowski <gi...@gmail.com>.
Hello.
Le ven. 23 sept. 2022 à 12:25, Alex Herbert <al...@gmail.com> a écrit :
>
> The pom for RNG has many plugins that explicitly manage a version. IIUC
> this was done to surpass the version in commons parent. However this is no
> longer required. The following plugins all have a higher version in CP 54
> (version shown at the end of the line):
>
> <rng.pmd.version>3.14.0</rng.pmd.version> 3.19.0
> <rng.pmd.dep.version>6.37.0</rng.pmd.dep.version> 6.49.0
> <rng.checkstyle.version>3.1.2</rng.checkstyle.version> 3.2.0
> <rng.checkstyle.dep.version>8.45</rng.checkstyle.dep.version> 9.3
> <rng.antrun.version>1.8</rng.antrun.version> Managed in
> org.apache:apache parent as 3.1.0
> <rng.surefire.version>3.0.0-M5</rng.surefire.version> 3.0.0-M7
> <rng.junit5.version>5.7.2</rng.junit5.version> 5.9.0
>
> I propose to update to CP 54 and then drop this version management.
The more is managed globally the better. However, I never understood
the rationale for an upgrade (to "shared" files) that is known to break
one or more components...
If it is bound to happen[1], wouldn'it be possible to decouple those
upgrades from actual fixes (i.e. things that *all* components benefit
from but that don't break anything).
> The drawback is that any upgrade of the project to CP will be hit with many
> changes, some of which may require code changes or rule exceptions. This
> can be mitigated by explicit management of the respective properties in CP
> back to versions that do work. However keeping inline with CP takes
> advantage of the latest versions maintained by dependabot.
We shouldn't have to choose between old bugs and new bugs.
Gilles
[1] Because some people want to go forward (with newer, and perhaps
incompatible, versions of plugins) while others don't have the same pace
(wanting to stay with older versions or not having the time to make the
required checks).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org