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 wrote: > 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 > 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 > > > > > > grp > > flex-components> > > 1.0 > > rsl > > > > > > > > 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 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 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 > > > grp > flex-components> > 1.0 > rsl > > > > 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
> > > > 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 grp flex-components> 1.0 rsl I guess existing tooling is sadly not namespace aware.
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
On 29 June 2011 12:20, Benson Margulies 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 wrote: >> On Wed, Jun 29, 2011 at 1:02 AM, Benson Margulies >> 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 >>> 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" 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
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 wrote: > On Wed, Jun 29, 2011 at 1:02 AM, Benson Margulies > 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 >> 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" 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 Wed, Jun 29, 2011 at 1:02 AM, Benson Margulies 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 > 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" 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
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 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" 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
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" 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 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]
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
