A few more 'schematic' notes. 1) AFAIKT, the schema isn't really part of the maven core. Nothing in maven core ever looks at it. The ancient pull parser in plexus wouldn't know a schema if one fell on it from a height.
2) We could publish a 4.0.1 schema tomorrow on the web site (does it need a release vote? :-)) and disturb nothing, since nothing will look at it until someone bothers to edit a POM to point to it. 3) At least the release plugin has a feature for adding schema declarations. We could hold off on changing it, and document: if you want to use these new features, it's up to you to put the new schema URL into your POM if you want to validate. On Fri, Jul 29, 2011 at 7:35 AM, Benson Margulies <bimargul...@gmail.com> wrote: > I'm in favor of the policy (since I suggested it), that maven 3.0.X > can deliver pom XSD 4.0.Y, where the changes the the XSD are proven to > be harmless to popular old versions and common sense characterizes > them as unlikely to blow anything up. I submit that adding some > inheritance control attributes would come under that rubric. > > Do we need to vote this, or otherwise clarify consensus or the lack > thereof? Does anyone hate it? > > On Fri, Jul 29, 2011 at 4:26 AM, Stephen Connolly > <stephen.alan.conno...@gmail.com> wrote: >> How about coming at this from a different track... >> >> <scm>scm:parent:/path/in/parent</scm> >> >> that is an SCM that is the same as parent with a path in the parent. >> >> the parent scm provider would look up the parent's scm and could use >> some rules to derive the effective path, acting like a delegate and >> giving us the correct path. >> >> It does mean that unless <prerequ><maven>3.1</maven></prerequ> users >> would have to specify the scm in all initial child modules. >> >> On 29 July 2011 08:39, Mark Struberg <strub...@yahoo.de> wrote: >>> gnah sorry :( >>> I explicitly tested the schema validation, but obviously using a new tool >>> (I'm new to macs...) at 3 o clock in the morning isn't producing reliable >>> results :/ >>> >>> But your idea with the XSD-4.0.1 sound really great. Almost too good to >>> believe! >>> That would probably allow us to implement most of the new features like >>> mixins and stuff _without_ getting incompatible. Maybe we could not >>> implement all the new stuff, but it's worth thinking about it. >>> >>> Otoh I'm not sure if such a change should be done in a bugfix release. >>> Or better said: I'm pretty sure that we should _not_ do such a change in a >>> bugfix release ;) >>> >>> LieGrue, >>> strub >>> >>> >>> --- On Fri, 7/29/11, Benson Margulies <bimargul...@gmail.com> wrote: >>> >>>> From: Benson Margulies <bimargul...@gmail.com> >>>> Subject: Re: [DISCUSS] SCM child-project URL composition >>>> To: "Maven Developers List" <dev@maven.apache.org> >>>> Date: Friday, July 29, 2011, 2:01 AM >>>> I have some perhaps minor bad news >>>> about attributes. >>>> >>>> Attributes on the <url/> element won't validate >>>> against the current >>>> schema. I had hoped to discover otherwise, but no such >>>> luck. >>>> >>>> The combine.children trick passes because it is inside of >>>> the 'any' >>>> inside the plugin configuration. >>>> >>>> I claim that the following is tolerable from a >>>> compatibility standpoint: >>>> >>>> 1) create a 4.0.1 XSD file that adds the necessary >>>> xs:anyAttribute (or >>>> specific attributes, if you prefer) to the <url/> >>>> element. >>>> >>>> 2) Change default archetypes and the release plugin and >>>> friends to add >>>> this schema instead of the 4.0.0 schema. >>>> >>>> In other words, Mark's experiments show that, in >>>> *practical* terms, >>>> adding the attributes works. That leave the question of >>>> programs that >>>> actually pay attention to the schema itself. The only bad >>>> case would >>>> be some program out there which for some reason always >>>> validates >>>> against the 4.0.0 schema even if the schema declared at the >>>> top is >>>> 4.0.1. I don't believe in this. >>>> >>>> --------------------------------------------------------------------- >>>> 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
