Le mercredi 24 août 2016 14:04:12 Fred Cooke a écrit : > 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? when you consume an artifact not build with Maven, do you get the full build script? no I know that, as Maven users, we got used to have the build pom published in central: this is now an issue, but we like that
notice: the build pom can be injected in the artifact, in META-INF/maven, like it is currently done but I don't see the point in requiring it to be pbulished separately in central: no other build tool does that, and they don't have any issue with that (and eventually it's a feature: don't publish internal details you don't really want people to see) Regards, Hervé > > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
