That should have separation between builder Pom and consumer Pom. For packaging=pom we deploy the builder Pom using classifier=build *for all other packaging a we do not deploy the builder Pom*.
I don't like the sound of this. The deployed artefacts should include the exact POM in use to build the project, as a reference, even if under a different name. Yes, they should be in SCM, however down stream it's useful to see these even when the SCM is offline or gone or private or whatever. Or did I misunderstand? If so, please clarify? On Wed, Aug 24, 2016 at 1:52 PM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > On Tuesday 23 August 2016, Paul Benedict <pbened...@apache.org> wrote: > > > On Tue, Aug 23, 2016 at 5:27 PM, Christian Schulte <c...@schulte.it > > <javascript:;>> wrote: > > > > > Am 08/24/16 um 00:08 schrieb Paul Benedict: > > > > POM and a future major version POM? I am hinting at a strategy for > > > forward > > > > compatibility. > > > > > > Is forward compatibility really needed/required? > > > > > > > I honestly don't know, which is why I am asking. An answer of "no > > compatibility" is possible, too. > > > > I can completely see the argument that says POMs must be > > all-parseable-or-nothing -- for the sake of reproducibility. I actually > > prefer this answer. I think it is sensible to fail a build when > > encountering a POM version too advanced. If your client only supports up > to > > model 4.0.0, then all artifacts must be specified by 4.0.0 models, too. > > > > On the other hand, I wanted to give the benefit of the doubt to the > > opposite argument. At least one person spoke up and said it's > unacceptable > > to fail a build on configuration you don't understand. Well, that's an > > interesting argument, too. That person doesn't want to tank the build for > > the 1% of configuration that can't be understood.... but I fail to see an > > escape hatch here. If a client can't understand what's being specified, > > then what else can be done but fail? > > > Strip the dependencies a and let the user fix up manually (ideally by > logging a warning that you are consuming a dependency using a newer > modelVersion) > > Everyone forgets that the 4.0.0 ship has sailed already, so we have to > deploy best-effort 4.0.0 poms > > Now I say that 3.4 should not have a new modelVersion but what it could do > is be more forgiving of newer modelVersions or try and download and use an > XSLT to convert newer modelVersions to 4.0.0 (while logging a warning) with > option flags to allow failing the build if XSLT had to be applied > > So let's bump the modelVersion in Maven 5.0.0 (there is no Maven 4.x let's > align on the modelVersion) > > That should have separation between builder Pom and consumer Pom. For > packaging=pom we deploy the builder Pom using classifier=build for all > other packaging a we do not deploy the builder Pom. > > We deploy a *best effort* conversion of the consumer Pom to modelVersion > 4.0.0 without a classifier and the consumer Pom gets deployed as classifier > consumer. > > The consumer Pom format allows for XSLT to transform to a parsable syntax, > if transform is required we log a warning (or fail the build if the builder > Pom indicates strict modelVersion adherence) > > So yeah maven 5.x will be able to parse dependencies with modelVersion 6.x > while logging warnings that the user may not have the correct dependency > tree. That is IMHO acceptable forward compatibility > > HTH > > -Stephen > > Ps I'm really hoping someone has a less crappy solution that this... But I > believe this is actually *a* solution... And prior to this I have not seen > any solution > > > > Cheers, > > Paul > > > > > -- > Sent from my phone >
