The consumer Pom is for machine to machine, it should be human readable because that is nice, but intent is never human generated.
Switching to this separation allows us to be more radical in the changes to the build Pom. The only reason we deploy packaging Pom's build Pom is for inheritance. If we didn't have to deal with that we wouldn't need to deploy any build poms ever. For using a build Pom as a parent, you implicitly pick up the minimum version of maven that your parent requires, so we then are free to evolve the build Pom format without worrying about forward compatibility, only backwards compatibility on the *build* Pom. The consumer Pom needs partial *forward* compatibility, so that older clients are able to *attempt* to consume... In short there are totally different compatibility constraints on the two, so they should be separate. Mixins would probably also be deployed, once we figure out how they work with build poms. I think we probably need to rethink version ranges. What I'd like is to let the consumer Pom treat version ranges more as guidance rather than hard requirements. It's a pain if you depend transitiveky on Foo:[1.0] but need Foo:[1.0.1,1.1) for the critical security fix... Having to run around applying excludes is not a good plan... Yes the build should initially fail if I depend on [1.0] and [1.0.1,1.1) in my graph, but I should be able to resolve the conflict for all my consumers (unless they pull in the conflict again themselves) On Tuesday 23 August 2016, Fred Cooke <fred.co...@gmail.com> wrote: > 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 > <javascript:;>> > 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 > <javascript:;>> > > > > > > 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 <javascript:;>> wrote: > > > > > > On Tuesday 23 August 2016, Paul Benedict <pbened...@apache.org > <javascript:;>> > > wrote: > > > > > > > On Tue, Aug 23, 2016 at 5:27 PM, Christian Schulte < > > c...@schulte.it <javascript:;> > > > > > > > > > > > > > > <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 > <javascript:;> > > > > For additional commands, e-mail: dev-h...@maven.apache.org > <javascript:;> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org <javascript:;> > > For additional commands, e-mail: dev-h...@maven.apache.org > <javascript:;> > > > > > -- Sent from my phone
