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
