I still find it a bit off that the original real POM won't always be directly available anymore.
Other tools create fake POMs because they *have* to - there's no other option. I feel like some fidelity would be lost. Diffability would be lost (from a scenario where there's nothing to diff). Unrelated, really, but kind of related: top level deployable artefact deployments, debs, wars, exes, etc. When ranges are in use it'd be nice to deploy a sort of strict effective pom with fully hard [] versions for all things. This can be achieved in other ways, though. I guess that is to say, don't forget about non-central deployments. I suppose if there's a way to always deploy pom.xml.build through some plugin or configuration or some such, then that's fine with me. On Wed, Aug 24, 2016 at 6:49 PM, Hervé BOUTEMY <herve.bout...@free.fr> wrote: > Le mercredi 24 août 2016 18:41:59 Fred Cooke a écrit : > > 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. > our consumer pom will be generated from build pom: we can automate copy of > any > information we want, and for sure, I expect to put at least description, > scm > details, issueManagement, license (of course). > In your list, there is only constributors that I was not counting on it: > but > it's a detailed decision we'll have to make > > for sure, Maven consumer poms, since generated from Maven build pom, can > have > much more details (and be sure they are accurrate) than build tools that > don't > generate it from data that exists in their original build format > > Regards, > > Hervé > > > > > > > > > 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 > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
