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/CANfRfr1Nq%3DSzsWQJ0WzVBZbBhh4HGX1Cr0XRiD-%3DPxPX_6gN_A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
