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]
