Hi all, Status update: By now Custom War Packager has been released in 1.0, and there are also many updates in Evergreen. IMHO it is a good time to get this story over the fence.
Last week I have submitted a patch to the design <https://github.com/jenkinsci/jep/pull/163>, which does the following: - Full format specification has been added to the JEP - New "version" field has been added to support changing the format in the future. It addresses my comment about extensibility in the future - "components" section has been documented, so it is no longer an empty blob - "type" has been added to "components". It addresses my comment about component type packaging - Dependency resolution rules have been documented explicitly - Reference implementation links are updated - Tooling has been explicitly excluded out of the scope (though Custom War Packager offers a lib) With the current changes, I believe that the JEP can be reviewed by the BDFL Delegate. The only outstanding comment is "YAGNI" from Jesse, but I believe that the reference implementations justify it a bit. I do not expect this Bill of Materials to be widely used, but accepting this JEP at least allows to stabilize and specify the current implementations which we already use in some cases. Best regards, Oleg On Saturday, June 16, 2018 at 2:00:22 AM UTC+2, Liam Newman wrote: > > I've approved JEP-309 as Draft. > https://github.com/jenkinsci/jep/tree/master/jep/309 > > > On Friday, May 11, 2018 at 9:20:36 AM UTC-7, Jesse Glick wrote: >> >> On Fri, May 11, 2018 at 6:43 AM, Oleg Nenashev <[email protected]> >> wrote: >> > We really need an inter-exchange format. As Jesse said somewhere, Maven >> > POM/BOM is not a silver-bullet in this area since it does not allow >> passing >> > extra metadata easily >> >> Indeed the v4 POM format does not permit custom metadata inline in >> `<dependency>`s. On the other hand you can always use a POM to define >> component versions and then mix it with other metadata for particular >> purposes. This is certainly friendlier to existing developer workflows >> than attempting to generate or update POMs from another source. We >> anyway need a Maven BOM (i.e., `pom.xml` with >> `<dependencyManagement>`) just to slim down per-plugin POMs and make >> it easy to develop against the “latest” versions of other stuff. >> >> I think the trouble here is that we have a bunch of different tools >> and workflows with different needs, and it is not that clear to me how >> much overlap there really is, or what problems we are trying to solve >> with a unified format. For example, for Evergreen deployment, we just >> need a list of components with versions (all assumed to come from >> `master`), which could easily fit in a POM if you also differentiate >> “environments” like AWS somewhere. For `buildPlugin` integration >> testing, it makes the most sense to pick up versions of other >> components from the Maven `test` scope, which is already used for >> functional tests. (You also need an optional branch override for >> `incrementals:update`, but this can easily be handled in mojo >> configuration.) >> >> > Custom Packager generates a specification of bundled components which >> is >> > then used by runPCT/runATH steps to define defaults for running steps >> >> Details of these test suites are configured via the `essentials.yaml`. >> I think you do not also need a BOM, if you are picking up `test` >> scope. >> >> > WAR bundles ship BOMs internally so that tools like PCT can easily >> determine >> > what's inside without parsing files >> >> The code to look up component versions in PCT already exists. Are >> there some subtleties not captured by the traditional logic? >> >> > BOM can be used as a source for repackaging third-party WARs. >> >> This is Custom WAR Packager IIUC? >> >> > Jenkins Essentials could be shipping BOM >> >> Well, Evergreen will be “shipping” a flat list of core & plugin URLs, >> if I gather Tyler’s intention correctly—the minimum information needed >> by the client. It is an open question what build process generates >> this list and from what source. >> > -- 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/fe094a4d-053a-4b91-a37e-bdd94c17c33e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
