Kenney Westerhof wrote: > Hi, > > Just did some test wrt MNG-2340 (using maven 2.0.7 and 2.0.6), and this is > what I found: > > P with dependencyManagement for lucene 1.3 > | > + my-dep with dependency on lucene 1.4.3 > + my-app with dependency on my-dep > > (I modified the attached project locally; rename my-app to my-dep and add > my-app with a dep on my-dep). > > When building my-dep, after installing P, I get lucene 1.4.3, so depMgt is > used for DEFAULTS for direct dependencies. > > When building my-app, after installing P and my-dep, I get lucene 1.3. So > depMgt is used as OVERRIDE for transitive dependencies.
Yes. > When I add a dep on lucene without a version in my-app, I get 1.3 aswell. > > When I add a dep on lucene 1.4.2 in my-app I get lucene 1.4.2. > > (luckily this also happens when building from the reactor). > > > This is one of the many possible implementations I described in > http://docs.codehaus.org/display/MAVEN/Maven+2.1+Artifact+Resolution+Specification, > and it's one that I don't think we should support. > > 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? Every EJB has all its deps (transitive or direct) in the manifest as classpath entry. Now try to build an EAR that consists of ~10 EJBs ... this is a whole nightmare, if you cannot override the transitive deps. And the EJB will simply fail if the EAR is deployed and not all of those EJBs use the deps in the same version. 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. Even worse, the transitive deps can change simply by adding a complete unrelated dep in your component. All because the sequence the deps are processed seems to be an iterator over a hash map. We had cases, were adding a *unrelated* dep caused the compilation of an project to fail, since suddenly a transitive dep was resolved in a different version. > 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. - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
