Stoyan brought me back to this question, and I think we have to reevaluate what we have said earlier. We all are biased on this topic. Sometimes we like it if transitive dependencies would be included, sometimes not. :-)
Our Position So Far A transitive dependency is a dependency of your dependency; if you reference a class from it, it becomes YOUR DIRECT dependency, and hence should be declared in YOUR pom. Even if I like this sentence (because it looks smart and theroetically right) there might be NO VALUE in it. Our Arguments Beyond theory i can find two arguments for this position: 1) You should not reference classes or functionality from others' dependency, because they are out of your control? But, this is not really correct. The sub dependencies are fixed per version of your dependency; so they are in your control. Subdependencies can change with new versions, but so can classes in your direct dependency. 2) You shouldn't encourage yourself and your developers to directly use functionality from transitive dependencies (which you would do if you automatically add them to project references in VS) That seems to be a real issue on the first glance - but just we do not properly support dependency scopes. But reread the 'Dependency Scope'-Section here: http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html Isn't the scope 'runtime' exactly what you are looking for then? It would be included on test runs and runtime, but not on compile. dotnet-executable, dotnet-archive (not implemented yet!), nar and asp could automatically resolve these for runtime. Any more? Suggestion I did not, but now i do agree with Stoyan: we should make NPanday expand transitive dependencies of scope 'compile' in normal projects, and of scope 'runtime' in executables and web projects. Maybe we can tweak the UI to show extra information on the References? Grey out transitive ones, show the scope? And we should not replicate this logic in NPanday, but instead rely on Maven Java code to resolve dependencies - either through CLI or IKVM. What do you think? _ Lars Can you think of ANY EXAMPLE, where you would have a compile Am 05.04.2011 um 18:57 schrieb Lars Corneliussen: > Hi, > > A transitive dependency is a dependeny of your dependency. > > If you reference a class of that "transitive" dependency, it is not a > dependency of your dependency anymore. It's now also your direct dependency > and hence SHOULD be declared in the POM. > > _ > Lars > > Am 05.04.11 18:32, schrieb Brett Porter: >> You're correct, and I think it is behaving as you expect. >> >> What I'm trying to be clear on (which is sometimes hard without pictures): >> >> Let's say B depends on C. Let's say your current project's source code uses >> classes from all of A, B and C. >> >> You should declare all 3 dependencies, because you need to compile against >> them. You shouldn't rely on not declaring C because B will bring it in - >> because B might later change not to, or use a different version. >> >> Now, if you just use A, B - you only compile against A, B, but you run >> against A, B, C (because B needs C to run). >> >> The problem in Java is if C contains an abstract class implemented in B, you >> need to compile against C, even if you only use classes from A and B. >> >> :) >> >> On 06/04/2011, at 2:11 AM, Khai Do wrote: >> >>> Hi Brett. Maybe I don't understand. What do you mean when you say ".NET is >>> not burdened the same way"? As a best practice (for java projects) I >>> follow the pattern of only referencing top level modules and letting maven >>> resolve all the transitive dependencies for me on compile. I believe this >>> is the definition of dependency management. It seems like your suggesting >>> that .NET is not build the same way and I shouldn't follow this pattern for >>> npanday builds? Wouldn't this break maven's dependency management feature? >>> -Khai >>> >> -- >> Brett Porter >> [email protected] >> http://brettporter.wordpress.com/ >> http://au.linkedin.com/in/brettporter >> >> >> >> >
