You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Mark Hobson <ma...@gmail.com> on 2007/06/13 15:30:55 UTC
maven-dependency-tree changes for 1.1
Hi there,
I've been working on dependency tree diagnostic tools and as a
consequence have made substantial changes to maven-dependency-tree. A
brief synopsis of changes are:
- support for node states: included, omitted for conflict, etc.
- node filter API and various implementations for pruning the tree
- node visitor API and various implementations for processing the tree
(esp. serializing visitor for pretty printing the tree, complete with
ascii art :)
There's a few API changes for the better, but I assume that's okay.
So the question is: can this be submitted as a big patch, or must I
painstakingly reverse engineer each change into a set of accumulative
patches.. (hint: big patch)
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-dependency-tree changes for 1.1
Posted by Joakim Erdfelt <jo...@erdfelt.com>.
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 <ma...@gmail.com> wrote:
>> Hi Joakim,
>>
>> On 19/06/07, Joakim Erdfelt <jo...@erdfelt.com> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-dependency-tree changes for 1.1
Posted by Mark Hobson <ma...@gmail.com>.
Hi Joakim,
On 19/06/07, Joakim Erdfelt <jo...@erdfelt.com> wrote:
> 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.)
I think this is the key issue here. I appreciate the problems you
experienced in archiva and why you were forced to do your own thing.
This really needs to be addressed in 2.1 to bring the new dependency
graph code and archiva into line to avoid duplicating efforts.
I have no doubt that the archiva graph is theoretically more accurate
than the dependencies resolved by maven core, but I'm currently
interested in reflecting what is actually happening within maven core
-- bugs and all. I'll continue to focus on these diagnostic tools for
2.0.x since they will be a big time saver for us, but hopefully 2.1
and archiva can combine forces and make this trivial in future.
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-dependency-tree changes for 1.1
Posted by Joakim Erdfelt <jo...@erdfelt.com>.
Mark Hobson wrote:
> On 19/06/07, Carlos Sanchez <ca...@apache.org> wrote:
>> On 6/19/07, Mark Hobson <ma...@gmail.com> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-dependency-tree changes for 1.1
Posted by Brett Porter <br...@apache.org>.
Thanks for the summary mail, Mark. I agree that's the general plan. A
couple of comments...
On 20/06/2007, at 2:48 AM, Mark Hobson wrote:
>
>> 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
right
> - 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
Yes, it sort of is, but it will surely reuse whatever ends up in
maven 2.1.
> - Jason has some code for graph-based resolution in 2.1, which will
> supersede and replace the need for maven-dependency-tree
Whatever goes into 2.1 should be usable in Archiva, dependency tree,
maven, and any other tools, yes. I haven't seen Jason's code or spec,
so I can't comment on whether that's the final solution yet :)
>
> 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.
Makes sense. It's likely we'll still need 2.0.x compatible tools even
after 2.1 is out for some time.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-dependency-tree changes for 1.1
Posted by Mark Hobson <ma...@gmail.com>.
On 19/06/07, Carlos Sanchez <ca...@apache.org> wrote:
> On 6/19/07, Mark Hobson <ma...@gmail.com> 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.
> 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
- Jason has some code for graph-based resolution in 2.1, which will
supersede and replace the need for maven-dependency-tree
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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-dependency-tree changes for 1.1
Posted by Carlos Sanchez <ca...@apache.org>.
On 6/19/07, Mark Hobson <ma...@gmail.com> wrote:
> Hi Joakim,
>
> On 19/06/07, Joakim Erdfelt <jo...@erdfelt.com> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-dependency-tree changes for 1.1
Posted by Mark Hobson <ma...@gmail.com>.
Hi Joakim,
On 19/06/07, Joakim Erdfelt <jo...@erdfelt.com> 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?
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-dependency-tree changes for 1.1
Posted by Joakim Erdfelt <jo...@erdfelt.com>.
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
<https://svn.apache.org/repos/asf/maven/archiva/trunk/archiva-base/archiva-dependency-graph/>
Especially the factory/facade class: DependencyGraphFactory.java
<https://svn.apache.org/repos/asf/maven/archiva/trunk/archiva-base/archiva-dependency-graph/src/main/java/org/apache/maven/archiva/dependency/DependencyGraphFactory.java>
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.
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>
- Joakim
Mark Hobson wrote:
> Hi Kenney,
>
> On 16/06/07, Kenney Westerhof <ke...@apache.org> wrote:
>> Hi,
>>
>> Just a quick question as to what this is for?
>
> maven-dependency-tree is the shared component for computing dependency
> trees from Maven's artifact resolution. The original code came from
> project-info-reports:dependencies, which I extracted for reuse by
> help:dependencies.
>
>> Is it used in 'help:dependencies'?
>
> It was, although I've now moved help:dependencies to dependency:tree
> after a recent discussion.
>
>> Is it/will it be used in maven-core?
>
> It isn't at the moment, but I assume it will be replaced with the
> graph based artifact resolution being discussed for 2.1.
>
>> I see the dependency plugin uses both dependency-tree and
>> dependency-analyzer,
>> what's the relation?
>
> dependency-tree is as described above; dependency-analyzer performs a
> bytecode analysis of compiled classes and determines which of the
> declared and transitive dependencies are actually used.
>
>> If maven core eventually uses this, shouldn't it be moved into
>> maven-components?
>
> Possibly, although I'd have thought the new artifact resolution for
> 2.1 would supersede this.
>
>> The help:dependencies goal shows a tree of dependencies, and it
>> didn't work too
>> well because the algorithm used there didn't match the internal
>> algorithm from
>> maven itself, so the report was quite useless. Is this an attempt to
>> fix that?
>
> I assume you're talking about MDEP-97. See my comment in that issue,
> but yes, the aim for this component is to accurately reflect what is
> happening within Maven.
>
> Hope this helps,
>
> Mark
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-dependency-tree changes for 1.1
Posted by Mark Hobson <ma...@gmail.com>.
Hi Kenney,
On 16/06/07, Kenney Westerhof <ke...@apache.org> wrote:
> Hi,
>
> Just a quick question as to what this is for?
maven-dependency-tree is the shared component for computing dependency
trees from Maven's artifact resolution. The original code came from
project-info-reports:dependencies, which I extracted for reuse by
help:dependencies.
> Is it used in 'help:dependencies'?
It was, although I've now moved help:dependencies to dependency:tree
after a recent discussion.
> Is it/will it be used in maven-core?
It isn't at the moment, but I assume it will be replaced with the
graph based artifact resolution being discussed for 2.1.
> I see the dependency plugin uses both dependency-tree and dependency-analyzer,
> what's the relation?
dependency-tree is as described above; dependency-analyzer performs a
bytecode analysis of compiled classes and determines which of the
declared and transitive dependencies are actually used.
> If maven core eventually uses this, shouldn't it be moved into maven-components?
Possibly, although I'd have thought the new artifact resolution for
2.1 would supersede this.
> The help:dependencies goal shows a tree of dependencies, and it didn't work too
> well because the algorithm used there didn't match the internal algorithm from
> maven itself, so the report was quite useless. Is this an attempt to fix that?
I assume you're talking about MDEP-97. See my comment in that issue,
but yes, the aim for this component is to accurately reflect what is
happening within Maven.
Hope this helps,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-dependency-tree changes for 1.1
Posted by Kenney Westerhof <ke...@apache.org>.
Hi,
Just a quick question as to what this is for?
Is it used in 'help:dependencies'?
Is it/will it be used in maven-core?
I see the dependency plugin uses both dependency-tree and dependency-analyzer,
what's the relation?
If maven core eventually uses this, shouldn't it be moved into maven-components?
The help:dependencies goal shows a tree of dependencies, and it didn't work too
well because the algorithm used there didn't match the internal algorithm from
maven itself, so the report was quite useless. Is this an attempt to fix that?
-- Kenney
Mark Hobson wrote:
> Hi there,
>
> I've been working on dependency tree diagnostic tools and as a
> consequence have made substantial changes to maven-dependency-tree. A
> brief synopsis of changes are:
>
> - support for node states: included, omitted for conflict, etc.
> - node filter API and various implementations for pruning the tree
> - node visitor API and various implementations for processing the tree
> (esp. serializing visitor for pretty printing the tree, complete with
> ascii art :)
>
> There's a few API changes for the better, but I assume that's okay.
>
> So the question is: can this be submitted as a big patch, or must I
> painstakingly reverse engineer each change into a set of accumulative
> patches.. (hint: big patch)
>
> Cheers,
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-dependency-tree changes for 1.1
Posted by Mark Hobson <ma...@gmail.com>.
On 15/06/07, Arnaud HERITIER <ah...@gmail.com> wrote:
> Go for it. If you change some public APIs, try if possible to deprecate them
> (in the case of some users used them)
Sure, but there has been some major refactoring so it may not be possible.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-dependency-tree changes for 1.1
Posted by Arnaud HERITIER <ah...@gmail.com>.
Go for it. If you change some public APIs, try if possible to deprecate them
(in the case of some users used them)
Arnaud
On 15/06/07, Brian E. Fox <br...@reply.infinity.nu> wrote:
>
> No problems here.
>
> -----Original Message-----
> From: Mark Hobson [mailto:markhobson@gmail.com]
> Sent: Friday, June 15, 2007 10:42 AM
> To: Maven Developers List
> Subject: Re: maven-dependency-tree changes for 1.1
>
> On 13/06/07, Mark Hobson <ma...@gmail.com> wrote:
> > Hi there,
> >
> > I've been working on dependency tree diagnostic tools and as a
> > consequence have made substantial changes to maven-dependency-tree. A
>
> > brief synopsis of changes are:
> >
> > - support for node states: included, omitted for conflict, etc.
> > - node filter API and various implementations for pruning the tree
> > - node visitor API and various implementations for processing the tree
>
> > (esp. serializing visitor for pretty printing the tree, complete with
> > ascii art :)
> >
> > There's a few API changes for the better, but I assume that's okay.
> >
> > So the question is: can this be submitted as a big patch, or must I
> > painstakingly reverse engineer each change into a set of accumulative
> > patches.. (hint: big patch)
>
> Any objections to me committing these major changes? 1.0 is available
> for existing users who can migrate to 1.1 as and when.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For additional
> commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
..........................................................
Arnaud HERITIER
..........................................................
OCTO Technology - aheritier@octo.com
www.octo.com | blog.octo.com
..........................................................
ASF - aheritier@apache.org
www.apache.org | maven.apache.org
...........................................................
RE: maven-dependency-tree changes for 1.1
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
No problems here.
-----Original Message-----
From: Mark Hobson [mailto:markhobson@gmail.com]
Sent: Friday, June 15, 2007 10:42 AM
To: Maven Developers List
Subject: Re: maven-dependency-tree changes for 1.1
On 13/06/07, Mark Hobson <ma...@gmail.com> wrote:
> Hi there,
>
> I've been working on dependency tree diagnostic tools and as a
> consequence have made substantial changes to maven-dependency-tree. A
> brief synopsis of changes are:
>
> - support for node states: included, omitted for conflict, etc.
> - node filter API and various implementations for pruning the tree
> - node visitor API and various implementations for processing the tree
> (esp. serializing visitor for pretty printing the tree, complete with
> ascii art :)
>
> There's a few API changes for the better, but I assume that's okay.
>
> So the question is: can this be submitted as a big patch, or must I
> painstakingly reverse engineer each change into a set of accumulative
> patches.. (hint: big patch)
Any objections to me committing these major changes? 1.0 is available
for existing users who can migrate to 1.1 as and when.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For additional
commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: maven-dependency-tree changes for 1.1
Posted by Mark Hobson <ma...@gmail.com>.
On 13/06/07, Mark Hobson <ma...@gmail.com> wrote:
> Hi there,
>
> I've been working on dependency tree diagnostic tools and as a
> consequence have made substantial changes to maven-dependency-tree. A
> brief synopsis of changes are:
>
> - support for node states: included, omitted for conflict, etc.
> - node filter API and various implementations for pruning the tree
> - node visitor API and various implementations for processing the tree
> (esp. serializing visitor for pretty printing the tree, complete with
> ascii art :)
>
> There's a few API changes for the better, but I assume that's okay.
>
> So the question is: can this be submitted as a big patch, or must I
> painstakingly reverse engineer each change into a set of accumulative
> patches.. (hint: big patch)
Any objections to me committing these major changes? 1.0 is available
for existing users who can migrate to 1.1 as and when.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org