I've been using the m2eclipse dependency hierarchy view, as well. That helped me identify the extra piece I needed to include.
But if I must do manual dependency analysis every time I update a third party jar -- just in case it now incurs a new dependency for me -- then what value are transitive dependencies in Maven at all? Regards, Brian. Stephen Connolly-2 wrote: > > have a look at dependency:analyze > > it will tell you what you are depending on in-directly and you can then > add > those indirect dependencies to your pom > > 2009/3/28 Trinition <trin+nabble....@trinition.org> > >> >> The problem I have is that I don't necesssarily know what the >> dependencies >> need to be. If I pull in thidparty.jar so I can use one of the classes >> in >> it, how do I know if one of the classes actually extends someone else's >> class in another jar? And if the next release of thirdparty.jar changes >> their internal implementations, I have to revisit this again. >> >> I thought this was the point of having transitive dependency support in >> Maven. If this isn't the reason, what is? >> >> Regards, >> Brian. >> >> >> Stephen Connolly-2 wrote: >> > >> > if your module requires the dependency to complie then it is a >> > dependency of your module >> > >> > what you describe as a "work around" is actually what you are supposed >> to >> > do >> > >> > the real issue is that compile is transitive. compile needs to be >> > transitive as a runtime dependency but should not be a transitive >> > compile dependency in order to force you to list all your dependencies >> > in your pom >> > >> > in short, if your module needs the dependency to compile, you should >> > add it as a dependency and not rely on it being pulled in as a >> > transitive dependency of anothe dependency of yours >> > On 27/03/2009, Trinition <trin+nabble....@trinition.org> wrote: >> >> >> >> I'm confused about why transitive provided dependencies shouldn't be >> >> included >> >> at compile time. >> >> >> >> I have a project, "myapp-web", which defines a custom Servlet, >> MyServlet. >> >> MyServlet extends a BaseServlet from "framework". BaseServlet extends >> a >> >> Servlet class from "thirdparty", ThirdPartyServlet. ThirdPartyServlet >> in >> >> turn implements the third party's CacheableServlet interface among >> other >> >> things. >> >> >> >> myapp-web: MyServlet >> >> framework: BaseServlet >> >> thirdparty: ThidrdPartyServlet, CacheableServlet, etc. >> >> >> >> So myapp's pom declares a compile-time dependency on framework, and >> >> framework declares a provided dependency on thirdparty. This is >> because >> >> the >> >> thirdparty jar is available at runtime in my container, thus I don't >> want >> >> to >> >> ever include it transitively for packaging. >> >> >> >> So when myapp-web compiles, it needs the definition of >> BaseServlet.class >> >> which it finds in its compile time dependency of "framework". >> However, >> >> it >> >> seems to not know about the definitions of BaseServelt's parent class >> >> (MyServlet's grandparent class), ThirdPartyServlet. I get >> compile-time >> >> errors like these: >> >> >> >> MyServlet.java:[199,20] cannot find symbol >> >> symbol : variable this >> >> location: class com.myapp.MyServlet >> >> >> >> MyServlet.java:[201,24] cannot find symbol >> >> symbol : variable super >> >> location: class com.myapp.MyServlet >> >> >> >> Because MyServlet extends BaseServlet which extends ThirdPartyServlet, >> >> doesn't the compile NEED to know about all classes in the hierarchy in >> >> order >> >> to compile? Thus, I would think anything that was available at >> compile >> >> time >> >> during the building of BaseServlet COULD BE a compile-time dependency >> to >> >> dependents of "framework" (such as "myapp-web"). >> >> >> >> So why does Maven NOT include provided dependencies transitively at >> >> compile >> >> time? >> >> >> >> This is presently blocking me. My workaround is to explicitly add >> >> "thirdparty" as a provided dependency to "myapp-web" so that the >> >> ThirdPartyServlet and CacheableServlet definitions will be available >> at >> >> compile time. But this is the very thing that transitive dependencies >> >> solves for COMPILE dependencies (which are really COMPILED and >> PACKAGED). >> >> Why not solve it for TRANSITIVE dependencies (whcich are COMPILED but >> NOT >> >> PACKAGED). >> >> -- >> >> View this message in context: >> >> >> http://www.nabble.com/Grandparent-classes-not-found-at-compile-time-tp22733894p22733894.html >> >> Sent from the Maven - Users mailing list archive at Nabble.com. >> >> >> >> >> >> --------------------------------------------------------------------- >> >> 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 >> > >> > >> > >> >> -- >> View this message in context: >> http://www.nabble.com/Grandparent-classes-not-found-at-compile-time-tp22733894p22759625.html >> Sent from the Maven - Users mailing list archive at Nabble.com. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> > > -- View this message in context: http://www.nabble.com/Grandparent-classes-not-found-at-compile-time-tp22733894p22784945.html Sent from the Maven - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
