Robert, I am not sure that a consumer-pom will ultimately provide any relief to the problem at hand. Eventually -- even if it is some point very distant in the future -- the consumer-pom will also need to evolve so the same problem will rear its head: how do you read a POM of a future model version? The only way this ultimately gets solved is to have evolving formats on each end... and a policy on what is, if anything, forward-compatible. I called out Subversion as a solution to model. Both of its formats (working copy and server) evolve. The most interesting aspect, however, is the transformation of the server copy into a working copy. If such a model was copied, then deploying a "consumer pom" would disappear as a notion. Instead, clients would download the build POM (like now), but then generate a "consumer pom" locally as their optimized "working copy" for dependency management.
Cheers, Paul On Mon, Aug 29, 2016 at 1:33 PM, Robert Scholte <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
