Sorry that I reply to consumer POM again, I want to fix my previous email, the parent in consumer POM is not needed from my point of view because I would naturally consider all POMs in Maven Central as totally resolved with their dependencies against scope=runtime and independent of parent and depMgt. The POM with packaging=pom may contain depMgt. This would lead to the situations where BOM files have depMgt but typical POMs with binaries packaging won't have depMgt, this means two XSD schemas. And here we come up with BOM files.
Cheers Tibor On 8/29/16, Robert Scholte-6 [via Maven] <ml-node+s40175n5879290...@n5.nabble.com> wrote: > > > We're missing separations of concerns with the pom. Right now it contains > all the information to build the project and all the dependency > information. Once deployed only the latter is roughly of any interest. As > long as the build-pom is also the deploy-pom, we cannot change a lot since > > this pom is also metadata for other tools, which are now very well capable > > in parsing and processing the pom. > Once we split this, the build-pom will become a Maven specific file and we > > can change it as often as we want (though we should try not to do so), as > long as the deploy-pom remains the same. > > The introduced changes had no effect on the schema, but it did change the > behavior of dependency resolution. > I don't know every fixed bug/changed feature, but based on the responses > there are projects which depend on that bug/feature. Overall I don't have > a very good feeling about these changes, since I can't predict the impact. > > Do we simply push them as bugfixes after more than 5 years? > I have more faith in the consumer-pom/dom, but that also requires talking > with third parties who depend on Central. I'm talking about artifact > repository vendors, IDE vendors and build tool vendors. Together we have > enough experience and should be able to come to a new and better schema. > > cheers, > Robert > > On Mon, 29 Aug 2016 01:32:12 +0200, Paul Benedict <pbened...@apache.org> > wrote: > >> Last week, I communicated my thoughts on why POM model 4.1.0 should not >> be >> introduced in the 3.x series. I said that I believed that forcing two >> separate lines of development would best be beneficial to the overall >> code >> base (which is big!!!). The benefit, so I think, is that 3.x would focus >> >> on >> graceful handling of new metadata; the 4.x line would be free to develop >> new features. The two concerns are important enough that one code base >> shouldn't try to handle both -- especially if there is desire to backport >> graceful handling into even older releases as small point releases. >> >> I am not sure there was any direct responses so I am raising the issue >> again. Does anyone find this appealing? And if not, why not? This is the >> direction I am advocating, but unless there is any traction on it, I >> don't >> want to beat the drum on a dead idea. Thanks everyone. >> >> Cheers, >> Paul >> >> On Sun, Aug 28, 2016 at 4:38 PM, Christian Schulte <c...@schulte.it> wrote: >> >>> Am 08/24/16 um 08:15 schrieb Hervé BOUTEMY: >>> > Le mercredi 24 août 2016 00:45:28 Christian Schulte a écrit : >>> >> Am 08/24/16 um 00:40 schrieb Christian Schulte: >>> >>> Am 08/23/16 um 22:33 schrieb Hervé BOUTEMY: >>> >>>> yes, people providing libraries have this big choice to do: when to >>> >>>> upgrade >>> >>>> minimum JRE version for consumers. >>> >>>> >>> >>>> yes, we can add them another new big decision to take: when to >>> upgrade >>> >>>> minium Maven version to consume the library? >>> >>> >>> >>> When that upgrade lets them solve issues they cannot solve in >>> another >>> way. >>> >> >>> >> No issue with what 4.0.0 provides -> no need to upgrade (do not >>> upgrade) >>> >> Issue you cannot solve with 4.0.0 -> upgrade to x.y.z, if that >>> provides >>> >> the solution. >>> >> >>> >> Regards, >>> > my point is that a library producer creates a Maven requirement for a >>> library >>> > consumer. >>> > >>> > I'll say it crude for us: Maven is the only tool that give library >>> consumers >>> > such issues. People using other build tools don't have this issue when >>> using >>> > central. >>> >>> Can you provide some links to source code of some other build tool which >>> does the whole dependency resolution including import scope processing >>> itself without re-using any Maven component? Have others really >>> implemented the dependency resolution with exactly the same behaviour >>> Maven has? For a build tool running on the Java VM, they would have >>> re-used the 'maven-model-builder' or 'maven-aether-provider', I guess. >>> That means they would just need to upgrade to 'maven-aether-provider' >>> 3.4 and be done with it. >>> >>> Regards, >>> -- >>> Christian >>> >>> >>> --------------------------------------------------------------------- >>> 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 > > > > > > _______________________________________________ > If you reply to this email, your message will be added to the discussion > below: > http://maven.40175.n5.nabble.com/Re-POM-Model-version-4-1-0-in-3-4-0-SNAPSHOTs-tp5878254p5879290.html > To start a new topic under Maven Developers, email > ml-node+s40175n142166...@n5.nabble.com > To unsubscribe from Maven Developers, visit > http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=142166&code=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3wxNDIxNjZ8LTI4OTQ5MjEwMg== -- Cheers Tibor -- View this message in context: http://maven.40175.n5.nabble.com/Re-POM-Model-version-4-1-0-in-3-4-0-SNAPSHOTs-tp5878254p5879313.html Sent from the Maven Developers mailing list archive at Nabble.com.
