Le mercredi 24 août 2016 13:50:33 Robert Scholte a écrit : > I realized last ApacheCon that I wasn't clear about my definiton of the > consumer-pom. > I don't think it should be a flattened pom with only the dependency > information. Instead it shouldn't be a pom (matching the pom.xsd) at all. IMHO, that's perhaps a future version of consumer pom: a first iteration of consumer pom as I understood it would be IMHO an important step in the right direction = permit Maven evolution on build features, without breaking anything for artifact consumers
> Maybe it should be called something like consumer-dom (dependency object > model, though dom is confusing...). when the model diverge, yes, we'll probably find a new name: to me, that's a long future > It should be the most fast and efficient way to resolve the dependency > tree. That means it should do less roundtrips like Maven must do do right > now: for every dependency download the pom, for all transitive > dependencies download all poms, etc. flatten already helps: not the faster, but faster. > Why can't it be a pom? I'd like to add the (file)extension too. Otherwise > Maven needs to initialize the matching ArtifactHandler and translate the > type to the proper extension. The pom doesn't have room for this. what is the performance loss from this requirement? I really don't catch the issue: network roundtrips have a strong impact, using an object in memory injected by IoC doesn't have any impact to me > Consumer-dom is an extraction and enriched version of the pom and will be > a separate upload to the repository. Build tools who can understand this > file can use it or fall back by downloading all poms. > > thanks, > Robert > > On Wed, 24 Aug 2016 09:22:03 +0200, Stephen Connolly > > <[email protected]> wrote: > > 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 <[email protected]> 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 <[email protected] > >> <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 > >> > >> <[email protected] > >> <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 < > >> > > > > > >> > > > > [email protected] <javascript:;>> wrote: > >> > > > > > On Tuesday 23 August 2016, Paul Benedict <[email protected] > >> > >> <javascript:;>> > >> > >> > wrote: > >> > > > > > > On Tue, Aug 23, 2016 at 5:27 PM, Christian Schulte < > >> > > >> > [email protected] <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: [email protected] > >> > >> <javascript:;> > >> > >> > > > For additional commands, e-mail: [email protected] > >> > >> <javascript:;> > >> > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: [email protected] > >> > >> <javascript:;> > >> > >> > For additional commands, e-mail: [email protected] > >> > >> <javascript:;> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
