Fair call re embedded pom, however it's quite convenient to just browse to it and read.
I've occasionally gone looking for details from poms of artefacts and found a mess and missing stuff, and been annoyed. It probably wasn't gradle's fault, though. Just a sloppy author. If I'm honest I wouldn't even know if I've ever consumed a non-maven artefact, certainly none of mine! :-) No, I am sure, I have, at least one, and it's an ant one with a hard coded POM that doesn't always reflect the contents of the jar. Yuck. Clearly not an issue with automated stuff, though. My only argument now is ease of reading things like project descriptions, contributors, SCM details, etc rather than having to unpack the jar. And if you do, and end up with two pom.xmls laying around, that's not nice. Better to just start always suffixing one with pom.xml.build or some such? I think so, but I haven't thought deeply about it aside from reading this thread. On Wed, Aug 24, 2016 at 6:32 PM, Hervé BOUTEMY <herve.bout...@free.fr> wrote: > 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 > >
