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 <[email protected]> wrote: > On Wed, Jun 29, 2011 at 1:02 AM, Benson Margulies <[email protected]> > 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 >> <[email protected]> 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" <[email protected]> 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: [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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
