The list of resolved dependencies is equivalent to what maven has.
And speaking of different resolutions, even now, maven 2.0.5 and 2.0.6
resolve differently. In my tests 2.0.6 does a worse job choosing the
'latest' version of a dep when in conflict, maven 2.0.5 picks correctly.
When I say "more accurate" it doesn't mean that the it has a different
list of deps, just more accurate as to where they come from.
A good example of this is direct dependencies that arrive in via Parent pom.
Under maven 2.0.5, they show as direct deps, under maven 2.0.6 it shows
up as transitive (seems to only occure if that same dep shows up as a
transitive dep later on)
The implementation on archiva side shows it as direct (which it should
be). Hence more accurate. Not different.
I've also seen maven choose different deps during a conflict based on
the order of the deps in the dependency list. A common one i keep
hitting is the xml-apis version, maven 2.0.6 chooses (incorrectly) the
1.0.x series, when in the same tree 1.3.x series is available (and
usually closer to the project than the 1.0.x series).
If you perform the dependency-tree lookup using a plugin or report, you
can get different results than if you run it standalone (not within the
maven execution environment). I suspect that this is due to the
existence of the maven core components within the $M2_HOME/lib that
overrides whatever version you specify in the plugin.
In short. The archiva one is consistent to compile / test scoped deps
that maven client uses for the same project. I even created an
archivadev:create-dependency-tests plugin to take the
shared-dependency-tree results of the project, and generate testcases
that ensure an identical resolution of artifacts.
- Joakim Erdfelt
Carlos Sanchez wrote:
On 6/19/07, Mark Hobson <[EMAIL PROTECTED]> wrote:
Hi Joakim,
On 19/06/07, Joakim Erdfelt <[EMAIL PROTECTED]> wrote:
> Note, Archiva couldn't use the DependencyTree component, as it made
> assumptions about repository access, availability, search order, and
> layout that simply were not true. (actually, this is a problem
mostly in
> maven/components, but it still affected Archiva).
>
> So, we wrote our own dependency graph / tree routines. It's more
> flexible, more reliable, faster, uses less memory, and more accurate
> than the ones in maven components (and the shared dependency tree
> component too). I even utilized a local version of select classes
from
> plexus-graph (that Jason wants to eventually use for dependency
management).
>
> Check it out: archiva-dependency-graph
[snip]
Ah thanks, I wasn't aware of that - I had assumed archiva used
dependency-tree, although I haven't got around to looking at archiva
yet. That certainly looks like the kind of code I was heading towards
- I'll have a proper look and get back to you. I'm just wondering how
it could be more accurate than the resolution process that Maven core
uses itself?
what would be the point of having a different resolution than the one
maven uses? If I see a dependency graph different of what maven uses
it would be really confusing
other than that let's just choose one of the libraries and deprecate
the other one to avoid splitting the work
> I welcome you to look at it as a potential PoC for dependency handling
> in maven 2.1.
>
> It needs better non-javadoc documentation, but that'll come.
Cool. Jason was talking about committing some artifact resolution
code this weekend, so hopefully we can start to converge these efforts
towards 2.1.
> BTW. I wrote a VersionComparator that uses logic version sorting
too in
> Archiva. I didn't realize it was a tough thing to do, until I read
> Kenney's email about versioning
> <http://www.nabble.com/versioning-tf2842865s177.html#a7938087>.
>
> Check it out: VersionComparator.java
>
<https://svn.apache.org/repos/asf/maven/archiva/trunk/archiva-base/archiva-common/src/main/java/org/apache/maven/archiva/common/utils/VersionComparator.java>
Nice, I'd definitely like to see Kenney's versioning become the default.
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
