RE: Why would 'mvn dependencies:tree' fail while 'mvn compile' works?

[Jamie Whitehouse]

I was about to reply with the same thing.  The Maven way is to install
artifacts.  Many plugins, rightly or not, depend on artifacts being
located in the local repository.

-Original Message-
From: Wayne Fay [mailto:wayne...@gmail.com] 
Sent: Tuesday, November 24, 2009 4:53 PM
To: Maven Users List
Subject: Re: Why would 'mvn dependencies:tree' fail while 'mvn compile'
works?

> My adversion to running 'mvn clean install' is just that I'd prefer 
> not to have to build and install something just to be able to examine
its dependencies.

This is merely a preference, right?

> under various 3rd party dependency scenarios. It seems backwards to me

> to have to first build and install something only to be able to 
> examine some abstract properties of it, so that's my main blocker.

This is merely a mental blocker, right?

> If there is some more maven-ey way to go about this stuff, I'm all for
it.

Run mvn clean install... that is the "maven-ey way to go about this
stuff." As Brian already said "running tree on a not-yet compiled or
installed project is an edge case."

Wayne

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org



---
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain 
confidential and proprietary information of Alcatel-Lucent and/or its 
affiliated entities. Access by the intended recipient only is authorized. Any 
liability arising from any party acting, or refraining from acting, on any 
information contained in this e-mail is hereby excluded. If you are not the 
intended recipient, please notify the sender immediately, destroy the original 
transmission and its attachments and do not disclose the contents to any other 
person, use it for any purpose, or store or copy the information in any medium. 
Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or 
its affiliated entities.


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Why would 'mvn dependencies:tree' fail while 'mvn compile' works?

[Wayne Fay]

> My adversion to running 'mvn clean install' is just that I'd prefer not to 
> have
> to build and install something just to be able to examine its dependencies.

This is merely a preference, right?

> under various 3rd party dependency scenarios. It seems backwards to me to have
> to first build and install something only to be able to examine some abstract
> properties of it, so that's my main blocker.

This is merely a mental blocker, right?

> If there is some more maven-ey way to go about this stuff, I'm all for it.

Run mvn clean install... that is the "maven-ey way to go about this
stuff." As Brian already said "running tree on a not-yet compiled or
installed project is an edge case."

Wayne

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Why would 'mvn dependencies:tree' fail while 'mvn compile' works?

[Jonathan Gold]

Jamie --

My adversion to running 'mvn clean install' is just that I'd prefer not to have
to build and install something just to be able to examine its dependencies.
Indeed, this problem came up originally as I was configuring a new project and
trying to do sort of a dry run to understand where things would be coming from
under various 3rd party dependency scenarios. It seems backwards to me to have
to first build and install something only to be able to examine some abstract
properties of it, so that's my main blocker.

I'm finding this same pattern (need to activate the reactor) with the eclipse
plugin, which also seems odd to me, since I effectively have to install a
project before I can add it to an eclipse workspace where, presumably, I would
actually be doing the work to get it to a point where there is something to
install.

If there is some more maven-ey way to go about this stuff, I'm all for it.

jon

On Fri, Nov 20, 2009 at 01:42:27PM -0800, Jamie Whitehouse wrote:
> Yes, thanks for clarifying Brian.
> 
> Jon, I'm still wondering why you're adverse to running mvn clean install? 
> 
> -Original Message-
> From: Jonathan Gold [mailto:jgold...@gmail.com] 
> Sent: Friday, November 20, 2009 4:26 PM
> To: users@maven.apache.org
> Subject: Re: Why would 'mvn dependencies:tree' fail while 'mvn compile' works?
> 
> Brian --
> 
> Thanks for this. I did run the combo 'mvn compile dependency:tree' as you 
> mention below, and it works. What I'm taking away from this is that 
> dependency:tree will work if it's part of the *same* mvn invocation as 
> something like compile, which forces maven to do the resolution of the local 
> workspace.
> Doing 'mvn compile' and then 'mvn dependency:tree' thus does not work.
> 
> As a new user, this was (and still is) a bit bizarre, but I'm happy to know 
> how to get it to work. 
> 
> Thanks!
> 
> jon
> 
> On Fri, Nov 20, 2009 at 03:54:11PM -0500, Brian Fox wrote:
> > This isn't exactly true. First, lets take a look at the stack trace:
> > 
> > --
> > 1 required artifact is missing.
> > 
> > for artifact:
> >   com.example:mod_b:jar:1.0
> > 
> > from the specified remote repositories:
> >   mynexus (http://192.168.101.21:8081/nexus/content/groups/public)
> > 
> > 
> > at 
> > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTra
> > nsitively(DefaultArtifactResolver.java:360)
> > at 
> > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTra
> > nsitively(DefaultArtifactResolver.java:304)
> > at 
> > org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDepende
> > ncies(DefaultPluginManager.java:1499)
> > at 
> > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
> > nManager.java:442)
> > at 
> > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
> > ultLifecycleExecutor.java:694)
> > ... 17 more
> > 
> > 
> > Notice this is all core code. It's trying to resolve the dependencies 
> > prior to invoking the plugin. As I mentioned earlier in the thread, 
> > the plugin sets @requiresDependencyResolution test which tells Maven 
> > to resolve the test scope (which means everything) before invoking the 
> > plugin.
> > 
> > If you only run "mvn dependency:tree" there are no references to the 
> > other projects in the reactor for Maven to find and use. Try running 
> > "mvn compile dependency:tree: and you'll see that it does in fact 
> > work. This is just a side effect of how maven 2.x does the resolution.
> > 
> > Could we rewrite the dependency tree goal to completely work around 
> > this? Probably, but it would mean duplicating tons of core logic to 
> > make the resolution work in all cases and running tree on a not-yet 
> > compiled or installed project is an edge case imo.
> > 
> > 
> > 2009/11/19 Jamie Whitehouse :
> > > Many of the dependency plugin goals are reactor aware, but 
> > > dependency:tree isn't.  I'm not too sure why, but you could search the 
> > > issue tracker and if there's no issue for this file one.
> > >
> > > -Original Message-
> > > From: Jonathan Gold [mailto:jgold...@gmail.com]
> > > Sent: Thursday, November 19, 2009 3:00 PM
> > > To: users@maven.apache.org
> > > Subject: Re: Why would 'mvn dependencies:tree' fail while 'mvn compile' 
> > > works?
> > >
>

