On 29 August 2016 at 23:27, Christian Schulte <c...@schulte.it
<javascript:_e(%7B%7D,'cvml','c...@schulte.it');>> wrote:
Am 08/30/16 um 00:16 schrieb Paul Benedict:
> I see a deployed faulty "consumer pom" to be more more harmful than
> generating it locally on demand. At least with the local one I can
upgrade
> my client to fix a dependency calculation. There will be no such
relief
in
> the case of your proposal.
It's not my proposal but I agree to what is proposed. This whole
discussion started because users have requested to revert commits due
to
compatibility issues. They want to keep such "faulty" behaviour. If
they
want to fix it, they can deploy a new version using a more recent Maven
version. The older Maven version will then also see this new behaviour.
If the consumer pom contains the complete resolved dependency tree, the
code interpreting that data is not much more than downloading some
files
from some repository. Yes. Repository information needs to be part of
that consumer pom as well. So the resolved dependency tree including
repository information from where to get the resolved artifacts. And we
also need to find a way to handle version ranges.
So the way I see this, different types of artifacts have different tree
requirements.
I may have one type of artifact (i.e. jar) where it really is not
supported to have multiple versions of the same artifact on the same
classpath at the same time.
We currently view artifact dependency resolution as building a linear
path
from the dependency tree based on the assumption of single version of
any
dependency.
In the JavaScript world... and even in the OSGi world... that assumption
is simply not true.
This implies - to me - that the consumer pom should contain the tree
that
was used at build time... *as a tree*
By all means, each node could include the version range as well as the
resolved version, e.g.
<dependency groupId="..." artifactId="..." architecture="..."
classifier="..." type="..." version="[1.0,2.0)" resolvedVersion="1.5.0">
<dependency groupId="..." artifactId="..." architecture="..."
classifier="..." type="..." version="..." resolvedVersion="...">
...
</dependency>
...
<dependency groupId="..." artifactId="..." architecture="..."
classifier="..." type="..." version="..." resolvedVersion="..."/>
</dependency>
The child elements are the dependencies of the resolved version.
Now the consumer of the consumer pom has all the dependency information
used at build time as well as the information to perform
substitutions...
This means that if I - as a consumer - am already pulling in a different
resolvedVersion (but valid within the advertised range) of a child
dependency and I am using the tree to produce a single-version
classpath, I
can prune the tree and know I have removed the unrequired dependencies.
If I - as a consumer - need to produce a multi-version classpath -
because
I am producing for an OSGi container - I can build the correct tree
rather
than being forced to look at a flattened classpath that may not be
aligned
with the requirements of the dependency system I am using
If I - as a consumer - decide that I want to push the ranges to newer,
we
still have the range information to allow for range validation... but by
default I will be using the versions that were resolved at build time
and
consequently tested with by the builder.
HTH
-Stephen
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
<javascript:_e(%7B%7D,'cvml','dev-unsubscr...@maven.apache.org');>
For additional commands, e-mail: dev-h...@maven.apache.org
<javascript:_e(%7B%7D,'cvml','dev-h...@maven.apache.org');>
