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