RE: Why would 'mvn dependencies:tree' fail while 'mvn compile' works?

[Jamie Whitehouse]

Yes, thanks for clarifying Brian.

Jon, I'm still wondering why you're adverse to running mvn clean install? 

-Original Message-
From: Jonathan Gold [mailto:jgold...@gmail.com] 
Sent: Friday, November 20, 2009 4:26 PM
To: users@maven.apache.org
Subject: Re: Why would 'mvn dependencies:tree' fail while 'mvn compile' works?

Brian --

Thanks for this. I did run the combo 'mvn compile dependency:tree' as you 
mention below, and it works. What I'm taking away from this is that 
dependency:tree will work if it's part of the *same* mvn invocation as 
something like compile, which forces maven to do the resolution of the local 
workspace.
Doing 'mvn compile' and then 'mvn dependency:tree' thus does not work.

As a new user, this was (and still is) a bit bizarre, but I'm happy to know how 
to get it to work. 

Thanks!

jon

On Fri, Nov 20, 2009 at 03:54:11PM -0500, Brian Fox wrote:
> This isn't exactly true. First, lets take a look at the stack trace:
> 
> --
> 1 required artifact is missing.
> 
> for artifact:
>   com.example:mod_b:jar:1.0
> 
> from the specified remote repositories:
>   mynexus (http://192.168.101.21:8081/nexus/content/groups/public)
> 
> 
> at 
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTra
> nsitively(DefaultArtifactResolver.java:360)
> at 
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTra
> nsitively(DefaultArtifactResolver.java:304)
> at 
> org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDepende
> ncies(DefaultPluginManager.java:1499)
> at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
> nManager.java:442)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
> ultLifecycleExecutor.java:694)
> ... 17 more
> 
> 
> Notice this is all core code. It's trying to resolve the dependencies 
> prior to invoking the plugin. As I mentioned earlier in the thread, 
> the plugin sets @requiresDependencyResolution test which tells Maven 
> to resolve the test scope (which means everything) before invoking the 
> plugin.
> 
> If you only run "mvn dependency:tree" there are no references to the 
> other projects in the reactor for Maven to find and use. Try running 
> "mvn compile dependency:tree: and you'll see that it does in fact 
> work. This is just a side effect of how maven 2.x does the resolution.
> 
> Could we rewrite the dependency tree goal to completely work around 
> this? Probably, but it would mean duplicating tons of core logic to 
> make the resolution work in all cases and running tree on a not-yet 
> compiled or installed project is an edge case imo.
> 
> 
> 2009/11/19 Jamie Whitehouse :
> > Many of the dependency plugin goals are reactor aware, but dependency:tree 
> > isn't.  I'm not too sure why, but you could search the issue tracker and if 
> > there's no issue for this file one.
> >
> > -Original Message-
> > From: Jonathan Gold [mailto:jgold...@gmail.com]
> > Sent: Thursday, November 19, 2009 3:00 PM
> > To: users@maven.apache.org
> > Subject: Re: Why would 'mvn dependencies:tree' fail while 'mvn compile' 
> > works?
> >
> > Jamie --
> >
> > Thanks for trying it out, and for the explanation. This makes sense in 
> > terms of why things are happening, so that's nice.
> >
> > I'm not familiar with the dependency plugin developers (are you one?), and 
> > wonder if having the dependency plugin be reactor-aware is something they 
> > would consider? Perhaps its an old tired discussion and the decision to 
> > build that plugin the way it is is said and done.
> >
> > Thanks for your help!
> >
> > jon
> >
> > On Thu, Nov 19, 2009 at 11:43:33AM -0800, Jamie Whitehouse wrote:
> >> What maven commands did you issue to test this?
> >>
> >> I used the attached project and here's the results.
> >> 1) extract zip
> >> 2) mvn dependency:tree
> >>   failed due to dependency resolution
> >> 3) mvn clean install
> >> 4) mvn dependency:tree
> >>   see the tree output
> >>
> >> I think you're misunderstanding how the local maven repo is used and the 
> >> affect reactor builds and plugins that are reactor aware vs not.  AFAIK 
> >> the dependency:tree goal is not reactor aware.  It needs to resolve 
> >> artifacts from the local repo (or download from remote repos if not 
> >> present locally).  Since you haven't mvn installed thes

Re: Why would 'mvn dependencies:tree' fail while 'mvn compile' works?

[Jonathan Gold]

Brian --

Thanks for this. I did run the combo 'mvn compile dependency:tree' as you
mention below, and it works. What I'm taking away from this is that
dependency:tree will work if it's part of the *same* mvn invocation as something
like compile, which forces maven to do the resolution of the local workspace.
Doing 'mvn compile' and then 'mvn dependency:tree' thus does not work.

