On 29 June 2011 12:20, Benson Margulies <[email protected]> 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 <[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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
