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 <jamie.whiteho...@genesyslab.com>: > > 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ć <ssla...@gmail.com> 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 <jgold...@gmail.com> > >> > > 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 <modules> > >> > >> 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 > >> > >> > >> ---------------------------------------------------------------------- > >> --------------------------------------------- > >> 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 > > > > > > > > ------------------------------------------------------------------------------------------------------------------- > > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