As a new user, this was (and still is) a bit bizarre, but I'm happy to know how
to get it to work. 

Thanks!

jon

On Fri, Nov 20, 2009 at 03:54:11PM -0500, Brian Fox wrote:
> This isn't exactly true. First, lets take a look at the stack trace:
> 
> --
> 1 required artifact is missing.
> 
> for artifact:
>   com.example:mod_b:jar:1.0
> 
> from the specified remote repositories:
>   mynexus (http://192.168.101.21:8081/nexus/content/groups/public)
> 
> 
> at 
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTra
> nsitively(DefaultArtifactResolver.java:360)
> at 
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTra
> nsitively(DefaultArtifactResolver.java:304)
> at 
> org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDepende
> ncies(DefaultPluginManager.java:1499)
> at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
> nManager.java:442)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
> ultLifecycleExecutor.java:694)
> ... 17 more
> 
> 
> Notice this is all core code. It's trying to resolve the dependencies
> prior to invoking the plugin. As I mentioned earlier in the thread,
> the plugin sets @requiresDependencyResolution test which tells Maven
> to resolve the test scope (which means everything) before invoking the
> plugin.
> 
> If you only run "mvn dependency:tree" there are no references to the
> other projects in the reactor for Maven to find and use. Try running
> "mvn compile dependency:tree: and you'll see that it does in fact
> work. This is just a side effect of how maven 2.x does the resolution.
> 
> Could we rewrite the dependency tree goal to completely work around
> this? Probably, but it would mean duplicating tons of core logic to
> make the resolution work in all cases and running tree on a not-yet
> compiled or installed project is an edge case imo.
> 
> 
> 2009/11/19 Jamie Whitehouse :
> > Many of the dependency plugin goals are reactor aware, but dependency:tree 
> > isn't.  I'm not too sure why, but you could search the issue tracker and if 
> > there's no issue for this file one.
> >
> > -Original Message-
> > From: Jonathan Gold [mailto:jgold...@gmail.com]
> > Sent: Thursday, November 19, 2009 3:00 PM
> > To: users@maven.apache.org
> > Subject: Re: Why would 'mvn dependencies:tree' fail while 'mvn compile' 
> > works?
> >
> > Jamie --
> >
> > Thanks for trying it out, and for the explanation. This makes sense in 
> > terms of why things are happening, so that's nice.
> >
> > I'm not familiar with the dependency plugin developers (are you one?), and 
> > wonder if having the dependency plugin be reactor-aware is something they 
> > would consider? Perhaps its an old tired discussion and the decision to 
> > build that plugin the way it is is said and done.
> >
> > Thanks for your help!
> >
> > jon
> >
> > On Thu, Nov 19, 2009 at 11:43:33AM -0800, Jamie Whitehouse wrote:
> >> What maven commands did you issue to test this?
> >>
> >> I used the attached project and here's the results.
> >> 1) extract zip
> >> 2) mvn dependency:tree
> >>   failed due to dependency resolution
> >> 3) mvn clean install
> >> 4) mvn dependency:tree
> >>   see the tree output
> >>
> >> I think you're misunderstanding how the local maven repo is used and the 
> >> affect reactor builds and plugins that are reactor aware vs not.  AFAIK 
> >> the dependency:tree goal is not reactor aware.  It needs to resolve 
> >> artifacts from the local repo (or download from remote repos if not 
> >> present locally).  Since you haven't mvn installed these into your local 
> >> repo the tree goal states that the artifact is missing.
> >>
> >> The compile goal is reactor aware, and hence if you invoke mvn compile it 
> >> determines the correct order in your multi-module build in order for mod_b 
> >> to resolve the reference to mod_a.  To test this reverse the order of the 

Re: Why would 'mvn dependencies:tree' fail while 'mvn compile' works?

[Brian Fox]

This isn't exactly true. First, lets take a look at the stack trace:

--
1 required artifact is missing.

for artifact:
  com.example:mod_b:jar:1.0

from the specified remote repositories:
  mynexus (http://192.168.101.21:8081/nexus/content/groups/public)


at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTra
nsitively(DefaultArtifactResolver.java:360)
at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTra
nsitively(DefaultArtifactResolver.java:304)
at org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDepende
ncies(DefaultPluginManager.java:1499)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
nManager.java:442)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:694)
... 17 more


Notice this is all core code. It's trying to resolve the dependencies
prior to invoking the plugin. As I mentioned earlier in the thread,
the plugin sets @requiresDependencyResolution test which tells Maven
to resolve the test scope (which means everything) before invoking the
plugin.

If you only run "mvn dependency:tree" there are no references to the
other projects in the reactor for Maven to find and use. Try running
"mvn compile dependency:tree: and you'll see that it does in fact
work. This is just a side effect of how maven 2.x does the resolution.

Could we rewrite the dependency tree goal to completely work around
this? Probably, but it would mean duplicating tons of core logic to
make the resolution work in all cases and running tree on a not-yet
compiled or installed project is an edge case imo.


