Mark Hobson wrote:
On 19/06/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
On 6/19/07, Mark Hobson <[EMAIL PROTECTED]> wrote:
> 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
I agree, this is what I was trying to say.
I chose to ensure consistency with maven itself.
It is not nearly as confusing as it is now.
other than that let's just choose one of the libraries and deprecate
the other one to avoid splitting the work
archiva-dependency-graph appears to be quite tied in to archiva
itself, so I'm not sure how easy it'd be to move away from that. The
situation so far appears to be:
- maven-dependency-tree uses the 2.0.x core APIs to build the same
tree as Maven actually uses
- archiva-dependency-graph is a good proof-of-concept of how
graph-based resolution could be implemented in 2.1, although is
currently quite tied to archiva itself
There are few decisions here in archiva.
1) The need to resolve project models differently.
Archiva doesn't have a local repository, it has many managed repos.
Archiva doesn't communicate with a remote repository unless directed
to do so because of a client request.
Archiva set up a ProjectModelResolver interface with a
ProjectModelResolverStack to allow for control over the project
resolution process. Currently, archiva does resolution via the
ProjectModelResolverStack, which specifies the order ... from DB/jpox,
then managed repos, then a dummy model. This resolver stack also has a
listener setup that allows for just in time persistence of newly
discovered models. Very nice.
2) The choice of persistence engine (jpox) and insistence on using
modello by other devs meant I couldn't use the maven/components model.
3) The model read / write via xpp3 was a PITA.
Archiva uses a proper SAX/DOM (and can even get around the mess
that trygvis's name causes. ;-)
Archiva also uses xpath to load 3.0.0 and 4.0.0 into the same
persisted model, making serving them out to m1 or m2 clients trivial.
I want to see maven 2.1 fixed in regards to project model resolution.
The current mess in maven/components is completely unusable within
archiva. If that occurs, then the rest of the dependency graph
resolution bits will fall into line easily. (It did for archiva.)
- Jason has some code for graph-based resolution in 2.1, which will
supersede and replace the need for maven-dependency-tree
I based the archiva-dependency-graph entirely off of discussions with
jason about how to do the dependency resolution bits. I intentionally
decoupled as much as I could to make the porting out of archiva easier.
I believe maven-dependency-tree is still relevant for 2.0.x and I will
continue to work on it since that's the version I'm targeting. Once
the spec and implementation is done for 2.1, it should be very easy to
move these diagnostic tools over to use that instead.
- Joakim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
