agreed. Am 09.11.2011 um 23:22 schrieb Stoyan Damov:
> Just to make it a bit clearer what currently doesn't work wrt transitive > dependenciesŠ > > Maven surely works. NPanday's Addin doesn't - if I add an artifact as a > dependency to my project, and it's got transitive dependencies, the Addin > wouldn't care. It'll just download (itself) the requested artifact and > reference it. > > Without having properly working transitive dependencies, there's no point > in discussing how to convert NuGet's official repo into a maven one (which > should be the very next task once 1.4.X works and is out) because there > are just a few useful NuGet packages *without* transitive dependencies. > > > Cheers > > On 11/9/11 11:01 PM, "Stoyan Damov" <[email protected]> wrote: > >> Hi, >> >> First and foremost, NPanday needs to become useful, otherwise it's just >> going to be a really cool project which brings maven's power to nobody. >> Not that I want to threaten :) but NuGet is on a feature spree and is >> useful to some extent to many developers (last time I downloaded the >> entire repo from Microsoft I got some ~4K packages). >> >> In order for NPanday to be useful, it doesn't need much. It just needs to: >> 1. Respect scopes and >> 2. Start using maven to do the job (as Lars pointed out) instead of >> "resolving" artifacts from the Addin's code (the code is, ahem, and >> doesn't really work). >> >> My 2 st. >> >> Stoyan >> >> On 11/9/11 8:04 PM, "Lars Corneliussen" <[email protected]> wrote: >> >>> 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-me >>> c >>> hanism.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 >>>>> >>>>> >>>>> >>>>> >>>> >>> >> >> > >