2009/11/19 Jamie Whitehouse :
> Many of the dependency plugin goals are reactor aware, but dependency:tree 
> isn't.  I'm not too sure why, but you could search the issue tracker and if 
> there's no issue for this file one.
>
> -Original Message-
> From: Jonathan Gold [mailto:jgold...@gmail.com]
> Sent: Thursday, November 19, 2009 3:00 PM
> To: users@maven.apache.org
> Subject: Re: Why would 'mvn dependencies:tree' fail while 'mvn compile' works?
>
> Jamie --
>
> Thanks for trying it out, and for the explanation. This makes sense in terms 
> of why things are happening, so that's nice.
>
> I'm not familiar with the dependency plugin developers (are you one?), and 
> wonder if having the dependency plugin be reactor-aware is something they 
> would consider? Perhaps its an old tired discussion and the decision to build 
> that plugin the way it is is said and done.
>
> Thanks for your help!
>
> jon
>
> On Thu, Nov 19, 2009 at 11:43:33AM -0800, Jamie Whitehouse wrote:
>> What maven commands did you issue to test this?
>>
>> I used the attached project and here's the results.
>> 1) extract zip
>> 2) mvn dependency:tree
>>   failed due to dependency resolution
>> 3) mvn clean install
>> 4) mvn dependency:tree
>>   see the tree output
>>
>> I think you're misunderstanding how the local maven repo is used and the 
>> affect reactor builds and plugins that are reactor aware vs not.  AFAIK the 
>> dependency:tree goal is not reactor aware.  It needs to resolve artifacts 
>> from the local repo (or download from remote repos if not present locally).  
>> Since you haven't mvn installed these into your local repo the tree goal 
>> states that the artifact is missing.
>>
>> The compile goal is reactor aware, and hence if you invoke mvn compile it 
>> determines the correct order in your multi-module build in order for mod_b 
>> to resolve the reference to mod_a.  To test this reverse the order of the 
>> module definitions in the root pom and see that the reactor summary builds 
>> mod_a first despite the modules list having mod_b first.
>>
>> If you want to simulate what dependency:tree does using the compile goal, 
>> just try to compile mod_b on it's own, in it's own sub module (e.g. 
>> c:\maven-repro1\mod_b> mvn compile ), you'll get the same error about not 
>> being able to resolve dependencies.
>>
>> Hope that helps.
>> Jamie.
>>
>> -Original Message-
>> From: Jonathan Gold [mailto:jgold...@gmail.com]
>> Sent: Thursday, November 19, 2009 12:52 PM
>> To: users@maven.apache.org
>> Subject: Re: Why would 'mvn dependencies:tree' fail while 'mvn compile' 
>> works?
>>
>> Brian --
>>
>> Thanks for your help so far. I did put together a very small sample project 
>> that will repro what I'm seeing (attached as a zip). Just run 'mvn 
>> dependency:tree'
>> in the root o

RE: Why would 'mvn dependencies:tree' fail while 'mvn compile' works?

[Jamie Whitehouse]

Many of the dependency plugin goals are reactor aware, but dependency:tree 
isn't.  I'm not too sure why, but you could search the issue tracker and if 
there's no issue for this file one.

-Original Message-
From: Jonathan Gold [mailto:jgold...@gmail.com] 
Sent: Thursday, November 19, 2009 3:00 PM
To: users@maven.apache.org
Subject: Re: Why would 'mvn dependencies:tree' fail while 'mvn compile' works?

Jamie --

Thanks for trying it out, and for the explanation. This makes sense in terms of 
why things are happening, so that's nice.

I'm not familiar with the dependency plugin developers (are you one?), and 
wonder if having the dependency plugin be reactor-aware is something they would 
consider? Perhaps its an old tired discussion and the decision to build that 
plugin the way it is is said and done.

Thanks for your help!

jon

On Thu, Nov 19, 2009 at 11:43:33AM -0800, Jamie Whitehouse wrote:
> What maven commands did you issue to test this?
> 
> I used the attached project and here's the results.
> 1) extract zip
> 2) mvn dependency:tree
>   failed due to dependency resolution
> 3) mvn clean install
> 4) mvn dependency:tree
>   see the tree output
> 
> I think you're misunderstanding how the local maven repo is used and the 
> affect reactor builds and plugins that are reactor aware vs not.  AFAIK the 
> dependency:tree goal is not reactor aware.  It needs to resolve artifacts 
> from the local repo (or download from remote repos if not present locally).  
> Since you haven't mvn installed these into your local repo the tree goal 
> states that the artifact is missing.
> 
> The compile goal is reactor aware, and hence if you invoke mvn compile it 
> determines the correct order in your multi-module build in order for mod_b to 
> resolve the reference to mod_a.  To test this reverse the order of the module 
> definitions in the root pom and see that the reactor summary builds mod_a 
> first despite the modules list having mod_b first.
> 
> If you want to simulate what dependency:tree does using the compile goal, 
> just try to compile mod_b on it's own, in it's own sub module (e.g. 
> c:\maven-repro1\mod_b> mvn compile ), you'll get the same error about not 
> being able to resolve dependencies.
> 
> Hope that helps.
> Jamie.
> 
> -----Original Message-----
> From: Jonathan Gold [mailto:jgold...@gmail.com]
> Sent: Thursday, November 19, 2009 12:52 PM
> To: users@maven.apache.org
> Subject: Re: Why would 'mvn dependencies:tree' fail while 'mvn compile' works?
> 
> Brian --
> 
> Thanks for your help so far. I did put together a very small sample project 
> that will repro what I'm seeing (attached as a zip). Just run 'mvn 
> dependency:tree'
> in the root of the project and see if you get the same error (mod_a is not 
> found, required by mod_b). It does compile fine.
> 
> I'll be interested to see if you get the same results, or have some insights.
> It's totally likely that I'm not setting my poms up correctly.
> 
> Thanks for any help you can give!
> 
> jon
> 
> On Wed, Nov 18, 2009 at 05:53:34PM -0500, Brian Fox wrote:
> > This is not related. The dependency plugin has some issues resolving 
> > things from the reactor and ranges in the following goals only:
> > copy
> > unpack
> > go-offline
> > resolve-plugins
> > 
> > 
> > All the other goals set @requiresDependencyResolution test which 
> > will cause Maven to resolve all dependencies prior to the plugin running.
> > So if you're seeing some error, it's happening in the core. Provide 
> > a sample project and/or some debug output and we might be able to 
> > tell what the problem is.
> > 
> > 
> > On Wed, Nov 18, 2009 at 12:59 PM, Stevo Slavić  wrote:
> > > Likely because dependency plugin has bugs, and I'm suspecting that 
> > > your issue is similar/related to this 
> > > <http://jira.codehaus.org/browse/MDEP-204>one already reported.
> > >
> > > But it's odd that it doesn't fail for you at module mod_c, as 
> > > build reactor should have ordered mod_c to be built/processed 
> > > before mod_d. Just guessing, maybe this mojo doesn't use maven 
> > > reactor at all, and probably mod_c is ordered in list of modules in your 
> > > parent module after mod_d.
> > >
> > > Regards,
> > > Stevo.
> > >
> > > On Wed, Nov 18, 2009 at 6:37 PM, Jonathan Gold  wrote:
> > >
> > >> Hi --
> > >>
> > >> I'm trying to track down some other depdendency issues in my 

