Re: depMgt (mng-1577 again....)
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]
Re: depMgt (mng-1577 again....)
Ralph Goers wrote: Kenney Westerhof wrote: 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? Actually, from the discussions that occurred while this was being developed what you are describing is exactly what was intended. 1. Before the fix depMgt only provided defaults for direct artifacts and had no impact on transitive dependencies. 2. The first version of my path overrode both direct and transitive dependencies. Objections were raised to it doing that so it was modified to its current behavior. 3. This is OK because you have control over your depMgt and your direct dependencies. You can choose (or not) to specify versions in the dependencies. You have no such control over transitive dependencies. 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, This doesn't work. It was essentially how things worked in 2.0.6. You will never have a clue what you are going to get as you have no way to control what transitive dependencies bring in, except by artificially declaring them in projects that don't really need them. OR we let depMgt override both local and transitive deps. See above. I think you're misreading (or I am). What's the problem with depMgt ALWAYS overriding? At least that's consistent. -- Kenney Or, is this the intended behaviour after all? Yes Ralph - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: depMgt (mng-1577 again....)
Jörg Schaible wrote: 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? 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.. 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. Yeah, that's fixed since 2.0.5; when 2 deps at the same depth have different versions, a 'random' one is chosen, depending on the hash or set implementation of your JRE. 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. 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. -- Kenney - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: depMgt (mng-1577 again....)
Brian E. Fox wrote: I think you're questioning if you have this: foo com 1 foo com 2 Should you get 1 or 2? Without the direct dependency, you should get 1 if pulled in transitively. With the direct dependency as shown, you should get 2. I think you always need to maintain the ability to override at a child level if needed. No i'm not questioning that. With maven 2.0.5 and before you'd get 1, with 2.0.6 and later you get 2. I'm questioning the dubious meaning of depMgt. you cannot tell wheter it was created to declare overrides for transitive deps, or wheter it was meant as defaults for direct deps. Either way, as soon as a direct dep is added resp. removed in any child module at any depth, the meaning changes and you get a different version. It's inconsistent, and you cannot tell what a dependencyManagement section does (which version of the dep you're goanna get) without looking at the entire module tree. This has some consequences if the depMgt was inherited and sibling dependencies are used since they would ignore the declared direct dependency in some cases. Is that why you think the behavior is wrong? Exactly; they'd honor the direct dep, but if it's absent and there's a transitive one, that one may win, depending on how far the dep is away from a module. P depMgt for E at 1.0 | + A dep on B, dep on C + B dep on C, dep on E 3.0 + C dep on E version 2.0 + D dep on E, no version + X dep on A, B, C, D D would get E 1.0 C would get E 2.0 B would get E 3.0 A would get either 3.0 or 2.0 ( A -> B -> E 3.0 A -> C -> E 2.0 ) X would get: X -> A -> B -> E 3.0 X -> A -> C -> E 2.0 X -> B -> E 3.0 X -> B -> C -> E 2.0 X -> C -> E 2.0 X -> D -> E 1.0 Shortest paths are through B, C and D, so can get either 1.0, 2.0 or 3.0. Which is it? According to my tests on 3 simple projects, since E is not a direct dep from X, the depMgt overrides kick in and I should get E 1.0 on X, right? It's way to confusing this way and totally not straightforward. An element can change semantics by something far away; that's not descriptive or deterministic or repeatable. If we need 2 different ways to handle versions: 1) declare defaults for direct dependencies 2) declare overrides for transitive ones we need a new element, like 'transitiveDependencyManagement'. This is something I hope we won't support in 2.1... -- Kenney -Original Message- From: Kenney Westerhof [mailto:[EMAIL PROTECTED] Sent: Saturday, June 16, 2007 7:06 AM To: Maven Developers List Subject: depMgt (mng-1577 again) 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. 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? 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? -- Kenney - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: depMgt (mng-1577 again....)
Kenney Westerhof wrote: 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? Actually, from the discussions that occurred while this was being developed what you are describing is exactly what was intended. 1. Before the fix depMgt only provided defaults for direct artifacts and had no impact on transitive dependencies. 2. The first version of my path overrode both direct and transitive dependencies. Objections were raised to it doing that so it was modified to its current behavior. 3. This is OK because you have control over your depMgt and your direct dependencies. You can choose (or not) to specify versions in the dependencies. You have no such control over transitive dependencies. 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, This doesn't work. It was essentially how things worked in 2.0.6. You will never have a clue what you are going to get as you have no way to control what transitive dependencies bring in, except by artificially declaring them in projects that don't really need them. OR we let depMgt override both local and transitive deps. See above. Or, is this the intended behaviour after all? Yes Ralph - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: depMgt (mng-1577 again....)
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]
RE: depMgt (mng-1577 again....)
I think you're questioning if you have this: foo com 1 foo com 2 Should you get 1 or 2? Without the direct dependency, you should get 1 if pulled in transitively. With the direct dependency as shown, you should get 2. I think you always need to maintain the ability to override at a child level if needed. This has some consequences if the depMgt was inherited and sibling dependencies are used since they would ignore the declared direct dependency in some cases. Is that why you think the behavior is wrong? -Original Message- From: Kenney Westerhof [mailto:[EMAIL PROTECTED] Sent: Saturday, June 16, 2007 7:06 AM To: Maven Developers List Subject: depMgt (mng-1577 again) 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. 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? 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? -- Kenney - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
