I've got a similar thing going for MPIR (maven-project-info-reports)
using the plexus-graph(ing) libs that Jason Van Zyl is working on for
maven 2.1.
BTW, the plexus-graph(ing) project has support for graphviz as a
visualizer currently, and a prefuse based one in the works (based on
carlos's graf
Hi,
really great ideas here and I'm looking forward for these new goals. I just
wrote my own deptree-plugin to generate a tree graph with all project
dependencies. When starting this work I was also looking for the right place to
implement such a feature but didn't found the right place - now I kn
Brian E. Fox wrote on Thursday, January 18, 2007 3:34 PM:
>> This is true, I haven't used dependency:resolve until you
> mentioned it.
> I
>> guess the only difference is that it doesn't show the scope of the
>> dependencies, but this could be easily resolved.
>
> Heh, actually I just added that
Mark Hobson wrote on Thursday, January 18, 2007 2:52 PM:
> On 17/01/07, Jörg Schaible <[EMAIL PROTECTED]> wrote:
>>> Perhaps, but I was thinking about the number of goals once we
>>> introduce tree and list goals for every scope. Would we name them
>>> dependency:compile-tree, dependency:compile-
On 18/01/07, Brian E. Fox <[EMAIL PROTECTED]> wrote:
>This is true, I haven't used dependency:resolve until you mentioned it.
I
>guess the only difference is that it doesn't show the scope of the
>dependencies, but this could be easily resolved.
Heh, actually I just added that feature last night
>This is true, I haven't used dependency:resolve until you mentioned it.
I
>guess the only difference is that it doesn't show the scope of the
>dependencies, but this could be easily resolved.
Heh, actually I just added that feature last night before reading this
thread. (mdep-57).
>Yeah tha
On 18/01/07, Jörg Schaible <[EMAIL PROTECTED]> wrote:
Here's the output of the dep tree of a single artifact:
= %< =
[big snip]
= %< =
We cannot live without this anymore ... it made our release process quite easy
and we can detect unwanted deps very e
On 18/01/07, Brian E. Fox <[EMAIL PROTECTED]> wrote:
I guess I'm a little behind in this thread:
1st, I think dependency:list is effectively the same as the existing
dependency:resolve is it not? The artifacts need to be resolved if you are
going to include transitive stuff.
This is true, I
On 17/01/07, Jörg Schaible <[EMAIL PROTECTED]> wrote:
> Perhaps, but I was thinking about the number of goals once we
> introduce tree and list goals for every scope. Would we name them
> dependency:compile-tree, dependency:compile-list, etc.? That's ten
> extra goals, I'm not sure if it's easi
On 17/01/07, Jörg Schaible <[EMAIL PROTECTED]> wrote:
http://jira.codehaus.org/browse/MNG-2589 (and I detected that I wrote a
stupid description ...)
Thanks for that, I'm sure there's a few related issues regarding
similar functionality I've seen before.
> This goal would still help for
> det
Hi Brian,
Brian E. Fox wrote on Thursday, January 18, 2007 7:53 AM:
> I guess I'm a little behind in this thread:
>
> 1st, I think dependency:list is effectively the same as the
> existing dependency:resolve is it not? The artifacts need to
> be resolved if you are going to include transitive st
Hi Mark,
Mark Hobson wrote on Wednesday, January 17, 2007 9:56 PM:
> On 17/01/07, Jörg Schaible <[EMAIL PROTECTED]> wrote:
[snip]
>> I'll post tomorrow an output from the command line to demonstrate
>> how it looks like. If your reactor build counts ~100 modules, the
>> filter is quite helpful
17, 2007 3:15 PM
To: dev@maven.apache.org
Subject: Re: [m2] Adding further dependency goals
Mark Hobson wrote:
> On 17/01/07, Jörg Schaible <[EMAIL PROTECTED]> wrote:
>> Yes, it's an own internal plugin. We have
>>
>> info:deps-
>>
>> Unfortunately it is developed
Mark Hobson wrote:
> On 17/01/07, Jörg Schaible <[EMAIL PROTECTED]> wrote:
>> Yes, it's an own internal plugin. We have
>>
>> info:deps-
>>
>> Unfortunately it is developed at the office and my employer refused to
>> sign the CCLA. Therefore the code is tainted for contribution :(
>
> No worries,
Mark Hobson wrote:
> On 17/01/07, Jörg Schaible <[EMAIL PROTECTED]> wrote:
>> This sounds really interesting. Although a lot of this could be achieved
>> by inheriting the transitive deps never in compile scope, but as runtime
>> only. That way the deps of a specific component would be explicit (y
On 17/01/07, Jörg Schaible <[EMAIL PROTECTED]> wrote:
This sounds really interesting. Although a lot of this could be achieved by
inheriting the transitive deps never in compile scope, but as runtime only.
That way the deps of a specific component would be explicit (yep, there's a
MNG-xxx issue f
On 17/01/07, Brett Porter <[EMAIL PROTECTED]> wrote:
On 18/01/2007, at 7:35 AM, Mark Hobson wrote:
>> Might go with something other than analyse too, if only to avoid the
>> need to deal with the spelling :)
>
> Yeah I thought that might cause arguments :) Better suggestions on
> a postcard.
H
On 17/01/07, Jörg Schaible <[EMAIL PROTECTED]> wrote:
Yes, it's an own internal plugin. We have
info:deps-
Unfortunately it is developed at the office and my employer refused to sign
the CCLA. Therefore the code is tainted for contribution :(
No worries, we have the dependency-tree shared com
Hi Mark,
Mark Hobson wrote:
> On 17/01/07, Brett Porter <[EMAIL PROTECTED]> wrote:
[snip]
>> Is the analyse goal like the dependency convergence report? Can any
>> of the code be shared?
>
> The analyse goal reports on the dependencies declared in the POM and
> the dependencies actually referenc
Mark Hobson wrote:
> On 17/01/07, Jörg Schaible <[EMAIL PROTECTED]> wrote:
>> What we have is also a plugin displaying a dep tree for one of
>> compile/runtime/test dependencies. This is really helpful.
>
> Do you have this internally? I haven't seen that functionality within
> the help plugin.
On 18/01/2007, at 7:35 AM, Mark Hobson wrote:
Might go with something other than analyse too, if only to avoid the
need to deal with the spelling :)
Yeah I thought that might cause arguments :) Better suggestions on
a postcard.
Hey, I'm with you on the spelling, but I think were outnumbe
On 17/01/07, Brett Porter <[EMAIL PROTECTED]> wrote:
dependency:list sounds good, though I'd be fine with help:effective-
dependencies or something too.
I did think that, although I was concerned that the help plugin would
become a melting pot of unrelated goals. Since these goals are all
depe
dependency:list sounds good, though I'd be fine with help:effective-
dependencies or something too.
Is the analyse goal like the dependency convergence report? Can any
of the code be shared?
Might go with something other than analyse too, if only to avoid the
need to deal with the spelling
On 17/01/07, Jörg Schaible <[EMAIL PROTECTED]> wrote:
What we have is also a plugin displaying a dep tree for one of
compile/runtime/test dependencies. This is really helpful.
Do you have this internally? I haven't seen that functionality within
the help plugin.
So if you're going to move he
Mark Hobson wrote:
> Hi there,
>
> I'd like to add some further goals to help with managing dependencies:
>
> 1) List all resolve dependencies for the current project
> 2) Compare all resolved dependencies between the current project and a
> previous release
>
> The question is where should the
25 matches
Mail list logo
