I think that your understanding is oversimplified, with all due respect. Yes, there is an xml schema emitted by modello. However, no, no version of maven checks poms against a schema. So, it is possible to make changes to the pom that are compatible with Maven 2, by the expedient of testing that they are, in fact, compatible. In particular Maven 2 pays no attention to attributes on <url/> elements. So adding them can't break it.
Now, anyone who adds the attributes has to use a new enough maven-release-plugin to get the benefit of them. On Sat, Jul 30, 2011 at 4:55 AM, Ralph Goers <ralph.go...@dslextreme.com> wrote: > i think I'm missing something. My understanding has been that any file named > pom.xml that isn't compliant with 4.0.0 is going to break Maven 2 users. Am I > misunderstanding something about what is being proposed? > > Ralph > > On Jul 29, 2011, at 8:04 AM, Benson Margulies wrote: > >> I think Herve said so. >> >> On Jul 29, 2011, at 10:50 AM, John Casey <jdca...@commonjava.org> wrote: >> >>> >>> >>> On 7/29/11 7:45 AM, Benson Margulies wrote: >>>> thereof? Does anyone hate it? >>>>> >>>>> I'm just a bit behind on mail, but need a clarification - in Maven the >>>>> XSD is an end result of the model that is generated, but you seem to >>>>> describe it here as an input. Am I misreading? >>>> >>>> I've been assuming that the XSD file is a manual production, but I >>>> didn't actually check. I guess that modello might be in the business >>>> of excreting XSD files, too. So my more recent email is a bit wrong. >>> >>> Yes, Modello is used to generate the XSD. So the next question that comes >>> up is: can we generate an XSD like you describe using Modello? >>> >>> If we can, I think this is a pretty decent plan, actually...the best of >>> limited options, IMO. >>> >>> If we get the alternative format work done later, then we escape the need >>> to live with the format forever too. So, the danger that we're adding to >>> our ball of tape and chewing gum is limited by that. >>> >>>> >>>> >>>>> >>>>> If you're suggesting a change to the model that is backwards compat >>>>> API-wise with 4.0.0, and has identical behaviour (or graceful >>>>> degradation) when read from the repository by<= 3.0.3, then I don't see >>>>> any problem with a particular change. >>>> >>>> Yes, that's precisely the idea. Some new accessors appear in the >>>> model, and if you don't bother them, they won't bother you. >>>> >>>> >>>>> >>>>> - Brett >>>>> >>>>> -- >>>>> Brett Porter >>>>> br...@apache.org >>>>> http://brettporter.wordpress.com/ >>>>> http://au.linkedin.com/in/brettporter >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> 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 >>>> >>> >>> -- >>> John Casey >>> Developer, PMC Chair - Apache Maven (http://maven.apache.org) >>> Blog: http://www.johnofalltrades.name/ >>> >>> --------------------------------------------------------------------- >>> 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
