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 <[email protected]> > > 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 <[email protected]> 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: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > > > -- > 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: [email protected] > For additional commands, e-mail: [email protected] > >
