Re: Question about transitive dependencies
Say you depend on a ClassA from dependency A. Class A extends ClassB from dependency B. When you compile against ClassA you will also need ClassB even if you do not access it directly. That is the reason B is automatically put on your compile classpath if you depend on A. There are several ways to avoid that a dependency is passed transitively. You can change the scope to provided or set set true in the POM of the dependency . As far as I understand it, both have the same effect on the compile time classpath. If you want to exclude a transitive dependency in the POM that declares the dependency, you will need to use the exclusion mechanism. More information can be found in: * http://maven.apache.org/pom.html * http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html Tom On 12/1/06, Heck, Joe <[EMAIL PROTECTED]> wrote: I couldn't answer this for one of the devs in our team, so I thought I'd push the question to you all for any feedback you could provide. Any insight would be great... -joe -- -- Can anyone explain to me why transitive dependencies (even of dependencies that are specified as "compile" scope in your project) are put on the compile time classpath? It seems to me that transitive dependencies on the compile time classpath are useless at best, since you shouldn't need them to build the project. If you have a transitive dependency that you actually do need for your project to build, doesn't that pretty much by definition mean that it should be a direct dependency of your project instead? For example say that I have a project in which I specify the artifact "Foo" as a dependency, and foo has a dependency on project "Bar". If my project doesn't have any direct dependency on Bar then there's no reason I need Bar to be in my classpath when I build, but having it there should be benign. But if my project does depend on Bar then just specifying Foo as a dependency could cause my project to build fine. It might not even be obvious that I'm getting my Bar dependency through Foo. This situation could potentially lead to bugs in my build or in my code if the Foo project decides to upgrade to Bar 2.0 and my code isn't compatible with it or if Foo drops its dependency on Bar altogether. So, is there a reason I'm missing for why you'd ever want to put a transitive dependency on your compile time classpath? Is there a way to cause a project to not put transitive dependencies on its compile time classpath but to keep them on the runtime classpath? - 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: Question about transitive dependencies
On 12/1/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: On 12/1/06, Alexander Sack <[EMAIL PROTECTED]> wrote: > > And in fact, one can actually remove the transitive dependencies that are > unwanted during the build classpath by declaring them in the POM as > "provided." I believe that fits his scenario where he is building against > a > library that has a transitive dependency that he does not want on his > build > classpath for whatever reason (packaging, etc.). My understanding is the "provided" is essentially the opposite of "runtime" ... it leaves the dependency on the compile classpath but does not include it in the output. Whereas, "runtime" leaves it off the compile classpath but does include it in the output. Craig, yea, your right. My apologies. I'm using provided in one project as a way to avoid output not build scope since as the original poster stated, transitive dependencies are relatively harmless. My issue was in fact that transitive dependencies were being packaged and I wanted to remove them. Again, sorry for the confusion and thanks for the correction! :D -aps -- "What lies behind us and what lies in front of us is of little concern to what lies within us." -Ralph Waldo Emerson
Re: Question about transitive dependencies
On 12/1/06, Alexander Sack <[EMAIL PROTECTED]> wrote: And in fact, one can actually remove the transitive dependencies that are unwanted during the build classpath by declaring them in the POM as "provided." I believe that fits his scenario where he is building against a library that has a transitive dependency that he does not want on his build classpath for whatever reason (packaging, etc.). My understanding is the "provided" is essentially the opposite of "runtime" ... it leaves the dependency on the compile classpath but does not include it in the output. Whereas, "runtime" leaves it off the compile classpath but does include it in the output. In a web app, I'll want to declare the servlet API as a "provided" API so that I can use it in my own code. The servlet container will make it available to me at runtime, so I don't want to include it in the war. But, if I'm also using something like the MyFaces JSF implementation, which has both an API jar and an implementation JAR, I'll want the API jar declared as "compile" scope (so its on the classpath and included in the war), but the impl JAR declared "runtime" scope (so it is *not* possible for me to accidentally compile against classes in the MyFaces implementation, where I should be programming solely to JSF APIs), but is included so that the runtime app will work. Craig -aps Craig On 12/1/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: > > On 12/1/06, Alexander Sack <[EMAIL PROTECTED]> wrote: > > > > This maybe an artifact of the fact that many plugins use the classpath > for > > runtime constraints as well. > > > It's also possible to avoid this behavior, by declaring a scope of > > on the dependency. That way, the module is *not* included on the compile > time classpath (unless it's declared with compile scope by someone else > you > depend on), but *is* included for runtime (for example, in a webapp it'd > be > included in WEB-INF/lib). > > -aps > > > Craig > > -- "What lies behind us and what lies in front of us is of little concern to what lies within us." -Ralph Waldo Emerson
Re: Question about transitive dependencies
And in fact, one can actually remove the transitive dependencies that are unwanted during the build classpath by declaring them in the POM as "provided." I believe that fits his scenario where he is building against a library that has a transitive dependency that he does not want on his build classpath for whatever reason (packaging, etc.). -aps On 12/1/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: On 12/1/06, Alexander Sack <[EMAIL PROTECTED]> wrote: > > This maybe an artifact of the fact that many plugins use the classpath for > runtime constraints as well. It's also possible to avoid this behavior, by declaring a scope of on the dependency. That way, the module is *not* included on the compile time classpath (unless it's declared with compile scope by someone else you depend on), but *is* included for runtime (for example, in a webapp it'd be included in WEB-INF/lib). -aps Craig -- "What lies behind us and what lies in front of us is of little concern to what lies within us." -Ralph Waldo Emerson
Re: Question about transitive dependencies
On 12/1/06, Alexander Sack <[EMAIL PROTECTED]> wrote: This maybe an artifact of the fact that many plugins use the classpath for runtime constraints as well. It's also possible to avoid this behavior, by declaring a scope of on the dependency. That way, the module is *not* included on the compile time classpath (unless it's declared with compile scope by someone else you depend on), but *is* included for runtime (for example, in a webapp it'd be included in WEB-INF/lib). -aps Craig
Re: Question about transitive dependencies
This maybe an artifact of the fact that many plugins use the classpath for runtime constraints as well. -aps On 12/1/06, Heck, Joe <[EMAIL PROTECTED]> wrote: I couldn't answer this for one of the devs in our team, so I thought I'd push the question to you all for any feedback you could provide. Any insight would be great... -joe -- -- Can anyone explain to me why transitive dependencies (even of dependencies that are specified as "compile" scope in your project) are put on the compile time classpath? It seems to me that transitive dependencies on the compile time classpath are useless at best, since you shouldn't need them to build the project. If you have a transitive dependency that you actually do need for your project to build, doesn't that pretty much by definition mean that it should be a direct dependency of your project instead? For example say that I have a project in which I specify the artifact "Foo" as a dependency, and foo has a dependency on project "Bar". If my project doesn't have any direct dependency on Bar then there's no reason I need Bar to be in my classpath when I build, but having it there should be benign. But if my project does depend on Bar then just specifying Foo as a dependency could cause my project to build fine. It might not even be obvious that I'm getting my Bar dependency through Foo. This situation could potentially lead to bugs in my build or in my code if the Foo project decides to upgrade to Bar 2.0 and my code isn't compatible with it or if Foo drops its dependency on Bar altogether. So, is there a reason I'm missing for why you'd ever want to put a transitive dependency on your compile time classpath? Is there a way to cause a project to not put transitive dependencies on its compile time classpath but to keep them on the runtime classpath? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "What lies behind us and what lies in front of us is of little concern to what lies within us." -Ralph Waldo Emerson
Question about transitive dependencies
I couldn't answer this for one of the devs in our team, so I thought I'd push the question to you all for any feedback you could provide. Any insight would be great... -joe -- -- Can anyone explain to me why transitive dependencies (even of dependencies that are specified as "compile" scope in your project) are put on the compile time classpath? It seems to me that transitive dependencies on the compile time classpath are useless at best, since you shouldn't need them to build the project. If you have a transitive dependency that you actually do need for your project to build, doesn't that pretty much by definition mean that it should be a direct dependency of your project instead? For example say that I have a project in which I specify the artifact "Foo" as a dependency, and foo has a dependency on project "Bar". If my project doesn't have any direct dependency on Bar then there's no reason I need Bar to be in my classpath when I build, but having it there should be benign. But if my project does depend on Bar then just specifying Foo as a dependency could cause my project to build fine. It might not even be obvious that I'm getting my Bar dependency through Foo. This situation could potentially lead to bugs in my build or in my code if the Foo project decides to upgrade to Bar 2.0 and my code isn't compatible with it or if Foo drops its dependency on Bar altogether. So, is there a reason I'm missing for why you'd ever want to put a transitive dependency on your compile time classpath? Is there a way to cause a project to not put transitive dependencies on its compile time classpath but to keep them on the runtime classpath? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
