Re: Pom changes
If they update to new versions of the thing with the pom. At least for polemic purposes, imagining a world in which the decision to make use of a new pom feature has the effect of forcing these sticks-in-the-mud to stick to old versions. Let me be more specific about why I don't like the alternative of forbidding change. Coming up with counter-intuitive syntax that happens to sneak past (some) old tools will cause maven to become less and less understandable. We get see plenty of criticism already that poms are hard to edit and maven is hard to understand. Telling people to edit and maintain two poms is also likely to lead to widespread derision. Here's another thought experiment in design. This may merely be me recapitulating Steven's idea. Say that for Maven 3.1 we wanted to fix this issue once and for all. So, we make maven 3.1 default to reading pom5.xml. (5 for the model version). If there isn't one of those, it goes looking for pom.xml. deploy:deploy creates pom.xml from pom5.xml, and deploys that too. (Artifact is 'pom5'.) Now, ancient tools find what they can use in the place they expect to use it, and users create and maintain a single file with a coherently-designed syntax. Further, in designing that syntax, we could adopt the policy I stated at the top of this thread, so we'd never have to do this again. I recommend reading the html5 group's thoughts on extensions and compatibility. On Wed, Jun 29, 2011 at 1:39 AM, Milos Kleint mkle...@gmail.com wrote: On Wed, Jun 29, 2011 at 1:02 AM, Benson Margulies bimargul...@gmail.com wrote: But why do 2.0.10 users need to build against brand-spanking-new poms? And, if they do, could we give them a downconversion tool? the new poms will arrive to central for everyone to use.. Milos On Tue, Jun 28, 2011 at 6:47 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: maven 2.0.10 is still widely used. and convincing enterprises to upgrade is tricky... even our own model parsing is not forgiving if i recall correctly... so far as 3.0.x too - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 28 Jun 2011 23:31, Benson Margulies bimargul...@gmail.com wrote: This is a new thread for the topic I accidentally started with Steven. I'm fairly new around here, so please try to forgive me for (re)stating the obvious. There is an ecosystem of tools that parse poms. They don't use any library we give them, they just parse them. We want old tools to handle new poms without crashing. We'd like those tools to be able to distinguish legitimate extensions from goofs, since some of them are trying to support authoring. This is hard. Retroactively, it may be impossible. However, we do have XML Schema to help us. If tools validate against the schema, they know when a POM is, in fact, valid for its declared model. Thus, any elements that the tool does not recognize are proved to be 'messengers from the future'. I personally think that it is madness to start telling people, 'well, yes, we've extended the expressiveness of the pom, but you have to add special off-to-the-side files to use the new elements.' So, one option we could adopt is to start a propaganda campaign now: Do you parse poms? Do you tolerate new elements? If not, better fix your code now, because in a few months they will be arriving. After all, in theory, some existing tool could barf on new scopes or any other supposedly compatible change we make. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Pom changes
On 29 June 2011 12:20, Benson Margulies bimargul...@gmail.com wrote: If they update to new versions of the thing with the pom. At least for polemic purposes, imagining a world in which the decision to make use of a new pom feature has the effect of forcing these sticks-in-the-mud to stick to old versions. Let me be more specific about why I don't like the alternative of forbidding change. Coming up with counter-intuitive syntax that happens to sneak past (some) old tools will cause maven to become less and less understandable. We get see plenty of criticism already that poms are hard to edit and maven is hard to understand. Telling people to edit and maintain two poms is also likely to lead to widespread derision. Here's another thought experiment in design. This may merely be me recapitulating Steven's idea. Say that for Maven 3.1 we wanted to fix this issue once and for all. So, we make maven 3.1 default to reading pom5.xml. (5 for the model version). If there isn't one of those, it goes looking for pom.xml. deploy:deploy creates pom.xml from pom5.xml, and deploys that too. (Artifact is 'pom5'.) Now, ancient tools find what they can use in the place they expect to use it, and users create and maintain a single file with a coherently-designed syntax. Further, in designing that syntax, we could adopt the policy I stated at the top of this thread, so we'd never have to do this again. I recommend reading the html5 group's thoughts on extensions and compatibility. That is my idea (that I developed in discussions with brian fox and others... so not entirely my idea) On Wed, Jun 29, 2011 at 1:39 AM, Milos Kleint mkle...@gmail.com wrote: On Wed, Jun 29, 2011 at 1:02 AM, Benson Margulies bimargul...@gmail.com wrote: But why do 2.0.10 users need to build against brand-spanking-new poms? And, if they do, could we give them a downconversion tool? the new poms will arrive to central for everyone to use.. Milos On Tue, Jun 28, 2011 at 6:47 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: maven 2.0.10 is still widely used. and convincing enterprises to upgrade is tricky... even our own model parsing is not forgiving if i recall correctly... so far as 3.0.x too - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 28 Jun 2011 23:31, Benson Margulies bimargul...@gmail.com wrote: This is a new thread for the topic I accidentally started with Steven. I'm fairly new around here, so please try to forgive me for (re)stating the obvious. There is an ecosystem of tools that parse poms. They don't use any library we give them, they just parse them. We want old tools to handle new poms without crashing. We'd like those tools to be able to distinguish legitimate extensions from goofs, since some of them are trying to support authoring. This is hard. Retroactively, it may be impossible. However, we do have XML Schema to help us. If tools validate against the schema, they know when a POM is, in fact, valid for its declared model. Thus, any elements that the tool does not recognize are proved to be 'messengers from the future'. I personally think that it is madness to start telling people, 'well, yes, we've extended the expressiveness of the pom, but you have to add special off-to-the-side files to use the new elements.' So, one option we could adopt is to start a propaganda campaign now: Do you parse poms? Do you tolerate new elements? If not, better fix your code now, because in a few months they will be arriving. After all, in theory, some existing tool could barf on new scopes or any other supposedly compatible change we make. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Pom changes
Telling people to edit and maintain two poms is also likely to lead to widespread derision. Here's another thought experiment in design. This may merely be me recapitulating Steven's idea. Say that for Maven 3.1 we wanted to fix this issue once and for all. So, we make maven 3.1 default to reading pom5.xml. (5 for the model version). If there isn't one of those, it goes looking for pom.xml. deploy:deploy creates pom.xml from pom5.xml, and deploys that too. (Artifact is 'pom5'.) That is my idea (that I developed in discussions with brian fox and others... so not entirely my idea) Sometimes I don't really understand something until I can rewrite it coherently. I hope my disclaimer was sufficient. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Pom changes
If tools validate against the schema, they know when a POM is, in fact, valid for its declared model. Thus, any elements that the tool does not recognize are proved to be 'messengers from the future'. It would help enormously if 'messengers from the future' used an appropriate XML namespace so that they could be discarded by clients that don't understand them. It always surprised me that the pom files never allowed the plugins to extend the meaning. For example, using some plugins I'm forced to maintain a separate config file, referencing much of the same information by coordinate. It'd be nice to be able to do things like dependency groupIdgrpgroupId artifactIdflex-components version1.0/version scope fm:domain=default fm:url=/components/flex.swfrsl/scope dependency I guess existing tooling is sadly not namespace aware.
Re: Pom changes
I'm opposed to namespaces for two reasons. One is a global reason, the other applies only to 'core' configuration. The global reason: read all the very cogent writing from the HTML5 process as to why they have run screaming away from namespaces. The more local reason: Consider what started this discussion recently: adding a declaration to a POM that indicates that the project serves the purpose of multiple artifacts for dependency management. If you put that in a namespace, how to do you explain it? It was invented in 2011 is one possible explanation. Pretty soon, we're up our ears in a confusing collection of namespaces. Spring, at least, groups things functionally into namespaces. But that doesn't work if the criteria is 'new feature - new namespace'. And you've got users cursing us as they try to remember which namespace goes with which feature. On the other hand, if you want to open the door for new information in the POM that 'belongs to' particular plugins (e.g. m2e), namespaces would at least make logical sense, unless you are persuaded by the HTML analogy. On Wed, Jun 29, 2011 at 9:07 AM, Nigel Magnay nigel.mag...@gmail.com wrote: If tools validate against the schema, they know when a POM is, in fact, valid for its declared model. Thus, any elements that the tool does not recognize are proved to be 'messengers from the future'. It would help enormously if 'messengers from the future' used an appropriate XML namespace so that they could be discarded by clients that don't understand them. It always surprised me that the pom files never allowed the plugins to extend the meaning. For example, using some plugins I'm forced to maintain a separate config file, referencing much of the same information by coordinate. It'd be nice to be able to do things like dependency groupIdgrpgroupId artifactIdflex-components version1.0/version scope fm:domain=default fm:url=/components/flex.swfrsl/scope dependency I guess existing tooling is sadly not namespace aware. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Pom changes
I'm not sure the HTML analogy flies (in particular, I'm not convinced that, say, schema.org isn't just re-invention of namespaces or RDFa via another mechanism). I have no argument that XML namespaces are somewhat klunky, but they are at least standardised and have well understood transformations (e.g: stripping them entirely is a trival operation). I wouldn't go mad on them, in fact I'd try hard to avoid them, but the fact I have to maintain - effectively - cross-reference lists against data in a separate descriptor is one of the reasons I periodically go sniffing around gradle.org. I'd also note that the current web attitude is 'if it don't render, upgrade your browser' - effectively deciding that backwards compatibility is no longer a design goal. On Wed, Jun 29, 2011 at 2:19 PM, Benson Margulies bimargul...@gmail.comwrote: I'm opposed to namespaces for two reasons. One is a global reason, the other applies only to 'core' configuration. The global reason: read all the very cogent writing from the HTML5 process as to why they have run screaming away from namespaces. The more local reason: Consider what started this discussion recently: adding a declaration to a POM that indicates that the project serves the purpose of multiple artifacts for dependency management. If you put that in a namespace, how to do you explain it? It was invented in 2011 is one possible explanation. Pretty soon, we're up our ears in a confusing collection of namespaces. Spring, at least, groups things functionally into namespaces. But that doesn't work if the criteria is 'new feature - new namespace'. And you've got users cursing us as they try to remember which namespace goes with which feature. On the other hand, if you want to open the door for new information in the POM that 'belongs to' particular plugins (e.g. m2e), namespaces would at least make logical sense, unless you are persuaded by the HTML analogy. On Wed, Jun 29, 2011 at 9:07 AM, Nigel Magnay nigel.mag...@gmail.com wrote: If tools validate against the schema, they know when a POM is, in fact, valid for its declared model. Thus, any elements that the tool does not recognize are proved to be 'messengers from the future'. It would help enormously if 'messengers from the future' used an appropriate XML namespace so that they could be discarded by clients that don't understand them. It always surprised me that the pom files never allowed the plugins to extend the meaning. For example, using some plugins I'm forced to maintain a separate config file, referencing much of the same information by coordinate. It'd be nice to be able to do things like dependency groupIdgrpgroupId artifactIdflex-components version1.0/version scope fm:domain=default fm:url=/components/flex.swfrsl/scope dependency I guess existing tooling is sadly not namespace aware. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Pom changes
This is a new thread for the topic I accidentally started with Steven. I'm fairly new around here, so please try to forgive me for (re)stating the obvious. There is an ecosystem of tools that parse poms. They don't use any library we give them, they just parse them. We want old tools to handle new poms without crashing. We'd like those tools to be able to distinguish legitimate extensions from goofs, since some of them are trying to support authoring. This is hard. Retroactively, it may be impossible. However, we do have XML Schema to help us. If tools validate against the schema, they know when a POM is, in fact, valid for its declared model. Thus, any elements that the tool does not recognize are proved to be 'messengers from the future'. I personally think that it is madness to start telling people, 'well, yes, we've extended the expressiveness of the pom, but you have to add special off-to-the-side files to use the new elements.' So, one option we could adopt is to start a propaganda campaign now: Do you parse poms? Do you tolerate new elements? If not, better fix your code now, because in a few months they will be arriving. After all, in theory, some existing tool could barf on new scopes or any other supposedly compatible change we make. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Pom changes
maven 2.0.10 is still widely used. and convincing enterprises to upgrade is tricky... even our own model parsing is not forgiving if i recall correctly... so far as 3.0.x too - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 28 Jun 2011 23:31, Benson Margulies bimargul...@gmail.com wrote: This is a new thread for the topic I accidentally started with Steven. I'm fairly new around here, so please try to forgive me for (re)stating the obvious. There is an ecosystem of tools that parse poms. They don't use any library we give them, they just parse them. We want old tools to handle new poms without crashing. We'd like those tools to be able to distinguish legitimate extensions from goofs, since some of them are trying to support authoring. This is hard. Retroactively, it may be impossible. However, we do have XML Schema to help us. If tools validate against the schema, they know when a POM is, in fact, valid for its declared model. Thus, any elements that the tool does not recognize are proved to be 'messengers from the future'. I personally think that it is madness to start telling people, 'well, yes, we've extended the expressiveness of the pom, but you have to add special off-to-the-side files to use the new elements.' So, one option we could adopt is to start a propaganda campaign now: Do you parse poms? Do you tolerate new elements? If not, better fix your code now, because in a few months they will be arriving. After all, in theory, some existing tool could barf on new scopes or any other supposedly compatible change we make. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Pom changes
But why do 2.0.10 users need to build against brand-spanking-new poms? And, if they do, could we give them a downconversion tool? On Tue, Jun 28, 2011 at 6:47 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: maven 2.0.10 is still widely used. and convincing enterprises to upgrade is tricky... even our own model parsing is not forgiving if i recall correctly... so far as 3.0.x too - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 28 Jun 2011 23:31, Benson Margulies bimargul...@gmail.com wrote: This is a new thread for the topic I accidentally started with Steven. I'm fairly new around here, so please try to forgive me for (re)stating the obvious. There is an ecosystem of tools that parse poms. They don't use any library we give them, they just parse them. We want old tools to handle new poms without crashing. We'd like those tools to be able to distinguish legitimate extensions from goofs, since some of them are trying to support authoring. This is hard. Retroactively, it may be impossible. However, we do have XML Schema to help us. If tools validate against the schema, they know when a POM is, in fact, valid for its declared model. Thus, any elements that the tool does not recognize are proved to be 'messengers from the future'. I personally think that it is madness to start telling people, 'well, yes, we've extended the expressiveness of the pom, but you have to add special off-to-the-side files to use the new elements.' So, one option we could adopt is to start a propaganda campaign now: Do you parse poms? Do you tolerate new elements? If not, better fix your code now, because in a few months they will be arriving. After all, in theory, some existing tool could barf on new scopes or any other supposedly compatible change we make. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Pom changes
On Wed, Jun 29, 2011 at 1:02 AM, Benson Margulies bimargul...@gmail.com wrote: But why do 2.0.10 users need to build against brand-spanking-new poms? And, if they do, could we give them a downconversion tool? the new poms will arrive to central for everyone to use.. Milos On Tue, Jun 28, 2011 at 6:47 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: maven 2.0.10 is still widely used. and convincing enterprises to upgrade is tricky... even our own model parsing is not forgiving if i recall correctly... so far as 3.0.x too - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 28 Jun 2011 23:31, Benson Margulies bimargul...@gmail.com wrote: This is a new thread for the topic I accidentally started with Steven. I'm fairly new around here, so please try to forgive me for (re)stating the obvious. There is an ecosystem of tools that parse poms. They don't use any library we give them, they just parse them. We want old tools to handle new poms without crashing. We'd like those tools to be able to distinguish legitimate extensions from goofs, since some of them are trying to support authoring. This is hard. Retroactively, it may be impossible. However, we do have XML Schema to help us. If tools validate against the schema, they know when a POM is, in fact, valid for its declared model. Thus, any elements that the tool does not recognize are proved to be 'messengers from the future'. I personally think that it is madness to start telling people, 'well, yes, we've extended the expressiveness of the pom, but you have to add special off-to-the-side files to use the new elements.' So, one option we could adopt is to start a propaganda campaign now: Do you parse poms? Do you tolerate new elements? If not, better fix your code now, because in a few months they will be arriving. After all, in theory, some existing tool could barf on new scopes or any other supposedly compatible change we make. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Pom changes in 2.1 (was Re: dependency version conflict resolution)
Improved dependency version conflict resolution, and a lot of other important issues either require or would benefit from changing the pom model. As far as I can tell, there have not yet been any changes to this model in the 2.1 branch. So I was wondering what should be the strategy for changes in the future? Brian brought up the issue that if we change the model and start deploying artifacts to the repository that use the new poms, then there may be some incompatibility if the dependency tree contains a mix of older and newer poms. So the remaining choices appear to be either start a new repository or never change the pom model. So can we make changes to the model in 2.1, or do we have to work with the existing model? Mark Hobson wrote: Yep, my ongoing saga with conflict resolution is detailed here: http://docs.codehaus.org/display/MAVEN/Conflict+Resolvers http://jira.codehaus.org/browse/MNG-612 Would be great to get this resolved. Mark 2008/5/22 Brett Porter [EMAIL PROTECTED]: That's what I was referring to. On 22/05/2008, at 10:25 AM, Brian E. Fox wrote: I thought Mark already started this and/or has a proposal on the wiki. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] On Behalf Of Brett Porter Sent: Wednesday, May 21, 2008 8:11 PM To: Maven Developers List Subject: Re: dependency version conflict resolution Hi John, I don't think there's any objection to implementing this strategy - however it's something that needs to be done in a pluggable way so that current build behaviour doesn't change. This has a few dependencies on other work in the core. Some people who are interested have contributed towards this in the past. Is this something you are looking to work on, or just making a request? Thanks, Brett On 22/05/2008, at 5:36 AM, John Williams wrote: I'm new to list list so I apologize if this has been beaten to death before, but I'd like to propose a change to the version conflict resolution strategy that Maven uses. It's a combination of the current nearest version strategy and a highest version strategy. There are two cases: 1. When an artifact has a declared dependency, the declared version always takes precedence over any inherited version. 2. When a project inherits two versions of the same dependency, the highest-numbered version takes precedence. Rule 1 is consistent with the nearest strategy. It is necessary to give developers adequate control over the dependencies they use, and also because it would be very confusing for Maven to use an artifact version other than the one declared in the pom.xml file. I believe this rule preserves all the desirable features of the nearest strategy. Rule 2 is consistent with a highest strategy, and it addresses the problem of unrelated artifacts overriding each other's dependencies. Suppose artifact A depends on B and C, both of which depend on different versions of D (and A does not depend directly on D). Obviously either B or C will be forced for use a version of D for which it was not designed, but if the developer of D has made some attempt to preserve compatibility across versions, the higher-numbered version of D is far more likely to work with both B and C and the lower-numbered version. I think this would be a big improvement over the somewhat arbitrary decision that the nearest strategy would make. --jw - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - 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] -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pom changes in 2.1 (was Re: dependency version conflict resolution)
On 22-May-08, at 7:28 AM, Paul Gier wrote: Improved dependency version conflict resolution, and a lot of other important issues either require or would benefit from changing the pom model. As far as I can tell, there have not yet been any changes to this model in the 2.1 branch. So I was wondering what should be the strategy for changes in the future? Brian brought up the issue that if we change the model and start deploying artifacts to the repository that use the new poms, then there may be some incompatibility if the dependency tree contains a mix of older and newer poms. So the remaining choices appear to be either start a new repository or never change the pom model. So can we make changes to the model in 2.1, or do we have to work with the existing model? Provide we retain the behavior of old with a flag if the user desires with 2.1 the door is wide open to correct anything we see fit. Mark Hobson wrote: Yep, my ongoing saga with conflict resolution is detailed here: http://docs.codehaus.org/display/MAVEN/Conflict+Resolvers http://jira.codehaus.org/browse/MNG-612 Would be great to get this resolved. Mark 2008/5/22 Brett Porter [EMAIL PROTECTED]: That's what I was referring to. On 22/05/2008, at 10:25 AM, Brian E. Fox wrote: I thought Mark already started this and/or has a proposal on the wiki. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] On Behalf Of Brett Porter Sent: Wednesday, May 21, 2008 8:11 PM To: Maven Developers List Subject: Re: dependency version conflict resolution Hi John, I don't think there's any objection to implementing this strategy - however it's something that needs to be done in a pluggable way so that current build behaviour doesn't change. This has a few dependencies on other work in the core. Some people who are interested have contributed towards this in the past. Is this something you are looking to work on, or just making a request? Thanks, Brett On 22/05/2008, at 5:36 AM, John Williams wrote: I'm new to list list so I apologize if this has been beaten to death before, but I'd like to propose a change to the version conflict resolution strategy that Maven uses. It's a combination of the current nearest version strategy and a highest version strategy. There are two cases: 1. When an artifact has a declared dependency, the declared version always takes precedence over any inherited version. 2. When a project inherits two versions of the same dependency, the highest-numbered version takes precedence. Rule 1 is consistent with the nearest strategy. It is necessary to give developers adequate control over the dependencies they use, and also because it would be very confusing for Maven to use an artifact version other than the one declared in the pom.xml file. I believe this rule preserves all the desirable features of the nearest strategy. Rule 2 is consistent with a highest strategy, and it addresses the problem of unrelated artifacts overriding each other's dependencies. Suppose artifact A depends on B and C, both of which depend on different versions of D (and A does not depend directly on D). Obviously either B or C will be forced for use a version of D for which it was not designed, but if the developer of D has made some attempt to preserve compatibility across versions, the higher- numbered version of D is far more likely to work with both B and C and the lower-numbered version. I think this would be a big improvement over the somewhat arbitrary decision that the nearest strategy would make. --jw - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - 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] -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- In short, man creates for himself a new religion of
RE: Pom changes in 2.1 (was Re: dependency version conflict resolution)
So can we make changes to the model in 2.1, or do we have to work with the existing model? Provide we retain the behavior of old with a flag if the user desires with 2.1 the door is wide open to correct anything we see fit. It's more than that, the poms deployed to central should conform to the 4.0.0 format or no one will be able to use them. Since not a lot of info is needed when depending on an artifact, this should be doable without any loss of resolution. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MEV-21) pom changes for basic hibernate project
[ http://jira.codehaus.org/browse/MEV-21?page=all ] Carlos Sanchez closed MEV-21: - Resolution: Fixed pom changes for basic hibernate project --- Key: MEV-21 URL: http://jira.codehaus.org/browse/MEV-21 Project: Maven Evangelism Type: Task Components: Dependencies Reporter: Ryan Sonnek Assignee: Carlos Sanchez it seems as if the current m2 repository has some invalid poms. I'm assuming this is because the m2 pom's were automatically generated from the m1 pom's. Here is a list of changes that were required in my local repository to get a very basic hibernate project up and going. change dom4j-1.6.pom stax dependencies to these: dependency groupIdstax/groupId artifactIdstax-api/artifactId version1.0/version /dependency dependency groupIdstax/groupId artifactIdstax/artifactId version1.1-dev/version /dependency remove this dependency from stax-1.1-dev.pom: dependency groupIdxmlbeans-jsr173-api/groupId artifactIdxmlbeans-jsr173-api/artifactId version2.0-dev/version /dependency manually install geronimo servlet-api as servlet api remove two dependencies from xom-1.0b3.pom: dependency groupIdicu4j/groupId artifactIdicu4j/artifactId version2.6.1/version /dependency dependency groupIdtagsoup/groupId artifactIdtagsoup/artifactId version0.9.7/version /dependency manually install empty jdbc-2.0.jar can these pom's be scrubbed, or move these dependencies to the m2 repository? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-21) pom changes for basic hibernate project
[ http://jira.codehaus.org/browse/MEV-21?page=comments#action_42300 ] Eric Crampton commented on MEV-21: -- I had a problem with the hibernate-3.0.5.pom---not sure what version the others above were using. The version of swarmcache says 1.0rc2, but should be 1.0RC2 (note capitalization difference). That's the only difference I had to make to use the hibernate pom present in the M2 repository as of right now. pom changes for basic hibernate project --- Key: MEV-21 URL: http://jira.codehaus.org/browse/MEV-21 Project: Maven Evangelism Type: Task Components: Dependencies Reporter: Ryan Sonnek Assignee: Carlos Sanchez it seems as if the current m2 repository has some invalid poms. I'm assuming this is because the m2 pom's were automatically generated from the m1 pom's. Here is a list of changes that were required in my local repository to get a very basic hibernate project up and going. change dom4j-1.6.pom stax dependencies to these: dependency groupIdstax/groupId artifactIdstax-api/artifactId version1.0/version /dependency dependency groupIdstax/groupId artifactIdstax/artifactId version1.1-dev/version /dependency remove this dependency from stax-1.1-dev.pom: dependency groupIdxmlbeans-jsr173-api/groupId artifactIdxmlbeans-jsr173-api/artifactId version2.0-dev/version /dependency manually install geronimo servlet-api as servlet api remove two dependencies from xom-1.0b3.pom: dependency groupIdicu4j/groupId artifactIdicu4j/artifactId version2.6.1/version /dependency dependency groupIdtagsoup/groupId artifactIdtagsoup/artifactId version0.9.7/version /dependency manually install empty jdbc-2.0.jar can these pom's be scrubbed, or move these dependencies to the m2 repository? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (MEV-21) pom changes for basic hibernate project
[ http://jira.codehaus.org/browse/MEV-21?page=all ] Brett Porter moved MNG-387 to MEV-21: - Component: (was: repository-tools) Dependencies Issue Type: Task (was: Bug) Key: MEV-21 (was: MNG-387) Project: Maven Evangelism (was: Maven 2) pom changes for basic hibernate project --- Key: MEV-21 URL: http://jira.codehaus.org/browse/MEV-21 Project: Maven Evangelism Type: Task Components: Dependencies Reporter: Ryan Sonnek it seems as if the current m2 repository has some invalid poms. I'm assuming this is because the m2 pom's were automatically generated from the m1 pom's. Here is a list of changes that were required in my local repository to get a very basic hibernate project up and going. change dom4j-1.6.pom stax dependencies to these: dependency groupIdstax/groupId artifactIdstax-api/artifactId version1.0/version /dependency dependency groupIdstax/groupId artifactIdstax/artifactId version1.1-dev/version /dependency remove this dependency from stax-1.1-dev.pom: dependency groupIdxmlbeans-jsr173-api/groupId artifactIdxmlbeans-jsr173-api/artifactId version2.0-dev/version /dependency manually install geronimo servlet-api as servlet api remove two dependencies from xom-1.0b3.pom: dependency groupIdicu4j/groupId artifactIdicu4j/artifactId version2.6.1/version /dependency dependency groupIdtagsoup/groupId artifactIdtagsoup/artifactId version0.9.7/version /dependency manually install empty jdbc-2.0.jar can these pom's be scrubbed, or move these dependencies to the m2 repository? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-387) pom changes for basic hibernate project
pom changes for basic hibernate project --- Key: MNG-387 URL: http://jira.codehaus.org/browse/MNG-387 Project: m2 Type: Bug Components: repository-tools Reporter: Ryan Sonnek it seems as if the current m2 repository has some invalid poms. I'm assuming this is because the m2 pom's were automatically generated from the m1 pom's. Here is a list of changes that were required in my local repository to get a very basic hibernate project up and going. change dom4j-1.6.pom stax dependencies to these: dependency groupIdstax/groupId artifactIdstax-api/artifactId version1.0/version /dependency dependency groupIdstax/groupId artifactIdstax/artifactId version1.1-dev/version /dependency remove this dependency from stax-1.1-dev.pom: dependency groupIdxmlbeans-jsr173-api/groupId artifactIdxmlbeans-jsr173-api/artifactId version2.0-dev/version /dependency manually install geronimo servlet-api as servlet api remove two dependencies from xom-1.0b3.pom: dependency groupIdicu4j/groupId artifactIdicu4j/artifactId version2.6.1/version /dependency dependency groupIdtagsoup/groupId artifactIdtagsoup/artifactId version0.9.7/version /dependency manually install empty jdbc-2.0.jar can these pom's be scrubbed, or move these dependencies to the m2 repository? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-387) pom changes for basic hibernate project
[ http://jira.codehaus.org/browse/MNG-387?page=comments#action_39006 ] Ryan Sonnek commented on MNG-387: - I also had to add the following dependencies which are not provided in the hibernate POM: dependency groupIdodmg/groupId artifactIdodmg/artifactId version3.0/version scoperuntime/scope /dependency dependency groupIdehcache/groupId artifactIdehcache/artifactId version1.1/version scoperuntime/scope /dependency dependency groupIdcglib/groupId artifactIdcglib/artifactId version2.0.2/version /dependency dependency groupIdasm/groupId artifactIdasm/artifactId version1.4.3/version /dependency dependency groupIdgeronimo-spec/groupId artifactIdgeronimo-spec-jta/artifactId version1.0-M1/version /dependency pom changes for basic hibernate project --- Key: MNG-387 URL: http://jira.codehaus.org/browse/MNG-387 Project: m2 Type: Bug Components: repository-tools Reporter: Ryan Sonnek it seems as if the current m2 repository has some invalid poms. I'm assuming this is because the m2 pom's were automatically generated from the m1 pom's. Here is a list of changes that were required in my local repository to get a very basic hibernate project up and going. change dom4j-1.6.pom stax dependencies to these: dependency groupIdstax/groupId artifactIdstax-api/artifactId version1.0/version /dependency dependency groupIdstax/groupId artifactIdstax/artifactId version1.1-dev/version /dependency remove this dependency from stax-1.1-dev.pom: dependency groupIdxmlbeans-jsr173-api/groupId artifactIdxmlbeans-jsr173-api/artifactId version2.0-dev/version /dependency manually install geronimo servlet-api as servlet api remove two dependencies from xom-1.0b3.pom: dependency groupIdicu4j/groupId artifactIdicu4j/artifactId version2.6.1/version /dependency dependency groupIdtagsoup/groupId artifactIdtagsoup/artifactId version0.9.7/version /dependency manually install empty jdbc-2.0.jar can these pom's be scrubbed, or move these dependencies to the m2 repository? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
