maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Scholte" <>
Subject Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs
Date Mon, 29 Aug 2016 21:07:02 GMT
I think that all the fields of a dependency are quite complete. Based on  
the issues I see with moving forward with Aether is that the (complex)  
dependency resolution is done inside Maven. The idea is to not calculate  
this anymore, but add all transitive dependencies to the consumer pom.
This would hopefully remove the discussion what all the dependencies are,  
since they're already summed up.
Stephen already started with a list of items which should be added the  
By the time we have the first complete definitions, we should compare it  
with the experiences at Subversion.

But that's a completely different discussion. We're actually still  
discussing: model 4.1.0 in Maven 3.4.0 or not?


On Mon, 29 Aug 2016 22:15:16 +0200, Paul Benedict <>  

> 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 <>
> 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 <>
>> 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 <>  
>>> 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
>>>> 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:
>>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message