Hi Jesse, You are a bit late to the party, JEP-309 has been already accepted. It would not be possible to fully address your feedback without introducing a 2.0 BOM version. Also note that JEP-309 defines a BOM definition format. It does NOT define strict guidelines how BOM packager implementations should package the *specification* section. It may address some of your concerns, see the responses below.
I would suggest dropping `status` and having all plugins which are to be > included explicitly listed in the main and environment sections > I hope that reasoning explains why it was decided to support transitive dependencies. In your BOM packager implementation you have an option to refuse unexplicit dependencies as it is defined in the Dependency Management section. Removing "status" would require a breaking change in the format. Then for each plugin, add a mandatory boolean `transitive` attribute. > Not a compatible change > Also it is unclear how well `environments` will work when we have a > bunch. Currently `aws-global-configuration` & `artifact-manager-s3` & > `ec2` are specified in the main section as well as `aws-ec2-cloud`, > which seems like a mistake—presumably they should be listed only in > `aws-ec2-cloud`. But then when there are common library plugins used > in several environments but _not_ in all, we will have duplicated > `version`s (a likely source of developer error) unless some equivalent > to Maven’s `<dependencyManagement>` is introduced. > Although it is not mentioned explicitly, JEP-309 does not prohibit combining environments if needed. IMO it is up to the BOM packager implementation Best regards, Oleg On Wednesday, August 22, 2018 at 12:36:57 PM UTC+2, Jesse Glick wrote: > > On Tue, Aug 14, 2018 at 11:38 AM R. Tyler Croy <[email protected] > <javascript:>> wrote: > > I've gone ahead and > > implemented the `status` section for the Bill of Materials being used > in the > > jenkins-infra/evergreen repository. > > From what I can tell, this is not working so well. There is a lot of > duplication between `spec` and `status`; lots of transitive > dependencies are much too old; there are unwanted transitive > dependencies and no clear way to track them. > > I would suggest dropping `status` and having all plugins which are to > be included explicitly listed in the main and environment sections > (with a mandatory alphabetical order). Produce a build-time error > (`make -C services check` perhaps) if a plugin expresses a dependency > which is too old, or nonoptional and missing—the same checks the > Jenkins plugin manager would do at runtime. The equivalent of `mvn > incrementals:update` should be easy to write which would go through > the list and offer updates of every entry to the latest version > available in Artifactory, including in the case of incremental > versions the latest deployed `master` commit. > > Then for each plugin, add a mandatory boolean `transitive` attribute. > If a plugin is marked `transitive: true`, a build-time error would > result if there is no dependency chain to this plugin from a plugin > which is marked `transitive: false`. That would make it clear in the > text that library plugins (`docker-commons`, `git-client`, > `bouncycastle-api`, …) are “along for the ride” as opposed to > independent features. More importantly, when we see unwanted plugins > in the list (`conditional-buildstep`, `icon-shim`, `matrix-project`, > `maven-plugin`, …) with `transitive: true`, we can simply try deleting > them and seeing if everything is still OK, or if not which bogus > dependency(ies) must be broken. And if you update a `transitive: > false` plugin to a version which no longer requires some library > plugin, and that was the last usage of the library (“refcount goes to > zero”), you will immediately get a build error if you forgot to remove > the now-obsolete library. > > Also it is unclear how well `environments` will work when we have a > bunch. Currently `aws-global-configuration` & `artifact-manager-s3` & > `ec2` are specified in the main section as well as `aws-ec2-cloud`, > which seems like a mistake—presumably they should be listed only in > `aws-ec2-cloud`. But then when there are common library plugins used > in several environments but _not_ in all, we will have duplicated > `version`s (a likely source of developer error) unless some equivalent > to Maven’s `<dependencyManagement>` is introduced. > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/401db247-479c-4d65-9729-e9a7cd0edddc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
