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
consumer-pom.
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?
thanks,
Robert
On Mon, 29 Aug 2016 22:15:16 +0200, Paul Benedict <pbened...@apache.org>
wrote:
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 <rfscho...@apache.org>
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
