RE: Why would 'mvn dependencies:tree' fail while 'mvn compile' works?
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?
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 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
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
Re: Why would 'mvn dependencies:tree' fail while 'mvn compile' works?
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
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 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
RE: Why would 'mvn dependencies:tree' fail while 'mvn compile' works?
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 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
RE: Why would 'mvn dependencies:tree' fail while 'mvn compile' works?
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-204one 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
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-204one 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
RE: Why would 'mvn dependencies:tree' fail while 'mvn compile' works?
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-204one 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
Re: Why would 'mvn dependencies:tree' fail while 'mvn compile' works?
Likely because dependency plugin has bugs, and I'm suspecting that your issue is similar/related to this http://jira.codehaus.org/browse/MDEP-204one 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
Re: Why would 'mvn dependencies:tree' fail while 'mvn compile' works?
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 http://jira.codehaus.org/browse/MDEP-204one 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
Re: Why would 'mvn dependencies:tree' fail while 'mvn compile' works?
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 jgold...@gmail.com 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 http://jira.codehaus.org/browse/MDEP-204one 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
RE: Why would 'mvn dependencies:tree' fail while 'mvn compile' works?
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 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 --- 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?
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 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 --- 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?
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-204one 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
