RE: Conflicting Dependency Version Dilemna
Mike Perham wrote on Wednesday, August 09, 2006 8:05 PM: Not exactly. We have a single parent POM per ear and don't share war/ejbs between ears, yes. But you can still do what you want with a dependencyManagement section in the parent to centralize the version numbers and just have each ear POM pull in its required ejbs. Or am I missing something? And what about the EJBs? As long as the EJBs do not use the same parent POM and declare the depednencies explicitly, it is not guaranteed to work. And if you add the same POM to different EARs you might be in conflict. And note, this is not simply hypothetical, we run into this often enough to be annoyed. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Conflicting Dependency Version Dilemna
I like it and I think that's a reasonable request. Throw it in JIRA and maybe Santa will deliver it in 2.1. :-) mike [EMAIL PROTECTED] wrote on 08/09/2006 11:37:39 PM: It could define the version conflict resolution rules such that dependencyManagement version declarations in *my* POMs (defined as the one for this project or the explictly declared parent tree) always win over version declarations that come from explicit or transitive dependencies. That way, I can declare in a single parent POM all my version dependency information for *all* my leaf node projects (webapps in my case, but the same principle applies to any environment where you are creating lots of individual artifacts that share a common set of dependencies) without having to tediously edit all of the leaf POMs individually.
RE: Conflicting Dependency Version Dilemna
Mike Perham wrote on Thursday, August 10, 2006 3:28 PM: I like it and I think that's a reasonable request. Throw it in JIRA and maybe Santa will deliver it in 2.1. :-) This *is* what MNG-1577 is about and it has been postponed since 2.0.1. :-/ mike [EMAIL PROTECTED] wrote on 08/09/2006 11:37:39 PM: It could define the version conflict resolution rules such that dependencyManagement version declarations in *my* POMs (defined as the one for this project or the explictly declared parent tree) always win over version declarations that come from explicit or transitive dependencies. That way, I can declare in a single parent POM all my version dependency information for *all* my leaf node projects (webapps in my case, but the same principle applies to any environment where you are creating lots of individual artifacts that share a common set of dependencies) without having to tediously edit all of the leaf POMs individually. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Conflicting Dependency Version Dilemna
[EMAIL PROTECTED] wrote on 08/10/2006 12:28:36 AM: If I understand your recommendation correctly, you would like me to declare my dependency on version [1.7.0,) instead (meaning version 1.7.0 or any later version). From a QE perspective, that is an untestable assertion -- there is no way to know that some future version of BeanUtils might introduce some incompatible change that makes *my* library no longer work. That is not acceptable to me as the supplier of a library, because it is *me* who is going to suffer the you *said* it would work bug reports. Craig, please don't ruin my fantasy world with your reality. :-) You are right, in a perfect world you could depend on libraries keeping backwards compatability but even then each project can have a different versioning policy and their dependents would have to understand and codify that policy in the version range, e.g., for commons-logging, should the version range be [1.0,1.1) or [1.0,2.0)? This is not realistic. If an end user of my library wants to override my setting, they can (although making them do it in every leaf node is definitely a violation of the don't repeat yourself mantra that M2 seems to really like :-). But I want *my* POMs to advertise what *I* have tested, and not rely on all of my dependencies not to break me with future versions. I wouldn't even want to trust my own modules enough to use ranges like that :-). I like your idea about dependencyManagement able to override transitive versions. To me that's the best idea because you are listing your own versioned bill of materials for your system to test with. This is critical - we have seen numerous instances where versions suddenly devolve due to the addition of a new dependency. That's unacceptable and having a master list of dependency versions in a single place would solve the problem. mike
RE: Conflicting Dependency Version Dilemna
Well, I added my vote and +1 to the issue. That's about all I can do since I shy away from touching the maven core. mike Jörg Schaible [EMAIL PROTECTED] wrote on 08/10/2006 08:42:40 AM: This *is* what MNG-1577 is about and it has been postponed since 2.0.1. :-/
RE: Conflicting Dependency Version Dilemna
Hi Craig, Craig McClanahan wrote on Wednesday, August 09, 2006 6:58 AM: A project[1] that I'm a participant in is a recent convert to Maven2 as a build environment. So far, there's a lot to like. But ... I think I've run into a limitation of the current design related to resolving conflicts in dependency versions. I'm looking for advice on what I can do other than wait for FINR (fixed in next rev) as the Better Builds book implies will be necessary :-). The starting point for my scenario is I wanted to explore whether Commons Logging 1.1 could successfully replace version 1.0.4 in a Shale-created webapp. To see all the gory details, you're probably best off downloading the sources and trying the build yourself. But the bottom line is that the only way I can convince a particular webapp build to use the new version of Commons Logging is to put the explicit dependence on 1.1 directly in the POM for that webapp. This is *not* what I want -- I'd much prefer to inherit the Commons Logging version dependency from the top-level shale POM ( org.apache.shale:shale-parent), or even from the intermediate layer I have as a basis for all the example webapps (org.apache.shale:shale-apps-parent). If you have a depednencyManagement section in your top-level POM and add the dep to your webapp without the version, it will work. Alas, this doesn't work. Any dependency such as MyFaces that declares a dependency on Commons Logging 1.0.4 seems to win, because it is closer on the nearness algorithm described in Section 3.6 of the Better Builds book. Point is, that you *have to* desclare the dep in the webapp, since the algorithm for the nearest version would take another version from one of your dependencies. It would seem to me that the simplest way to deal with this is that inherited dependencies (from a parent POM) should be considered as being at the same level of the dependency graph, just as if they had been explicitly declared. That would always allow a project to establish priority for shared dependencies itself, without having their builds destabilized because inheritance and dependence are both being treated as one step down the graph. Am I missing something? Is there some way to accomplish what I want (with M2 2.0.4) in the mean time, without explicitly declaring this dependency in the leaf node artifact POMs? Vote for it: http://jira.codehaus.org/browse/MNG-1577 - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Conflicting Dependency Version Dilemna
On 8/8/06, Jörg Schaible [EMAIL PROTECTED] wrote: Hi Craig, Hello Jörg Craig McClanahan wrote on Wednesday, August 09, 2006 6:58 AM: A project[1] that I'm a participant in is a recent convert to Maven2 as a build environment. So far, there's a lot to like. But ... I think I've run into a limitation of the current design related to resolving conflicts in dependency versions. I'm looking for advice on what I can do other than wait for FINR (fixed in next rev) as the Better Builds book implies will be necessary :-). The starting point for my scenario is I wanted to explore whether Commons Logging 1.1 could successfully replace version 1.0.4 in a Shale-created webapp. To see all the gory details, you're probably best off downloading the sources and trying the build yourself. But the bottom line is that the only way I can convince a particular webapp build to use the new version of Commons Logging is to put the explicit dependence on 1.1 directly in the POM for that webapp. This is *not* what I want -- I'd much prefer to inherit the Commons Logging version dependency from the top-level shale POM ( org.apache.shale:shale-parent), or even from the intermediate layer I have as a basis for all the example webapps (org.apache.shale:shale-apps-parent). If you have a depednencyManagement section in your top-level POM and add the dep to your webapp without the version, it will work. Agreed ... but the requirement to explicitly do this in every single webapp is not what I want. The whole point of my apps inheriting a parent POM is to get rid of this sort of administrivia. Alas, this doesn't work. Any dependency such as MyFaces that declares a dependency on Commons Logging 1.0.4 seems to win, because it is closer on the nearness algorithm described in Section 3.6 of the Better Builds book. Point is, that you *have to* desclare the dep in the webapp, since the algorithm for the nearest version would take another version from one of your dependencies. Why should I have to declare it in the app, when I've declared it at the parent level? What's the point of transitive dependencies if they do not work the way you want, and there's no way to force them to do so? It would seem to me that the simplest way to deal with this is that inherited dependencies (from a parent POM) should be considered as being at the same level of the dependency graph, just as if they had been explicitly declared. That would always allow a project to establish priority for shared dependencies itself, without having their builds destabilized because inheritance and dependence are both being treated as one step down the graph. Am I missing something? Is there some way to accomplish what I want (with M2 2.0.4) in the mean time, without explicitly declaring this dependency in the leaf node artifact POMs? Vote for it: http://jira.codehaus.org/browse/MNG-1577 Done. - Jörg Craig
Re: Conflicting Dependency Version Dilemna
On 8/8/06, Craig McClanahan [EMAIL PROTECTED] wrote: Why should I have to declare it in the app, when I've declared it at the parent level? What's the point of transitive dependencies if they do not work the way you want, and there's no way to force them to do so? I should have been more clear. It is not that transitive dependencies are bad ... it's that I believe inherited dependencies (including version dependencies described by dependencyManagement sections should *always* override transitive dependencies on the same artifact. Alternatively, it would be reasonable to allow an override of whatever the default behavior is for advanced cases ... but requiring me to define version overrides in leaf nodes, simply because my inheritance hierarchy is deeper than my dependence hierarchy, encourages bad build architecture design behavior -- and isn't part of the point of Maven to eliminate that kind of idiocy? :-) Craig
RE: Conflicting Dependency Version Dilemna
Hi Craig, Craig McClanahan wrote on Wednesday, August 09, 2006 8:46 AM: On 8/8/06, Craig McClanahan [EMAIL PROTECTED] wrote: Why should I have to declare it in the app, when I've declared it at the parent level? What's the point of transitive dependencies if they do not work the way you want, and there's no way to force them to do so? I should have been more clear. It is not that transitive dependencies are bad ... it's that I believe inherited dependencies (including version dependencies described by dependencyManagement sections should *always* override transitive dependencies on the same artifact. This is also my PoV, struggling with the same problems. While the current algorithm works for simple jars, it fails badly for all modules gathering the transitive dependencies: - webapps - ears - all jars with the classpath in the manifest (esp. true for EJBs) Building an ear with two EJBs I have to add a dep for any of the EJBs as well as for the EAR. Otherwise the manifest of the two EJBs might reference the same artifact in different versions and the EAR will contain a third one - leaving me with a complete broken EAR (not to mension that M2 will screw up the classspaths in the manifests for snapshot deps anyway using a multi-module build - at least this one is fixed in 2.0.5: MEJB-18). Alternatively, it would be reasonable to allow an override of whatever the default behavior is for advanced cases ... but requiring me to define version overrides in leaf nodes, simply because my inheritance hierarchy is deeper than my dependence hierarchy, encourages bad build architecture design behavior -- and isn't part of the point of Maven to eliminate that kind of idiocy? :-) I wished MNG-1577 would not have been postponed from version to version ... feel the same about the idiocy part ... - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Conflicting Dependency Version Dilemna
Any comment from the maven devs? This problem seems to be affecting more and more people. Ruel Loehr JBoss QA -Original Message- From: Jörg Schaible [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 09, 2006 1:57 AM To: Maven Users List Subject: RE: Conflicting Dependency Version Dilemna Hi Craig, Craig McClanahan wrote on Wednesday, August 09, 2006 8:46 AM: On 8/8/06, Craig McClanahan [EMAIL PROTECTED] wrote: Why should I have to declare it in the app, when I've declared it at the parent level? What's the point of transitive dependencies if they do not work the way you want, and there's no way to force them to do so? I should have been more clear. It is not that transitive dependencies are bad ... it's that I believe inherited dependencies (including version dependencies described by dependencyManagement sections should *always* override transitive dependencies on the same artifact. This is also my PoV, struggling with the same problems. While the current algorithm works for simple jars, it fails badly for all modules gathering the transitive dependencies: - webapps - ears - all jars with the classpath in the manifest (esp. true for EJBs) Building an ear with two EJBs I have to add a dep for any of the EJBs as well as for the EAR. Otherwise the manifest of the two EJBs might reference the same artifact in different versions and the EAR will contain a third one - leaving me with a complete broken EAR (not to mension that M2 will screw up the classspaths in the manifests for snapshot deps anyway using a multi-module build - at least this one is fixed in 2.0.5: MEJB-18). Alternatively, it would be reasonable to allow an override of whatever the default behavior is for advanced cases ... but requiring me to define version overrides in leaf nodes, simply because my inheritance hierarchy is deeper than my dependence hierarchy, encourages bad build architecture design behavior -- and isn't part of the point of Maven to eliminate that kind of idiocy? :-) I wished MNG-1577 would not have been postponed from version to version ... feel the same about the idiocy part ... - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.10.8/414 - Release Date: 8/9/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.10.8/414 - Release Date: 8/9/2006 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Conflicting Dependency Version Dilemna
We have come up with a pattern that we feel works pretty well to work around this. We split our modules into standard jars and j2ee type archives. The standard jars declare their own deps as normal. The j2ee jars all share a parent which overrides all dependency versions so all the wars/ears are guaranteed to have the same manifest.mf and ear lib/*.jar contents. When we release, standard jars are released one at a time. The j2ee jars are all released at the same time (using one big recursive release). This way we update the parent with the latest versions of all the standard jars and then all the j2ee jars will pick it up. Craig, the other thing to remember is that version ranges are key here also. Your transitive dependency should not be specifying 1.0.4, it should say [1.0,) so that versions are not pushed to its dependents (i.e. your project) like you are seeing. Unfortunately M2 has several bugs wrt version ranges but this is important to solidify for the 2.1 release IMO. The other thing needed is to document a development process for building J2EE artifacts. M2 works pretty well for OSS people writing jars and fat wars but is a pain to deal with for application (EAR) authors trying to package more than one j2ee module. Jörg Schaible [EMAIL PROTECTED] wrote on 08/09/2006 01:56:58 AM: Hi Craig, Craig McClanahan wrote on Wednesday, August 09, 2006 8:46 AM: On 8/8/06, Craig McClanahan [EMAIL PROTECTED] wrote: Why should I have to declare it in the app, when I've declared it at the parent level? What's the point of transitive dependencies if they do not work the way you want, and there's no way to force them to do so? I should have been more clear. It is not that transitive dependencies are bad ... it's that I believe inherited dependencies (including version dependencies described by dependencyManagement sections should *always* override transitive dependencies on the same artifact. This is also my PoV, struggling with the same problems. While the current algorithm works for simple jars, it fails badly for all modules gathering the transitive dependencies: - webapps - ears - all jars with the classpath in the manifest (esp. true for EJBs) Building an ear with two EJBs I have to add a dep for any of the EJBs as well as for the EAR. Otherwise the manifest of the two EJBs might reference the same artifact in different versions and the EAR will contain a third one - leaving me with a complete broken EAR (not to mension that M2 will screw up the classspaths in the manifests for snapshot deps anyway using a multi-module build - at least this one is fixed in 2.0.5: MEJB-18). Alternatively, it would be reasonable to allow an override of whatever the default behavior is for advanced cases ... but requiring me to define version overrides in leaf nodes, simply because my inheritance hierarchy is deeper than my dependence hierarchy, encourages bad build architecture design behavior -- and isn't part of the point of Maven to eliminate that kind of idiocy? :-) I wished MNG-1577 would not have been postponed from version to version ... feel the same about the idiocy part ... - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Conflicting Dependency Version Dilemna
Hi Mike, Mike Perham wrote on Wednesday, August 09, 2006 6:21 PM: We have come up with a pattern that we feel works pretty well to work around this. We split our modules into standard jars and j2ee type archives. The standard jars declare their own deps as normal. The j2ee jars all share a parent which overrides all dependency versions so all the wars/ears are guaranteed to have the same manifest.mf and ear lib/*.jar contents. When we release, standard jars are released one at a time. The j2ee jars are all released at the same time (using one big recursive release). This way we update the parent with the latest versions of all the standard jars and then all the j2ee jars will pick it up. Unfortunately this pattern does only help if you build a single EAR. For multiple EARs (we have so) and a lot of EJBs (not exclusivly referenced), you cannot define the dependencies in a common parent, since then you woud end up with all depednencies of all EJBs in every EAR. So you use a dependencyManagement (we do) and you're left with the already described problem - you cannot force transitive dependencies toi the version defined in the management. [snip] - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Conflicting Dependency Version Dilemna
Not exactly. We have a single parent POM per ear and don't share war/ejbs between ears, yes. But you can still do what you want with a dependencyManagement section in the parent to centralize the version numbers and just have each ear POM pull in its required ejbs. Or am I missing something? mike Jörg Schaible [EMAIL PROTECTED] wrote on 08/09/2006 11:46:10 AM: Unfortunately this pattern does only help if you build a single EAR. For multiple EARs (we have so) and a lot of EJBs (not exclusivly referenced), you cannot define the dependencies in a common parent, since then you woud end up with all depednencies of all EJBs in every EAR. So you use a dependencyManagement (we do) and you're left with the already described problem - you cannot force transitive dependencies toi the version defined in the management.
Re: Conflicting Dependency Version Dilemna
On 8/9/06, Mike Perham [EMAIL PROTECTED] wrote: Not exactly. We have a single parent POM per ear and don't share war/ejbs between ears, yes. But you can still do what you want with a dependencyManagement section in the parent to centralize the version numbers and just have each ear POM pull in its required ejbs. Or am I missing something? Defining dependencyManagement in the parent does not seem to cover all the cases for me. A simplified scenario goes like this: * Parent POM declares a version for artifact A * Child POM declares (or inherits) a dependency on artifact B * Dependency B declares a dependency on artifact A with an explicit, but different, version number. It seems that the two dependencies on artifact A are at the same level (in the terms of the book's section on this) and therefore the behavior is undefined. Indeed, it seems to work for most of the dependencies with version conflicts, but not all of them ... and it is completely unclear to me at this point why the cases are different. mike Craig Jörg Schaible [EMAIL PROTECTED] wrote on 08/09/2006 11:46:10 AM: Unfortunately this pattern does only help if you build a single EAR. For multiple EARs (we have so) and a lot of EJBs (not exclusivly referenced), you cannot define the dependencies in a common parent, since then you woud end up with all depednencies of all EJBs in every EAR. So you use a dependencyManagement (we do) and you're left with the already described problem - you cannot force transitive dependencies toi the version defined in the management.
Re: Conflicting Dependency Version Dilemna
Again, this is because dependency B is not using version ranges but rather forcing a specific version on its downstream dependents. If A requires a different version, it has to declare that dependency in order to override the transitive dependency version from B. There's nothing Maven can do when the POM data is incorrect. You need to exclude it or override it. [EMAIL PROTECTED] wrote on 08/09/2006 01:29:22 PM: Defining dependencyManagement in the parent does not seem to cover all the cases for me. A simplified scenario goes like this: * Parent POM declares a version for artifact A * Child POM declares (or inherits) a dependency on artifact B * Dependency B declares a dependency on artifact A with an explicit, but different, version number. It seems that the two dependencies on artifact A are at the same level (in the terms of the book's section on this) and therefore the behavior is undefined. Indeed, it seems to work for most of the dependencies with version conflicts, but not all of them ... and it is completely unclear to me at this point why the cases are different.
Re: Conflicting Dependency Version Dilemna
On 8/9/06, Mike Perham [EMAIL PROTECTED] wrote: Again, this is because dependency B is not using version ranges but rather forcing a specific version on its downstream dependents. Ah, but dependency B is a third party library ... and the entire transitive dependency tree for Shale (which is pretty small compared to lots of multi-project environments) has at least 100 such dependencies. Seems to me like evangelizing all those folks to set up proper version ranges in their POMs belongs to the Maven team, not to me whose just an (indirect) Joe User for all those packages :-). If A requires a different version, it has to declare that dependency in order to override the transitive dependency version from B. There's nothing Maven can do when the POM data is incorrect. You need to exclude it or override it. Yes, there is something Maven could do -- it could reflect the reality that most POMs don't actually do this, and provide developers a workaround that protects them from instabilities caused by the current rules. It could define the version conflict resolution rules such that dependencyManagement version declarations in *my* POMs (defined as the one for this project or the explictly declared parent tree) always win over version declarations that come from explicit or transitive dependencies. That way, I can declare in a single parent POM all my version dependency information for *all* my leaf node projects (webapps in my case, but the same principle applies to any environment where you are creating lots of individual artifacts that share a common set of dependencies) without having to tediously edit all of the leaf POMs individually. Craig
Re: Conflicting Dependency Version Dilemna
On 8/9/06, Mike Perham [EMAIL PROTECTED] wrote: Again, this is because dependency B is not using version ranges but rather forcing a specific version on its downstream dependents. Thinking about this a little further, there is a QE viewpoint that leads me to believe that declaring a specific version on a dependency is actually the right thing to do. Let's consider a concrete case: the Shale core library (org.apache.shale:shale-core) artifact depends on, among other things, Commons BeanUtils. In the POM for this module, I want to inherit from the parent POM (org.apache.shale:shale-parent) a dependence on a particular version of this library, so that I can update the dependencies of a bunch of other artifacts all at once when I've satisfied myself that it works. Currently, in the parent POM, the version (declared in a dependencyManagement section) of BeanUtils that is requested is, specifically, 1.7.0. This is essentially an assertion that I have tested my library against this specific version, and am satisfied that it works. If I understand your recommendation correctly, you would like me to declare my dependency on version [1.7.0,) instead (meaning version 1.7.0 or any later version). From a QE perspective, that is an untestable assertion -- there is no way to know that some future version of BeanUtils might introduce some incompatible change that makes *my* library no longer work. That is not acceptable to me as the supplier of a library, because it is *me* who is going to suffer the you *said* it would work bug reports. If an end user of my library wants to override my setting, they can (although making them do it in every leaf node is definitely a violation of the don't repeat yourself mantra that M2 seems to really like :-). But I want *my* POMs to advertise what *I* have tested, and not rely on all of my dependencies not to break me with future versions. I wouldn't even want to trust my own modules enough to use ranges like that :-). Craig
Conflicting Dependency Version Dilemna
A project[1] that I'm a participant in is a recent convert to Maven2 as a build environment. So far, there's a lot to like. But ... I think I've run into a limitation of the current design related to resolving conflicts in dependency versions. I'm looking for advice on what I can do other than wait for FINR (fixed in next rev) as the Better Builds book implies will be necessary :-). The starting point for my scenario is I wanted to explore whether Commons Logging 1.1 could successfully replace version 1.0.4 in a Shale-created webapp. To see all the gory details, you're probably best off downloading the sources and trying the build yourself. But the bottom line is that the only way I can convince a particular webapp build to use the new version of Commons Logging is to put the explicit dependence on 1.1 directly in the POM for that webapp. This is *not* what I want -- I'd much prefer to inherit the Commons Logging version dependency from the top-level shale POM ( org.apache.shale:shale-parent), or even from the intermediate layer I have as a basis for all the example webapps (org.apache.shale:shale-apps-parent). Alas, this doesn't work. Any dependency such as MyFaces that declares a dependency on Commons Logging 1.0.4 seems to win, because it is closer on the nearness algorithm described in Section 3.6 of the Better Builds book. It would seem to me that the simplest way to deal with this is that inherited dependencies (from a parent POM) should be considered as being at the same level of the dependency graph, just as if they had been explicitly declared. That would always allow a project to establish priority for shared dependencies itself, without having their builds destabilized because inheritance and dependence are both being treated as one step down the graph. Am I missing something? Is there some way to accomplish what I want (with M2 2.0.4) in the mean time, without explicitly declaring this dependency in the leaf node artifact POMs? Craig McClanahan [1] http://shale.apache.org/
