We of course also should think one step further and also make a check how we proceed from XSD-4.0.1 to 4.0.2
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, 11:35 AM > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
