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