Re: Why would 'mvn dependencies:tree' fail while 'mvn compile' works?

[Jonathan Gold]

Jamie --

Thanks for trying it out, and for the explanation. This makes sense in terms of
why things are happening, so that's nice.

I'm not familiar with the dependency plugin developers (are you one?), and
wonder if having the dependency plugin be reactor-aware is something they would
consider? Perhaps its an old tired discussion and the decision to build that
plugin the way it is is said and done.

Thanks for your help!

jon

On Thu, Nov 19, 2009 at 11:43:33AM -0800, Jamie Whitehouse wrote:
> What maven commands did you issue to test this?
> 
> I used the attached project and here's the results.
> 1) extract zip
> 2) mvn dependency:tree
>   failed due to dependency resolution
> 3) mvn clean install
> 4) mvn dependency:tree
>   see the tree output
> 
> I think you're misunderstanding how the local maven repo is used and the 
> affect reactor builds and plugins that are reactor aware vs not.  AFAIK the 
> dependency:tree goal is not reactor aware.  It needs to resolve artifacts 
> from the local repo (or download from remote repos if not present locally).  
> Since you haven't mvn installed these into your local repo the tree goal 
> states that the artifact is missing.
> 
> The compile goal is reactor aware, and hence if you invoke mvn compile it 
> determines the correct order in your multi-module build in order for mod_b to 
> resolve the reference to mod_a.  To test this reverse the order of the module 
> definitions in the root pom and see that the reactor summary builds mod_a 
> first despite the modules list having mod_b first.
> 
> If you want to simulate what dependency:tree does using the compile goal, 
> just try to compile mod_b on it's own, in it's own sub module (e.g. 
> c:\maven-repro1\mod_b> mvn compile ), you'll get the same error about not 
> being able to resolve dependencies.
> 
> Hope that helps.
> Jamie.
> 
> -Original Message-----
> From: Jonathan Gold [mailto:jgold...@gmail.com] 
> Sent: Thursday, November 19, 2009 12:52 PM
> To: users@maven.apache.org
> Subject: Re: Why would 'mvn dependencies:tree' fail while 'mvn compile' works?
> 
> Brian --
> 
> Thanks for your help so far. I did put together a very small sample project 
> that will repro what I'm seeing (attached as a zip). Just run 'mvn 
> dependency:tree'
> in the root of the project and see if you get the same error (mod_a is not 
> found, required by mod_b). It does compile fine.
> 
> I'll be interested to see if you get the same results, or have some insights.
> It's totally likely that I'm not setting my poms up correctly.
> 
> Thanks for any help you can give!
> 
> jon
> 
> On Wed, Nov 18, 2009 at 05:53:34PM -0500, Brian Fox wrote:
> > This is not related. The dependency plugin has some issues resolving 
> > things from the reactor and ranges in the following goals only:
> > copy
> > unpack
> > go-offline
> > resolve-plugins
> > 
> > 
> > All the other goals set @requiresDependencyResolution test which will 
> > cause Maven to resolve all dependencies prior to the plugin running.
> > So if you're seeing some error, it's happening in the core. Provide a 
> > sample project and/or some debug output and we might be able to tell 
> > what the problem is.
> > 
> > 
> > On Wed, Nov 18, 2009 at 12:59 PM, Stevo Slavić  wrote:
> > > Likely because dependency plugin has bugs, and I'm suspecting that 
> > > your issue is similar/related to this 
> > > <http://jira.codehaus.org/browse/MDEP-204>one already reported.
> > >
> > > But it's odd that it doesn't fail for you at module mod_c, as build 
> > > reactor should have ordered mod_c to be built/processed before 
> > > mod_d. Just guessing, maybe this mojo doesn't use maven reactor at 
> > > all, and probably mod_c is ordered in list of modules in your parent 
> > > module after mod_d.
> > >
> > > Regards,
> > > Stevo.
> > >
> > > On Wed, Nov 18, 2009 at 6:37 PM, Jonathan Gold  wrote:
> > >
> > >> Hi --
> > >>
> > >> I'm trying to track down some other depdendency issues in my 
> > >> project using dependencies:tree, but am getting errors that a module 
> > >> isn't found.
> > >>
> > >> I have my project set up with a parent pom and a list of modules, 
> > >> each referencing the parent, etc. Essentially, I have this:
> > >>
> > >>    pom.xml # parent, references mods a, b, c, d in 
> > >>    mod_a/pom.xml # module, n

