Kenney Westerhof wrote: [snip]
>>> The meaning of depMgt is different, applied to either local deps or >>> transitive deps, and it's not consistent. >>> >>> This somewhat describes the situation: >>> - depMgt for artifact X is used to provide defaults for direct >>> dependencies of artifact X, >>> and for overrides of transitive dependencies on X, >>> unless there's also a direct dependency on X in which case the direct >>> dependency is used. >>> >>> >>> I'm sure this is not intended, so what should the intended behaviour be? >> >> No, this was *exacltly* the intended behaviour! Do you know, how often we >> have to add direct deps simply because depMgmt did not override the >> transitive deps? > > Ok, so you wanna be able to override transitive deps, that's fine; a good > usecase. > > [snip] > >> Everytime a third-party dep is upgraded, you have to check all its >> dependencies again. You never know in your EJB if the local deps are >> there to override transitive one or if they are really necessary. > > You have to do that too now, for your modules. If one module defines a > dependency with a version different from your depMgt, you won't get the > version specified in depMgt. You're shifting the problem with this > solution.. Yes, but did I tell ya already, that we don't define the versions in our direct deps? ;-) [snip] >>> Either we keep the 'child overrides' that's globally present in all of >>> maven, so that dependencies can override depMgt, as is the case now, and >>> also apply that to transitive deps, OR we let depMgt override both local >>> and transitive deps. >>> >>> Or, is this the intended behaviour after all? >> >> Yes, it is. Definitely for me and I reported 1577. Thanks again for those >> guys who implemented it. > > I'm ok with the fact that depMgt overrides versions. I just expected it to > do just that, and not be a 'default' or 'override' depending on how many > resolution nodes away a dependency was. > Say project A extends P where P declares depmgt for B 1.0, > and A needs B 2.0. Since dependency versions are 'hints' anyway, they > shouldn't be used to override something that's designed to override; just > use the override mechanism already there - the depMgt. Inheritance will > make sure that any depMgt section in A overrides depMgt sections in P, so > you still can have what you want. I don't grok your description here fully, therefore I reference the example you gave Brian. Just imaging A, B, C, D are EJBs and X is an EAR. You realize you're in trouble now? You cannot build a valid X.ear at all, all EJBs refer a different version of E in their manifest. Therefore none of the EJBs should declare a direct dep with a version. You may argue that B may now no longer compile or run, since it has to use an old version of E, but that's exactly what I want ... get a hint very early in the process, that you have a severe version conflict and you have to do something in your code! > If I see a depMgt section now, I have no clue what the intent was - > defaults or overrides? I'd have to scan the entire module tree to find > out; and even then, it could be that for a subset of modules it was meant > as an override, and for another subset as defaults. The project as a whole > will have problems since there are 2 versions for a given artifact, and > depending on the depth, one of them will be chosen. This is very bad imho. What is the distinction between default and override really good for? In the end my EAR will contain exactly *one* version of the artifact and I really prefer that the unit tests for all my submodules and (EJBs as well as JARs) already use that one ... for obvious reasons. Bitten before! - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
