On Fri, 23 Sept 2022 at 15:19, Gilles Sadowski <gillese...@gmail.com> wrote:
> Hello. > > Le ven. 23 sept. 2022 à 15:18, Alex Herbert <alex.d.herb...@gmail.com> a > écrit : > > > > On Fri, 23 Sept 2022 at 13:53, Gilles Sadowski <gillese...@gmail.com> > wrote: > > > > > Hello. > > > > > > Le ven. 23 sept. 2022 à 12:25, Alex Herbert <alex.d.herb...@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/