RE: Why would 'mvn dependencies:tree' fail while 'mvn compile' works?

[Jamie Whitehouse]

What maven commands did you issue to test this?

I used the attached project and here's the results.
1) extract zip
2) mvn dependency:tree
  failed due to dependency resolution
3) mvn clean install
4) mvn dependency:tree
  see the tree output

I think you're misunderstanding how the local maven repo is used and the affect 
reactor builds and plugins that are reactor aware vs not.  AFAIK the 
dependency:tree goal is not reactor aware.  It needs to resolve artifacts from 
the local repo (or download from remote repos if not present locally).  Since 
you haven't mvn installed these into your local repo the tree goal states that 
the artifact is missing.

The compile goal is reactor aware, and hence if you invoke mvn compile it 
determines the correct order in your multi-module build in order for mod_b to 
resolve the reference to mod_a.  To test this reverse the order of the module 
definitions in the root pom and see that the reactor summary builds mod_a first 
despite the modules list having mod_b first.

If you want to simulate what dependency:tree does using the compile goal, just 
try to compile mod_b on it's own, in it's own sub module (e.g. 
c:\maven-repro1\mod_b> mvn compile ), you'll get the same error about not being 
able to resolve dependencies.

Hope that helps.
Jamie.

-Original Message-
From: Jonathan Gold [mailto:jgold...@gmail.com] 
Sent: Thursday, November 19, 2009 12:52 PM
To: users@maven.apache.org
Subject: Re: Why would 'mvn dependencies:tree' fail while 'mvn compile' works?

Brian --

Thanks for your help so far. I did put together a very small sample project 
that will repro what I'm seeing (attached as a zip). Just run 'mvn 
dependency:tree'
in the root of the project and see if you get the same error (mod_a is not 
found, required by mod_b). It does compile fine.

I'll be interested to see if you get the same results, or have some insights.
It's totally likely that I'm not setting my poms up correctly.

Thanks for any help you can give!

jon

On Wed, Nov 18, 2009 at 05:53:34PM -0500, Brian Fox wrote:
> This is not related. The dependency plugin has some issues resolving 
> things from the reactor and ranges in the following goals only:
> copy
> unpack
> go-offline
> resolve-plugins
> 
> 
> All the other goals set @requiresDependencyResolution test which will 
> cause Maven to resolve all dependencies prior to the plugin running.
> So if you're seeing some error, it's happening in the core. Provide a 
> sample project and/or some debug output and we might be able to tell 
> what the problem is.
> 
> 
> On Wed, Nov 18, 2009 at 12:59 PM, Stevo Slavić  wrote:
> > Likely because dependency plugin has bugs, and I'm suspecting that 
> > your issue is similar/related to this 
> > <http://jira.codehaus.org/browse/MDEP-204>one already reported.
> >
> > But it's odd that it doesn't fail for you at module mod_c, as build 
> > reactor should have ordered mod_c to be built/processed before 
> > mod_d. Just guessing, maybe this mojo doesn't use maven reactor at 
> > all, and probably mod_c is ordered in list of modules in your parent module 
> > after mod_d.
> >
> > Regards,
> > Stevo.
> >
> > On Wed, Nov 18, 2009 at 6:37 PM, Jonathan Gold  wrote:
> >
> >> Hi --
> >>
> >> I'm trying to track down some other depdendency issues in my 
> >> project using dependencies:tree, but am getting errors that a module isn't 
> >> found.
> >>
> >> I have my project set up with a parent pom and a list of modules, 
> >> each referencing the parent, etc. Essentially, I have this:
> >>
> >>    pom.xml # parent, references mods a, b, c, d in 
> >>    mod_a/pom.xml # module, no module dependencies
> >>    mod_b/pom.xml # module, no module dependencies
> >>    mod_c/pom.xml # module, declared dependency on mod_b
> >>    mod_d/pom.xml # module, declared depdenency on mod_a, mod_b, 
> >> mod_c
> >>
> >> From the root workspace directory, I can run things like 'compile' 
> >> or 'jar:jar'
> >> just fine, but for some reason 'dependencies:tree' is failing when 
> >> it gets to mod_d, complaining that it can't find mod_c.
> >>
> >> Any ideas what I'm doing wrong?
> >>
> >> jon
> >>
> >> ---
> >> -- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: users-h...@maven.apache.org
> >>
> >>
> >
> 
> 

Re: Why would 'mvn dependencies:tree' fail while 'mvn compile' works?

[Brian Fox]

This is not related. The dependency plugin has some issues resolving
things from the reactor and ranges in the following goals only:
copy
unpack
go-offline
resolve-plugins


All the other goals set @requiresDependencyResolution test which will
cause Maven to resolve all dependencies prior to the plugin running.
So if you're seeing some error, it's happening in the core. Provide a
sample project and/or some debug output and we might be able to tell
what the problem is.


