RE: dependency.getDependencies()
Would things with classifiers be excluded from this list? How about types other than jar? I still (with things set as compile) can't get things to show up in the list... -Original Message- From: Stuart McCulloch [mailto:mccu...@gmail.com] Sent: Thursday, December 11, 2008 9:25 PM To: Maven Users List Subject: Re: dependency.getDependencies() 2008/12/12 EJ Ciramella ecirame...@upromise.com Hmmm, where to start Firstly, we've created our own packaging type (atg-module). This packaging type generates a jar and a zip. The zip is what has the scope of provided. This isn't a compile time dependency and we did NOT want the zip showing up in every jar generated where there is a dependency on said zip. So the scope of provided is used. The dependency list is used for generating a special manifest file for the consumer of these modules. I say special because this is a non-standard java manifest file so there aren't options for things we needed to tuck in there or the ordering we needed etc. After talking to a developer here, what we probably could have done is left a compile time dependency and then where we are building a war, configure the war plugin to exclude any atg-module type artifacts from the packaging. What really strikes me as odd is why wouldn't C show up? A to B shows up, so why wouldn't B to C? from http://maven.apache.org/guides/introduction/introduction-to-dependency-m echanism.html#Transitive_Dependencies *provided* This is much like compile, but indicates you expect the JDK or a container to provide the dependency at runtime. For example, when building a web application for the Java Enterprise Edition, you would set the dependency on the Servlet API and related Java EE APIs to scope provided because the web container provides those classes. This scope is only available on the compilation and test classpath, and is not transitive. so provided scope dependencies are never transitive, which explains why you see B (the direct dependency) but not C. A depends on B depends on C A to B is provided B to C is provided B shows up C does not. -Original Message- From: Wayne Fay [mailto:wayne...@gmail.com] Sent: Thursday, December 11, 2008 5:49 PM To: Maven Users List Subject: Re: dependency.getDependencies() In that example, I don't believe C will ever show up in a deps tree or report. So I'm not surprised the API does not reveal them. Transitive deps of provided deps are basically your problem. If B to C is compile, do you see any difference in the deps reported? I don't believe so. What is the business case that would indicate this should be supported? This says I will be providing B in my container, but need all of B's deps (which I do not depend on in A directly) included in A -- that makes no sense. Wayne On Thu, Dec 11, 2008 at 1:17 PM, EJ Ciramella ecirame...@upromise.com wrote: That still doesn't return a dependency of a dependency where the last one is of scope provided. A depends on B depends on C A to B is provided B to C is provided B shows up C does not. -Original Message- From: sirly...@gmail.com [mailto:sirly...@gmail.com] On Behalf Of John Stoneham Sent: Thursday, December 11, 2008 1:20 PM To: Maven Users List Subject: Re: dependency.getDependencies() On Thu, Dec 11, 2008 at 9:25 AM, EJ Ciramella ecirame...@upromise.com wrote: is there a way to get ALL dependencies (including transitive ones)? Marking your mojo with @requiresDependencyResolution test ought to resolve all this out for you and populate the artifacts variables on the MavenProject object. - John - 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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Cheers, Stuart - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: dependency.getDependencies()
NVM - I can see that I was using the wrong get method. Nothing to see here -Original Message- From: EJ Ciramella [mailto:ecirame...@upromise.com] Sent: Monday, December 15, 2008 3:28 PM To: Maven Users List Subject: RE: dependency.getDependencies() Would things with classifiers be excluded from this list? How about types other than jar? I still (with things set as compile) can't get things to show up in the list... -Original Message- From: Stuart McCulloch [mailto:mccu...@gmail.com] Sent: Thursday, December 11, 2008 9:25 PM To: Maven Users List Subject: Re: dependency.getDependencies() 2008/12/12 EJ Ciramella ecirame...@upromise.com Hmmm, where to start Firstly, we've created our own packaging type (atg-module). This packaging type generates a jar and a zip. The zip is what has the scope of provided. This isn't a compile time dependency and we did NOT want the zip showing up in every jar generated where there is a dependency on said zip. So the scope of provided is used. The dependency list is used for generating a special manifest file for the consumer of these modules. I say special because this is a non-standard java manifest file so there aren't options for things we needed to tuck in there or the ordering we needed etc. After talking to a developer here, what we probably could have done is left a compile time dependency and then where we are building a war, configure the war plugin to exclude any atg-module type artifacts from the packaging. What really strikes me as odd is why wouldn't C show up? A to B shows up, so why wouldn't B to C? from http://maven.apache.org/guides/introduction/introduction-to-dependency-m echanism.html#Transitive_Dependencies *provided* This is much like compile, but indicates you expect the JDK or a container to provide the dependency at runtime. For example, when building a web application for the Java Enterprise Edition, you would set the dependency on the Servlet API and related Java EE APIs to scope provided because the web container provides those classes. This scope is only available on the compilation and test classpath, and is not transitive. so provided scope dependencies are never transitive, which explains why you see B (the direct dependency) but not C. A depends on B depends on C A to B is provided B to C is provided B shows up C does not. -Original Message- From: Wayne Fay [mailto:wayne...@gmail.com] Sent: Thursday, December 11, 2008 5:49 PM To: Maven Users List Subject: Re: dependency.getDependencies() In that example, I don't believe C will ever show up in a deps tree or report. So I'm not surprised the API does not reveal them. Transitive deps of provided deps are basically your problem. If B to C is compile, do you see any difference in the deps reported? I don't believe so. What is the business case that would indicate this should be supported? This says I will be providing B in my container, but need all of B's deps (which I do not depend on in A directly) included in A -- that makes no sense. Wayne On Thu, Dec 11, 2008 at 1:17 PM, EJ Ciramella ecirame...@upromise.com wrote: That still doesn't return a dependency of a dependency where the last one is of scope provided. A depends on B depends on C A to B is provided B to C is provided B shows up C does not. -Original Message- From: sirly...@gmail.com [mailto:sirly...@gmail.com] On Behalf Of John Stoneham Sent: Thursday, December 11, 2008 1:20 PM To: Maven Users List Subject: Re: dependency.getDependencies() On Thu, Dec 11, 2008 at 9:25 AM, EJ Ciramella ecirame...@upromise.com wrote: is there a way to get ALL dependencies (including transitive ones)? Marking your mojo with @requiresDependencyResolution test ought to resolve all this out for you and populate the artifacts variables on the MavenProject object. - John - 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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Cheers, Stuart - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h
dependency.getDependencies()
Is there a way to do what the pseudo code in the subject line is talking about in a maven plugin? We wrote a home grown, depth first dependency traversing package (because we couldn't find this documented anywhere), but there are short comings to it. I'd prefer that we leverage the built in maven dependency mechanism versus trying to create our own.
RE: dependency.getDependencies()
Nvm - I found a much better approach to doing any of this - -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Thursday, December 11, 2008 9:33 AM To: users@maven.apache.org Subject: dependency.getDependencies() Is there a way to do what the pseudo code in the subject line is talking about in a maven plugin? We wrote a home grown, depth first dependency traversing package (because we couldn't find this documented anywhere), but there are short comings to it. I'd prefer that we leverage the built in maven dependency mechanism versus trying to create our own. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: dependency.getDependencies()
Well, I'm getting ahead of myself a bit - is there a way to get ALL dependencies (including transitive ones)? It can be as high as from the project level, not from an individual dependency. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Thursday, December 11, 2008 9:55 AM To: Maven Users List Subject: RE: dependency.getDependencies() Nvm - I found a much better approach to doing any of this - -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Thursday, December 11, 2008 9:33 AM To: users@maven.apache.org Subject: dependency.getDependencies() Is there a way to do what the pseudo code in the subject line is talking about in a maven plugin? We wrote a home grown, depth first dependency traversing package (because we couldn't find this documented anywhere), but there are short comings to it. I'd prefer that we leverage the built in maven dependency mechanism versus trying to create our own. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dependency.getDependencies()
On Thu, Dec 11, 2008 at 9:25 AM, EJ Ciramella [EMAIL PROTECTED] wrote: is there a way to get ALL dependencies (including transitive ones)? It sounds like this thread might help: http://www.nabble.com/How-to-get-all-dependecy-in-a-mojo---td19533728.html#a19533728 depth first dependency traversing package When my mojo needed needed a hierarchical view of the dependency tree, I used the API that dependency:tree uses: org.apache.maven.shared.dependency.tree.DependencyNode http://maven.apache.org/shared/maven-dependency-tree/apidocs/org/apache/maven/shared/dependency/tree/DependencyNode.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: dependency.getDependencies()
Thank you - let me digest -Original Message- From: Luke Patterson [mailto:lukewpatter...@gmail.com] Sent: Thursday, December 11, 2008 10:46 AM To: Maven Users List Subject: Re: dependency.getDependencies() On Thu, Dec 11, 2008 at 9:25 AM, EJ Ciramella ecirame...@upromise.com wrote: is there a way to get ALL dependencies (including transitive ones)? It sounds like this thread might help: http://www.nabble.com/How-to-get-all-dependecy-in-a-mojo---td19533728.ht ml#a19533728 depth first dependency traversing package When my mojo needed needed a hierarchical view of the dependency tree, I used the API that dependency:tree uses: org.apache.maven.shared.dependency.tree.DependencyNode http://maven.apache.org/shared/maven-dependency-tree/apidocs/org/apache/ maven/shared/dependency/tree/DependencyNode.html - 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: dependency.getDependencies()
I'm still missing some dependencies that have a scope of provided - does that conflict with @requiresDependencyResolution setting? -Original Message- From: EJ Ciramella [mailto:ecirame...@upromise.com] Sent: Thursday, December 11, 2008 1:33 PM To: Maven Users List Subject: RE: dependency.getDependencies() Thank you - let me digest -Original Message- From: Luke Patterson [mailto:lukewpatter...@gmail.com] Sent: Thursday, December 11, 2008 10:46 AM To: Maven Users List Subject: Re: dependency.getDependencies() On Thu, Dec 11, 2008 at 9:25 AM, EJ Ciramella ecirame...@upromise.com wrote: is there a way to get ALL dependencies (including transitive ones)? It sounds like this thread might help: http://www.nabble.com/How-to-get-all-dependecy-in-a-mojo---td19533728.ht ml#a19533728 depth first dependency traversing package When my mojo needed needed a hierarchical view of the dependency tree, I used the API that dependency:tree uses: org.apache.maven.shared.dependency.tree.DependencyNode http://maven.apache.org/shared/maven-dependency-tree/apidocs/org/apache/ maven/shared/dependency/tree/DependencyNode.html - 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
Re: dependency.getDependencies()
On Thu, Dec 11, 2008 at 9:25 AM, EJ Ciramella ecirame...@upromise.com wrote: is there a way to get ALL dependencies (including transitive ones)? Marking your mojo with @requiresDependencyResolution test ought to resolve all this out for you and populate the artifacts variables on the MavenProject object. - John - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: dependency.getDependencies()
That still doesn't return a dependency of a dependency where the last one is of scope provided. A depends on B depends on C A to B is provided B to C is provided B shows up C does not. -Original Message- From: sirly...@gmail.com [mailto:sirly...@gmail.com] On Behalf Of John Stoneham Sent: Thursday, December 11, 2008 1:20 PM To: Maven Users List Subject: Re: dependency.getDependencies() On Thu, Dec 11, 2008 at 9:25 AM, EJ Ciramella ecirame...@upromise.com wrote: is there a way to get ALL dependencies (including transitive ones)? Marking your mojo with @requiresDependencyResolution test ought to resolve all this out for you and populate the artifacts variables on the MavenProject object. - John - 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: dependency.getDependencies()
In that example, I don't believe C will ever show up in a deps tree or report. So I'm not surprised the API does not reveal them. Transitive deps of provided deps are basically your problem. If B to C is compile, do you see any difference in the deps reported? I don't believe so. What is the business case that would indicate this should be supported? This says I will be providing B in my container, but need all of B's deps (which I do not depend on in A directly) included in A -- that makes no sense. Wayne On Thu, Dec 11, 2008 at 1:17 PM, EJ Ciramella ecirame...@upromise.com wrote: That still doesn't return a dependency of a dependency where the last one is of scope provided. A depends on B depends on C A to B is provided B to C is provided B shows up C does not. -Original Message- From: sirly...@gmail.com [mailto:sirly...@gmail.com] On Behalf Of John Stoneham Sent: Thursday, December 11, 2008 1:20 PM To: Maven Users List Subject: Re: dependency.getDependencies() On Thu, Dec 11, 2008 at 9:25 AM, EJ Ciramella ecirame...@upromise.com wrote: is there a way to get ALL dependencies (including transitive ones)? Marking your mojo with @requiresDependencyResolution test ought to resolve all this out for you and populate the artifacts variables on the MavenProject object. - John - 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
RE: dependency.getDependencies()
Hmmm, where to start Firstly, we've created our own packaging type (atg-module). This packaging type generates a jar and a zip. The zip is what has the scope of provided. This isn't a compile time dependency and we did NOT want the zip showing up in every jar generated where there is a dependency on said zip. So the scope of provided is used. The dependency list is used for generating a special manifest file for the consumer of these modules. I say special because this is a non-standard java manifest file so there aren't options for things we needed to tuck in there or the ordering we needed etc. After talking to a developer here, what we probably could have done is left a compile time dependency and then where we are building a war, configure the war plugin to exclude any atg-module type artifacts from the packaging. What really strikes me as odd is why wouldn't C show up? A to B shows up, so why wouldn't B to C? A depends on B depends on C A to B is provided B to C is provided B shows up C does not. -Original Message- From: Wayne Fay [mailto:wayne...@gmail.com] Sent: Thursday, December 11, 2008 5:49 PM To: Maven Users List Subject: Re: dependency.getDependencies() In that example, I don't believe C will ever show up in a deps tree or report. So I'm not surprised the API does not reveal them. Transitive deps of provided deps are basically your problem. If B to C is compile, do you see any difference in the deps reported? I don't believe so. What is the business case that would indicate this should be supported? This says I will be providing B in my container, but need all of B's deps (which I do not depend on in A directly) included in A -- that makes no sense. Wayne On Thu, Dec 11, 2008 at 1:17 PM, EJ Ciramella ecirame...@upromise.com wrote: That still doesn't return a dependency of a dependency where the last one is of scope provided. A depends on B depends on C A to B is provided B to C is provided B shows up C does not. -Original Message- From: sirly...@gmail.com [mailto:sirly...@gmail.com] On Behalf Of John Stoneham Sent: Thursday, December 11, 2008 1:20 PM To: Maven Users List Subject: Re: dependency.getDependencies() On Thu, Dec 11, 2008 at 9:25 AM, EJ Ciramella ecirame...@upromise.com wrote: is there a way to get ALL dependencies (including transitive ones)? Marking your mojo with @requiresDependencyResolution test ought to resolve all this out for you and populate the artifacts variables on the MavenProject object. - John - 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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: dependency.getDependencies()
2008/12/12 EJ Ciramella ecirame...@upromise.com Hmmm, where to start Firstly, we've created our own packaging type (atg-module). This packaging type generates a jar and a zip. The zip is what has the scope of provided. This isn't a compile time dependency and we did NOT want the zip showing up in every jar generated where there is a dependency on said zip. So the scope of provided is used. The dependency list is used for generating a special manifest file for the consumer of these modules. I say special because this is a non-standard java manifest file so there aren't options for things we needed to tuck in there or the ordering we needed etc. After talking to a developer here, what we probably could have done is left a compile time dependency and then where we are building a war, configure the war plugin to exclude any atg-module type artifacts from the packaging. What really strikes me as odd is why wouldn't C show up? A to B shows up, so why wouldn't B to C? from http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Transitive_Dependencies *provided* This is much like compile, but indicates you expect the JDK or a container to provide the dependency at runtime. For example, when building a web application for the Java Enterprise Edition, you would set the dependency on the Servlet API and related Java EE APIs to scope provided because the web container provides those classes. This scope is only available on the compilation and test classpath, and is not transitive. so provided scope dependencies are never transitive, which explains why you see B (the direct dependency) but not C. A depends on B depends on C A to B is provided B to C is provided B shows up C does not. -Original Message- From: Wayne Fay [mailto:wayne...@gmail.com] Sent: Thursday, December 11, 2008 5:49 PM To: Maven Users List Subject: Re: dependency.getDependencies() In that example, I don't believe C will ever show up in a deps tree or report. So I'm not surprised the API does not reveal them. Transitive deps of provided deps are basically your problem. If B to C is compile, do you see any difference in the deps reported? I don't believe so. What is the business case that would indicate this should be supported? This says I will be providing B in my container, but need all of B's deps (which I do not depend on in A directly) included in A -- that makes no sense. Wayne On Thu, Dec 11, 2008 at 1:17 PM, EJ Ciramella ecirame...@upromise.com wrote: That still doesn't return a dependency of a dependency where the last one is of scope provided. A depends on B depends on C A to B is provided B to C is provided B shows up C does not. -Original Message- From: sirly...@gmail.com [mailto:sirly...@gmail.com] On Behalf Of John Stoneham Sent: Thursday, December 11, 2008 1:20 PM To: Maven Users List Subject: Re: dependency.getDependencies() On Thu, Dec 11, 2008 at 9:25 AM, EJ Ciramella ecirame...@upromise.com wrote: is there a way to get ALL dependencies (including transitive ones)? Marking your mojo with @requiresDependencyResolution test ought to resolve all this out for you and populate the artifacts variables on the MavenProject object. - John - 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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Cheers, Stuart
Re: dependency.getDependencies()
Firstly, we've created our own packaging type (atg-module). This packaging type generates a jar and a zip. The zip is what has the scope of provided. This isn't a compile time dependency and we did NOT want the zip showing up in every jar generated where there is a dependency on said zip. So the scope of provided is used. The dependency list is used for generating a special manifest file for the consumer of these modules. I say special because this is a non-standard java manifest file so there aren't options for things we needed to tuck in there or the ordering we needed etc. Seems like the transitive provided dependencies would -have- to be there, on a compile classpath for example. How are you accessing these dependencies again? You shouldn't have to go through this 'pretend it's a compile-time dependency and then exclude it later' rigmarole. Then again I may be showing my lack of experience with provided-scope dependencies. - John - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