On Wed, Nov 18, 2009 at 12:59 PM, Stevo Slavić  wrote:
> Likely because dependency plugin has bugs, and I'm suspecting that your
> issue is similar/related to this
> one already reported.
>
> But it's odd that it doesn't fail for you at module mod_c, as build reactor
> should have ordered mod_c to be built/processed before mod_d. Just guessing,
> maybe this mojo doesn't use maven reactor at all, and probably mod_c is
> ordered in list of modules in your parent module after mod_d.
>
> Regards,
> Stevo.
>
> On Wed, Nov 18, 2009 at 6:37 PM, Jonathan Gold  wrote:
>
>> Hi --
>>
>> I'm trying to track down some other depdendency issues in my project using
>> dependencies:tree, but am getting errors that a module isn't found.
>>
>> I have my project set up with a parent pom and a list of modules, each
>> referencing the parent, etc. Essentially, I have this:
>>
>>    pom.xml # parent, references mods a, b, c, d in 
>>    mod_a/pom.xml # module, no module dependencies
>>    mod_b/pom.xml # module, no module dependencies
>>    mod_c/pom.xml # module, declared dependency on mod_b
>>    mod_d/pom.xml # module, declared depdenency on mod_a, mod_b, mod_c
>>
>> From the root workspace directory, I can run things like 'compile' or
>> 'jar:jar'
>> just fine, but for some reason 'dependencies:tree' is failing when it gets
>> to
>> mod_d, complaining that it can't find mod_c.
>>
>> Any ideas what I'm doing wrong?
>>
>> jon
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
>

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Why would 'mvn dependencies:tree' fail while 'mvn compile' works?

[Jonathan Gold]

Jamie --

Thanks for the response. I don't have mod_d depending on a snapshot -- just on
the sibling module itself. Also, I'm not installing versions in the local repo
at the point I'm seeing this problem (and would rather not, actually, since it's
just for development anyway).

If mod_d was depending on a SNAPSHOT version (I saw something about SNAPSHOTS in
the docs, I'll go back and take a look), do you think that would have some
effect?

jon

On Wed, Nov 18, 2009 at 12:30:34PM -0800, Jamie Whitehouse wrote:
> AFAIK dependency tree does not run in the reactor.  Is mod_d depending
> on a SNAPSHOT version of mod_c?  Do you have that version installed in
> your local repo?
> 
> I have used dependency tree many time on a large mutli-module project so
> I can attest that it does work in some form. 
> 
> -Original Message-
> From: Jonathan Gold [mailto:jgold...@gmail.com] 
> Sent: Wednesday, November 18, 2009 12:37 PM
> To: users@maven.apache.org
> Subject: Why would 'mvn dependencies:tree' fail while 'mvn compile'
> works?
> 
> Hi --
> 
> I'm trying to track down some other depdendency issues in my project
> using dependencies:tree, but am getting errors that a module isn't
> found.
> 
> I have my project set up with a parent pom and a list of modules, each
> referencing the parent, etc. Essentially, I have this:
> 
> pom.xml # parent, references mods a, b, c, d in 
> mod_a/pom.xml # module, no module dependencies
> mod_b/pom.xml # module, no module dependencies
> mod_c/pom.xml # module, declared dependency on mod_b
> mod_d/pom.xml # module, declared depdenency on mod_a, mod_b, mod_c
> 
> >From the root workspace directory, I can run things like 'compile' or
> 'jar:jar'
> just fine, but for some reason 'dependencies:tree' is failing when it
> gets to mod_d, complaining that it can't find mod_c.
> 
> Any ideas what I'm doing wrong?
> 
> jon
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 
>   
> ---
> CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain 
> confidential and proprietary information of Alcatel-Lucent and/or its 
> affiliated entities. Access by the intended recipient only is authorized. Any 
> liability arising from any party acting, or refraining from acting, on any 
> information contained in this e-mail is hereby excluded. If you are not the 
> intended recipient, please notify the sender immediately, destroy the 
> original transmission and its attachments and do not disclose the contents to 
> any other person, use it for any purpose, or store or copy the information in 
> any medium. Copyright in this e-mail and any attachments belongs to 
> Alcatel-Lucent and/or its affiliated entities.
>   
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: Why would 'mvn dependencies:tree' fail while 'mvn compile' works?

[Jamie Whitehouse]

AFAIK dependency tree does not run in the reactor.  Is mod_d depending
on a SNAPSHOT version of mod_c?  Do you have that version installed in
your local repo?

I have used dependency tree many time on a large mutli-module project so
I can attest that it does work in some form. 

-Original Message-
From: Jonathan Gold [mailto:jgold...@gmail.com] 
Sent: Wednesday, November 18, 2009 12:37 PM
To: users@maven.apache.org
Subject: Why would 'mvn dependencies:tree' fail while 'mvn compile'
works?

Hi --

I'm trying to track down some other depdendency issues in my project
using dependencies:tree, but am getting errors that a module isn't
found.

I have my project set up with a parent pom and a list of modules, each
referencing the parent, etc. Essentially, I have this:

pom.xml # parent, references mods a, b, c, d in 
mod_a/pom.xml # module, no module dependencies
mod_b/pom.xml # module, no module dependencies
mod_c/pom.xml # module, declared dependency on mod_b
mod_d/pom.xml # module, declared depdenency on mod_a, mod_b, mod_c

>From the root workspace directory, I can run things like 'compile' or
'jar:jar'
just fine, but for some reason 'dependencies:tree' is failing when it
gets to mod_d, complaining that it can't find mod_c.

Any ideas what I'm doing wrong?

jon

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org



---
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain 
confidential and proprietary information of Alcatel-Lucent and/or its 
affiliated entities. Access by the intended recipient only is authorized. Any 
liability arising from any party acting, or refraining from acting, on any 
information contained in this e-mail is hereby excluded. If you are not the 
intended recipient, please notify the sender immediately, destroy the original 
transmission and its attachments and do not disclose the contents to any other 
person, use it for any purpose, or store or copy the information in any medium. 
Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or 
its affiliated entities.


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Why would 'mvn dependencies:tree' fail while 'mvn compile' works?

[Stevo Slavić]

You could try to install your project first, and after that run
dependency:tree.

Regards,
Stevo.

On Wed, Nov 18, 2009 at 7:05 PM, Jonathan Gold  wrote:

> Thanks for the response. In fact, I have all of my modules listed in
> depdendency
> order in the parent pom, so it's quite odd indeed.
>
> Thanks for the tip -- I voted for the bug, for what it's worth.
>
> jon
>
> On Wed, Nov 18, 2009 at 06:59:41PM +0100, Stevo Slavić wrote:
> > Likely because dependency plugin has bugs, and I'm suspecting that your
> > issue is similar/related to this
> > one already reported.
> >
> > But it's odd that it doesn't fail for you at module mod_c, as build
> reactor
> > should have ordered mod_c to be built/processed before mod_d. Just
> guessing,
> > maybe this mojo doesn't use maven reactor at all, and probably mod_c is
> > ordered in list of modules in your parent module after mod_d.
> >
> > Regards,
> > Stevo.
> >
> > On Wed, Nov 18, 2009 at 6:37 PM, Jonathan Gold 
> wrote:
> >
> > > Hi --
> > >
> > > I'm trying to track down some other depdendency issues in my project
> using
> > > dependencies:tree, but am getting errors that a module isn't found.
> > >
> > > I have my project set up with a parent pom and a list of modules, each
> > > referencing the parent, etc. Essentially, I have this:
> > >
> > >pom.xml # parent, references mods a, b, c, d in 
> > >mod_a/pom.xml # module, no module dependencies
> > >mod_b/pom.xml # module, no module dependencies
> > >mod_c/pom.xml # module, declared dependency on mod_b
> > >mod_d/pom.xml # module, declared depdenency on mod_a, mod_b, mod_c
> > >
> > > From the root workspace directory, I can run things like 'compile' or
> > > 'jar:jar'
> > > just fine, but for some reason 'dependencies:tree' is failing when it
> gets
> > > to
> > > mod_d, complaining that it can't find mod_c.
> > >
> > > Any ideas what I'm doing wrong?
> > >
> > > jon
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: users-h...@maven.apache.org
> > >
> > >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Why would 'mvn dependencies:tree' fail while 'mvn compile' works?

[Jonathan Gold]

Thanks for the response. In fact, I have all of my modules listed in depdendency
order in the parent pom, so it's quite odd indeed.

Thanks for the tip -- I voted for the bug, for what it's worth.

jon

On Wed, Nov 18, 2009 at 06:59:41PM +0100, Stevo Slavić wrote:
> Likely because dependency plugin has bugs, and I'm suspecting that your
> issue is similar/related to this
> one already reported.
> 
> But it's odd that it doesn't fail for you at module mod_c, as build reactor
> should have ordered mod_c to be built/processed before mod_d. Just guessing,
> maybe this mojo doesn't use maven reactor at all, and probably mod_c is
> ordered in list of modules in your parent module after mod_d.
> 
> Regards,
> Stevo.
> 
> On Wed, Nov 18, 2009 at 6:37 PM, Jonathan Gold  wrote:
> 
> > Hi --
> >
> > I'm trying to track down some other depdendency issues in my project using
> > dependencies:tree, but am getting errors that a module isn't found.
> >
> > I have my project set up with a parent pom and a list of modules, each
> > referencing the parent, etc. Essentially, I have this:
> >
> >pom.xml # parent, references mods a, b, c, d in 
> >mod_a/pom.xml # module, no module dependencies
> >mod_b/pom.xml # module, no module dependencies
> >mod_c/pom.xml # module, declared dependency on mod_b
> >mod_d/pom.xml # module, declared depdenency on mod_a, mod_b, mod_c
> >
> > From the root workspace directory, I can run things like 'compile' or
> > 'jar:jar'
> > just fine, but for some reason 'dependencies:tree' is failing when it gets
> > to
> > mod_d, complaining that it can't find mod_c.
> >
> > Any ideas what I'm doing wrong?
> >
> > jon
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Why would 'mvn dependencies:tree' fail while 'mvn compile' works?

[Stevo Slavić]

Likely because dependency plugin has bugs, and I'm suspecting that your
issue is similar/related to this
one already reported.

But it's odd that it doesn't fail for you at module mod_c, as build reactor
should have ordered mod_c to be built/processed before mod_d. Just guessing,
maybe this mojo doesn't use maven reactor at all, and probably mod_c is
ordered in list of modules in your parent module after mod_d.

Regards,
Stevo.

On Wed, Nov 18, 2009 at 6:37 PM, Jonathan Gold  wrote:

> Hi --
>
> I'm trying to track down some other depdendency issues in my project using
> dependencies:tree, but am getting errors that a module isn't found.
>
> I have my project set up with a parent pom and a list of modules, each
> referencing the parent, etc. Essentially, I have this:
>
>pom.xml # parent, references mods a, b, c, d in 
>mod_a/pom.xml # module, no module dependencies
>mod_b/pom.xml # module, no module dependencies
>mod_c/pom.xml # module, declared dependency on mod_b
>mod_d/pom.xml # module, declared depdenency on mod_a, mod_b, mod_c
>
> From the root workspace directory, I can run things like 'compile' or
> 'jar:jar'
> just fine, but for some reason 'dependencies:tree' is failing when it gets
> to
> mod_d, complaining that it can't find mod_c.
>
> Any ideas what I'm doing wrong?
>
> jon
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>