Re: [DISCUSS] SCM child-project URL composition
On Sat, Jul 30, 2011 at 1:07 PM, Ralph Goers wrote: > I am aware the Maven never does schema checking but that it complains when > processing the pom when it sees things that aren't part of the model. So if > IIUC you are just taking advantage of a place that Maven isn't rigorous in > its validation. That would be fine. Ralph, sorry to have assumed that you knew less, rather than more, than I did. We're now on the same page in any case. --benson > > Ralph > > On Jul 30, 2011, at 4:29 AM, Benson Margulies wrote: > >> 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 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 >> 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 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 >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > - To un
Re: [DISCUSS] SCM child-project URL composition
I am aware the Maven never does schema checking but that it complains when processing the pom when it sees things that aren't part of the model. So if IIUC you are just taking advantage of a place that Maven isn't rigorous in its validation. That would be fine. Ralph On Jul 30, 2011, at 4:29 AM, Benson Margulies wrote: > 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 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 > 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 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 > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
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 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 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 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
Re: [DISCUSS] SCM child-project URL composition
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 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
Re: [DISCUSS] SCM child-project URL composition
I think Herve said so. On Jul 29, 2011, at 10:50 AM, John Casey 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
Re: [DISCUSS] SCM child-project URL composition
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
Re: [DISCUSS] SCM child-project URL composition
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. > > 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
Re: [DISCUSS] SCM child-project URL composition
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 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 > wrote: >> How about coming at this from a different track... >> >> scm:parent:/path/in/parent >> >> 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 3.1 users >> would have to specify the scm in all initial child modules. >> >> On 29 July 2011 08:39, Mark Struberg 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 wrote: >>> >>>> From: Benson Margulies >>>> Subject: Re: [DISCUSS] SCM child-project URL composition >>>> To: "Maven Developers List" >>>> Date: Friday, July 29, 2011, 2:01 AM >>>> I have some perhaps minor bad news >>>> about attributes. >>>> >>>> Attributes on the 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 >>>> 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
Re: [DISCUSS] SCM child-project URL composition
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 wrote: > From: Benson Margulies > Subject: Re: [DISCUSS] SCM child-project URL composition > To: "Maven Developers List" > 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 > > wrote: > > How about coming at this from a different track... > > > > scm:parent:/path/in/parent > > > > 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 > 3.1 > users > > would have to specify the scm in all initial child > modules. > > > > On 29 July 2011 08:39, Mark Struberg > 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 > wrote: > >> > >>> From: Benson Margulies > >>> Subject: Re: [DISCUSS] SCM child-project URL > composition > >>> To: "Maven Developers List" > >>> Date: Friday, July 29, 2011, 2:01 AM > >>> I have some perhaps minor bad news > >>> about attributes. > >>> > >>> Attributes on the 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 > > >>> 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
Re: [DISCUSS] SCM child-project URL composition
On 29 July 2011 12:35, Benson Margulies wrote: > I'm in favor of the policy (since I suggested it), that maven 3.0.X I think that requires at least a minor bump I would not be happy with classing those as a patch bump > 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 > wrote: >> How about coming at this from a different track... >> >> scm:parent:/path/in/parent >> >> 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 3.1 users >> would have to specify the scm in all initial child modules. >> >> On 29 July 2011 08:39, Mark Struberg 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 wrote: >>> >>>> From: Benson Margulies >>>> Subject: Re: [DISCUSS] SCM child-project URL composition >>>> To: "Maven Developers List" >>>> Date: Friday, July 29, 2011, 2:01 AM >>>> I have some perhaps minor bad news >>>> about attributes. >>>> >>>> Attributes on the 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 >>>> 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
Re: [DISCUSS] SCM child-project URL composition
On 29/07/2011, at 9:35 PM, Benson Margulies 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? 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? 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. - 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
Re: [DISCUSS] SCM child-project URL composition
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 wrote: > How about coming at this from a different track... > > scm:parent:/path/in/parent > > 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 3.1 users > would have to specify the scm in all initial child modules. > > On 29 July 2011 08:39, Mark Struberg 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 wrote: >> >>> From: Benson Margulies >>> Subject: Re: [DISCUSS] SCM child-project URL composition >>> To: "Maven Developers List" >>> Date: Friday, July 29, 2011, 2:01 AM >>> I have some perhaps minor bad news >>> about attributes. >>> >>> Attributes on the 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 >>> 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
Re: [DISCUSS] SCM child-project URL composition
How about coming at this from a different track... scm:parent:/path/in/parent 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 3.1 users would have to specify the scm in all initial child modules. On 29 July 2011 08:39, Mark Struberg 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 wrote: > >> From: Benson Margulies >> Subject: Re: [DISCUSS] SCM child-project URL composition >> To: "Maven Developers List" >> Date: Friday, July 29, 2011, 2:01 AM >> I have some perhaps minor bad news >> about attributes. >> >> Attributes on the 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 >> 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
Re: [DISCUSS] SCM child-project URL composition
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 wrote: > From: Benson Margulies > Subject: Re: [DISCUSS] SCM child-project URL composition > To: "Maven Developers List" > Date: Friday, July 29, 2011, 2:01 AM > I have some perhaps minor bad news > about attributes. > > Attributes on the 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 > 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
Re: [DISCUSS] SCM child-project URL composition
Hi,
here's a use case/convention which neither the current "append child's
artifactId" strategy nor the "static:" prefix can handle.
The parent project uses something like
/scm-root/
and the modules/children use
/scm-root/modules/${project.artifactId}
IMHO, the only fully flexible solution is to have an *absolute* URI
which is used for the current project and an extra attribute which
specifies the *relative* URI to be appended by child projects.
This extra attribute would simply default to "./${project.artifactId}",
thereby making the "append child's artifactId" strategy explicit. The
"static" use case could then be handled by a value of
"../${project.artifactId}".
Of course, this relies on SCM providers properly handling path
components like "." and "..". Also, when property expansion happens
needs to be hashed out. (I think, the parent's relative path attribute
should be expanded in the child's context.)
But while the above convention is maybe not a common case in SCM URIs,
the relations between parent and child *site* URIs (which currently
also use the "append child's artifactId" strategy) are more diverse,
which I think warrants thinking about a flexible solution.
Just my $0.02.
Andreas
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
Hi Hervé! Txs for the input! > this would be project.scm.autoModule? dont think that properties would work in this case. They are also only fully evaluated after the model is already built, isn't? Thats a tad to late I fear. But I'm happy to be proven wrong if you find time to test the behaviour. > And the upgrade scenario exists: you can override a library > shipped with Maven Hmm not really. Because older projects rely on older SCM providers which they define in their pom. Another project might use the latest and greatest new SCM provider. Thus this new 'scm-url-mangler' must be compatible to years of maven-scm history, without even knowing which version will be taken. Not even at runtime, because it will get used at a point in time where the maven-scm version is not yet determined. LieGrue, strub --- On Fri, 7/29/11, Hervé BOUTEMY wrote: > From: Hervé BOUTEMY > Subject: Re: [DISCUSS] SCM child-project URL composition > To: "Maven Developers List" > Date: Friday, July 29, 2011, 6:31 AM > Le vendredi 29 juillet 2011, Mark > Struberg a écrit : > > > Is it as simple as that for all SCMs? > > > > Yes it is. > > Remember the old days: this is only a fix for a 'fix'. > Originally the SCM > > URLs haven't been changed for child modules. This > 'feature' only got > > introduce later to make life easier for SVN and CVS > users (the vast > > majority of projects back then). > > > > What we now do is to disable this 'feature' (which now > got a known and > > expected default behaviour) in some certain cases. Not > more not less. > a property? > like we did for project.build.encoding? > this would be project.scm.autoModule? > > > > > I honestly fear of doing some magic with the SCM Urls > because those are NOT > > native urls but get interpreted by the SCM providers. > Thus the 'url > > adaptors' would need to 100% match the specific scm > providers. So you > > either ship it in the same build or you are soon > doomed I fear. But as you > > need to ship that classes as part of a maven release, > there is just no > > upgrade scenario and you would need to support sins > for a long time... > if this gets into maven-scm, this needs to be a dedicated > module, cross-scms, > and independendant from wagon-provider-api > And the upgrade scenario exists: you can override a library > shipped with Maven > > > > > The 2nd nice benefit: I'm currently digging into the > attribute stuff in > > Modello. If this works out, we can use this approach > for other long > > awaited features (like the mixins) in a pom-4.0.0 > compatible way! > if you didn't see, there is a strictXmlAttribute > configuration added in Modello > 1.2 [1] to deal with attributes checks or not > I don't know how the maven.mdo has been configured in every > Maven release. > > Regards, > > Hervé > > [1] http://modello.codehaus.org/modello.html#class_default > > > > LieGrue, > > strub > > > > --- On Fri, 7/29/11, Jason van Zyl > wrote: > > > From: Jason van Zyl > > > Subject: Re: [DISCUSS] SCM child-project URL > composition > > > To: "Maven Developers List" > > > Date: Friday, July 29, 2011, 12:47 AM > > > > > > On Jul 28, 2011, at 8:31 PM, Mark Struberg > wrote: > > > > Of course, not having to touch the POMs is a > good > > > > > > thing. > > > > > > > But I don't get the 'historic behaviour' > part. Even if > > > > > > you would have components in the scm-providers > (which all > > > need to be changed), this solution would not work > with older > > > maven version because they will simply not get > injected > > > somewhere. > > > > > > > > > Dealing with what people use today versus native > > > expressions in the future. The components are > simple, they > > > could be external and use in Maven 2.x and 3.x. > > > > > > > Plus, you would need to split that code from > the > > > > > > scm-providers, as explained before. But > maintaining them > > > separately, I wonder how this should scale. It > must be part > > > of maven-core, because it must clearly be > available _before_ > > > dependencies and even extensions are available. > > > > > > We're going to end up with a few lines of code > for each > > > SCM. For the short term I doubt this is going to > be a > > > problem
Re: [DISCUSS] SCM child-project URL composition
Le vendredi 29 juillet 2011, Mark Struberg a écrit : > > Is it as simple as that for all SCMs? > > Yes it is. > Remember the old days: this is only a fix for a 'fix'. Originally the SCM > URLs haven't been changed for child modules. This 'feature' only got > introduce later to make life easier for SVN and CVS users (the vast > majority of projects back then). > > What we now do is to disable this 'feature' (which now got a known and > expected default behaviour) in some certain cases. Not more not less. a property? like we did for project.build.encoding? this would be project.scm.autoModule? > > I honestly fear of doing some magic with the SCM Urls because those are NOT > native urls but get interpreted by the SCM providers. Thus the 'url > adaptors' would need to 100% match the specific scm providers. So you > either ship it in the same build or you are soon doomed I fear. But as you > need to ship that classes as part of a maven release, there is just no > upgrade scenario and you would need to support sins for a long time... if this gets into maven-scm, this needs to be a dedicated module, cross-scms, and independendant from wagon-provider-api And the upgrade scenario exists: you can override a library shipped with Maven > > The 2nd nice benefit: I'm currently digging into the attribute stuff in > Modello. If this works out, we can use this approach for other long > awaited features (like the mixins) in a pom-4.0.0 compatible way! if you didn't see, there is a strictXmlAttribute configuration added in Modello 1.2 [1] to deal with attributes checks or not I don't know how the maven.mdo has been configured in every Maven release. Regards, Hervé [1] http://modello.codehaus.org/modello.html#class_default > > LieGrue, > strub > > --- On Fri, 7/29/11, Jason van Zyl wrote: > > From: Jason van Zyl > > Subject: Re: [DISCUSS] SCM child-project URL composition > > To: "Maven Developers List" > > Date: Friday, July 29, 2011, 12:47 AM > > > > On Jul 28, 2011, at 8:31 PM, Mark Struberg wrote: > > > Of course, not having to touch the POMs is a good > > > > thing. > > > > > But I don't get the 'historic behaviour' part. Even if > > > > you would have components in the scm-providers (which all > > need to be changed), this solution would not work with older > > maven version because they will simply not get injected > > somewhere. > > > > > > Dealing with what people use today versus native > > expressions in the future. The components are simple, they > > could be external and use in Maven 2.x and 3.x. > > > > > Plus, you would need to split that code from the > > > > scm-providers, as explained before. But maintaining them > > separately, I wonder how this should scale. It must be part > > of maven-core, because it must clearly be available _before_ > > dependencies and even extensions are available. > > > > We're going to end up with a few lines of code for each > > SCM. For the short term I doubt this is going to be a > > problem because there are probably less than 10 to deal with > > and changes could be made quickly and then they are unlikely > > to change. It's not a lot of code to deal with, it can be in > > Maven as it is more for POM construction than anything to do > > with any particular SCM. > > > > > So basically it comes down to > > > > > > 1.) having a list of SCMs which must not get the > > > > module-name appended. It imo doesn't make much difference if > > you do this via a regexp or via a Java class. I think the > > regexp in toolchains.mdo even would have the benefit that a > > user would be able to overwrite/extend the default config if > > he needs to. > > > > Is it as simple as that for all SCMs? > > > > > 2.) marking the url tag somehow. Either inside the URL > > > > string with a prefix like 'absolute:' or via an xml > > attribute. > > > > > The explicit marking of URLs allows this solution to > > > > get applied for site stuff too. The regexp/Java stuff would > > not work for the site URL problematic, because there is no > > information about the intention of the user in the pom atm. > > > > > > It would be useful to see the forms SCM URL construction > > for: > > > > CVS > > SVN > > Git > > Hg > > Perforce > > Clearcase > > > > And anything else that people might want. I think if it's > > going to be
Re: [DISCUSS] SCM child-project URL composition
This was exactly the fix I applied back in 2.0.6 ish times and broke too much stuff. Because the currently impl doesn't care about the trailing /, too many poms have it set incorrectly. On Thu, Jul 28, 2011 at 5:49 PM, John Casey wrote: > > > On 7/28/11 5:43 PM, Benson Margulies wrote: >> >> I keep thinking that I read about a convention that used the presence >> or absence of a trailing '/' on the URL to control this. Does anyone >> else recall this? > > You mean overloading an explicit URL referencing a directory? Seems a tad > confusing and maybe even a problem waiting to happen... > >> >> On Thu, Jul 28, 2011 at 5:32 PM, Brian Fox wrote: >>> >>> not crazy about the syntax, but generally yes i think that makes sense. >>> >>> I've long maintained that we need something similar for properties to >>> balance between "resolve at build time" and "resolve at fetch from >>> repo" type of issues. >>> >>> On Thu, Jul 28, 2011 at 3:37 PM, Mark Struberg wrote: >>>> >>>> Hi John, Brian >>>> >>>> Just to make sure I did understand that correctly: >>>> you propose to use a special URL prefix to tell the maven >>>> DefaultProjectBuilder to treat those urls as static. An example: >>>> >>>> >>>> >>>> >>>> staticscm:git:ssh://myserver:/..>>> >>>> resulting in replacing 'staticscm' with 'scm' and not adding the child >>>> modules to the URL. >>>> Did I get this correctly? >>>> >>>> Tried that with mvn-3.0.3 and mvn-2.2.1 and a standard build works just >>>> fine. Of course a release would only work with the newer maven versions! >>>> >>>> LieGrue, >>>> strub >>>> >>>> --- On Thu, 7/28/11, Brian Fox wrote: >>>> >>>>> From: Brian Fox >>>>> Subject: Re: [DISCUSS] SCM child-project URL composition >>>>> To: "Maven Developers List" >>>>> Date: Thursday, July 28, 2011, 7:23 PM >>>>> On Thu, Jul 28, 2011 at 2:59 PM, John >>>>> Casey >>>>> wrote: >>>>>> >>>>>> Would it be better to have a syntax to mark a URL as >>>>> >>>>> literal, not to be >>>>>> >>>>>> calculated or used as the basis of calculation? >>>>>> >>>>> >>>>> Yes. I tried to fix this behavior for urls back in ~2.0.6/7 >>>>> ish and it >>>>> broke lots of stuff that depended upon that behavior. >>>>> >>>>>> That way, we don't have to worry about adjusting to >>>>> >>>>> new SCMs or other places >>>>>> >>>>>> where we want to use it...new SCMs could be added via >>>>> >>>>> build extension, IIRC, >>>>>> >>>>>> so this is particularly important there. >>>>>> >>>>>> WDYT? >>>>>> >>>>>> On 7/28/11 12:46 PM, Mark Struberg wrote: >>>>>>> >>>>>>> Hi! >>>>>>> >>>>>>> problem description >>>>>>> --- >>>>>>> >>>>>>> SCM URLs currently automatically get extended for >>>>> >>>>> child modules. >>>>>>> >>>>>>> E.g. from >>>>>>> svn://mycompany.com/myproject >>>>>>> in the parent pom, a child module 'frontend' will >>>>> >>>>> result in getting a SCM >>>>>>> >>>>>>> URL >>>>>>> svn://mycompany.com/myproject/frontend >>>>>>> >>>>>>> This is fine for SVN and CVS, but broken for GIT, >>>>> >>>>> HG, etc because the SCM >>>>>>> >>>>>>> URL is 'static' for them. >>>>>>> >>>>>>> >>>>>>> proposal >>>>>>> --- >>>>>>> >>>>>>> Since we cannot put this information into the >>>>> >>>>> various scm plugins (because >>>>>>> >>>>>>> of a 'definition
Re: [DISCUSS] SCM child-project URL composition
I have some perhaps minor bad news about attributes. Attributes on the 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 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
Re: [DISCUSS] SCM child-project URL composition
> Is it as simple as that for all SCMs? Yes it is. Remember the old days: this is only a fix for a 'fix'. Originally the SCM URLs haven't been changed for child modules. This 'feature' only got introduce later to make life easier for SVN and CVS users (the vast majority of projects back then). What we now do is to disable this 'feature' (which now got a known and expected default behaviour) in some certain cases. Not more not less. I honestly fear of doing some magic with the SCM Urls because those are NOT native urls but get interpreted by the SCM providers. Thus the 'url adaptors' would need to 100% match the specific scm providers. So you either ship it in the same build or you are soon doomed I fear. But as you need to ship that classes as part of a maven release, there is just no upgrade scenario and you would need to support sins for a long time... The 2nd nice benefit: I'm currently digging into the attribute stuff in Modello. If this works out, we can use this approach for other long awaited features (like the mixins) in a pom-4.0.0 compatible way! LieGrue, strub --- On Fri, 7/29/11, Jason van Zyl wrote: > From: Jason van Zyl > Subject: Re: [DISCUSS] SCM child-project URL composition > To: "Maven Developers List" > Date: Friday, July 29, 2011, 12:47 AM > > On Jul 28, 2011, at 8:31 PM, Mark Struberg wrote: > > > Of course, not having to touch the POMs is a good > thing. > > > > But I don't get the 'historic behaviour' part. Even if > you would have components in the scm-providers (which all > need to be changed), this solution would not work with older > maven version because they will simply not get injected > somewhere. > > > > Dealing with what people use today versus native > expressions in the future. The components are simple, they > could be external and use in Maven 2.x and 3.x. > > > Plus, you would need to split that code from the > scm-providers, as explained before. But maintaining them > separately, I wonder how this should scale. It must be part > of maven-core, because it must clearly be available _before_ > dependencies and even extensions are available. > > We're going to end up with a few lines of code for each > SCM. For the short term I doubt this is going to be a > problem because there are probably less than 10 to deal with > and changes could be made quickly and then they are unlikely > to change. It's not a lot of code to deal with, it can be in > Maven as it is more for POM construction than anything to do > with any particular SCM. > > > > > So basically it comes down to > > > > 1.) having a list of SCMs which must not get the > module-name appended. It imo doesn't make much difference if > you do this via a regexp or via a Java class. I think the > regexp in toolchains.mdo even would have the benefit that a > user would be able to overwrite/extend the default config if > he needs to. > > Is it as simple as that for all SCMs? > > > > > 2.) marking the url tag somehow. Either inside the URL > string with a prefix like 'absolute:' or via an xml > attribute. > > > > > > The explicit marking of URLs allows this solution to > get applied for site stuff too. The regexp/Java stuff would > not work for the site URL problematic, because there is no > information about the intention of the user in the pom atm. > > > > It would be useful to see the forms SCM URL construction > for: > > CVS > SVN > Git > Hg > Perforce > Clearcase > > And anything else that people might want. I think if it's > going to be something that must work for all cases, and > cases we cannot foresee then a simple implementation in a > component where the default implementation is component that > uses regexes that's fine, but if we're thinking of making > this pluggable then I think allowing someone to plug in > whatever logic they want would be useful. > > > LieGrue, > > strub > > > > > > --- On Fri, 7/29/11, Jason van Zyl > wrote: > > > >> From: Jason van Zyl > >> Subject: Re: [DISCUSS] SCM child-project URL > composition > >> To: "Maven Developers List" > >> Date: Friday, July 29, 2011, 12:08 AM > >> I would also propose > >> > >> C) A small bit of Java code in the form of a > component for > >> each SCM type and inject those into the > inheritance > >> assembler to deal with the URLs. Then no need is > required in > >> the POM, and we can also look at the version of > Maven if we > >> want to mimic histori
Re: [DISCUSS] SCM child-project URL composition
On Jul 28, 2011, at 8:31 PM, Mark Struberg wrote: > Of course, not having to touch the POMs is a good thing. > > But I don't get the 'historic behaviour' part. Even if you would have > components in the scm-providers (which all need to be changed), this solution > would not work with older maven version because they will simply not get > injected somewhere. > Dealing with what people use today versus native expressions in the future. The components are simple, they could be external and use in Maven 2.x and 3.x. > Plus, you would need to split that code from the scm-providers, as explained > before. But maintaining them separately, I wonder how this should scale. It > must be part of maven-core, because it must clearly be available _before_ > dependencies and even extensions are available. We're going to end up with a few lines of code for each SCM. For the short term I doubt this is going to be a problem because there are probably less than 10 to deal with and changes could be made quickly and then they are unlikely to change. It's not a lot of code to deal with, it can be in Maven as it is more for POM construction than anything to do with any particular SCM. > > So basically it comes down to > > 1.) having a list of SCMs which must not get the module-name appended. It imo > doesn't make much difference if you do this via a regexp or via a Java class. > I think the regexp in toolchains.mdo even would have the benefit that a user > would be able to overwrite/extend the default config if he needs to. Is it as simple as that for all SCMs? > > 2.) marking the url tag somehow. Either inside the URL string with a prefix > like 'absolute:' or via an xml attribute. > > > The explicit marking of URLs allows this solution to get applied for site > stuff too. The regexp/Java stuff would not work for the site URL problematic, > because there is no information about the intention of the user in the pom > atm. > It would be useful to see the forms SCM URL construction for: CVS SVN Git Hg Perforce Clearcase And anything else that people might want. I think if it's going to be something that must work for all cases, and cases we cannot foresee then a simple implementation in a component where the default implementation is component that uses regexes that's fine, but if we're thinking of making this pluggable then I think allowing someone to plug in whatever logic they want would be useful. > LieGrue, > strub > > > --- On Fri, 7/29/11, Jason van Zyl wrote: > >> From: Jason van Zyl >> Subject: Re: [DISCUSS] SCM child-project URL composition >> To: "Maven Developers List" >> Date: Friday, July 29, 2011, 12:08 AM >> I would also propose >> >> C) A small bit of Java code in the form of a component for >> each SCM type and inject those into the inheritance >> assembler to deal with the URLs. Then no need is required in >> the POM, and we can also look at the version of Maven if we >> want to mimic historic behavior. We could also try to >> simply the form we currently have to simply allow >> native expressions like: >> >> g...@github.com:sonatype/sonatype-aether.git >> >> And deal with those in the component if it's determined >> it's possible. I think this method has the advantage of >> requiring zero change to the POM, no trickery with Modello, >> can be made flexible with relation to different versions of >> Maven and will allow a progression toward using native >> expressions. It would be a bit more code but are we sure we >> can handle weirder cases like with Perforce or Clearcase >> with just absolute and relative?. If someone can hack out a >> little bit a Java code I think that's ultimately simpler >> than trying to play with regular expressions, and modello. >> >> On Jul 28, 2011, at 6:59 PM, Mark Struberg wrote: >> >>> will try that too.... >>> >>> yup, just fine too with mvn-3.0.3 and mvn-2.2.1. >>> >>> So we now have either >>> >>> A.) >>> scm:git:https://... >>> >>> or >>> B.) >>> absolute:scm:git:https://... >>> >>> Please decide folks ;) >>> >>> LieGrue, >>> strub >>> >>> --- On Thu, 7/28/11, Stephen Connolly >> wrote: >>> >>>> From: Stephen Connolly >>>> Subject: Re: [DISCUSS] SCM child-project URL >> composition >>>> To: "Maven Developers List" >>>> Date: Thursday, July 28, 2011, 10:47 PM >>>> i think modelleo allows any random >
Re: [DISCUSS] SCM child-project URL composition
Of course, not having to touch the POMs is a good thing. But I don't get the 'historic behaviour' part. Even if you would have components in the scm-providers (which all need to be changed), this solution would not work with older maven version because they will simply not get injected somewhere. Plus, you would need to split that code from the scm-providers, as explained before. But maintaining them separately, I wonder how this should scale. It must be part of maven-core, because it must clearly be available _before_ dependencies and even extensions are available. So basically it comes down to 1.) having a list of SCMs which must not get the module-name appended. It imo doesn't make much difference if you do this via a regexp or via a Java class. I think the regexp in toolchains.mdo even would have the benefit that a user would be able to overwrite/extend the default config if he needs to. 2.) marking the url tag somehow. Either inside the URL string with a prefix like 'absolute:' or via an xml attribute. The explicit marking of URLs allows this solution to get applied for site stuff too. The regexp/Java stuff would not work for the site URL problematic, because there is no information about the intention of the user in the pom atm. LieGrue, strub --- On Fri, 7/29/11, Jason van Zyl wrote: > From: Jason van Zyl > Subject: Re: [DISCUSS] SCM child-project URL composition > To: "Maven Developers List" > Date: Friday, July 29, 2011, 12:08 AM > I would also propose > > C) A small bit of Java code in the form of a component for > each SCM type and inject those into the inheritance > assembler to deal with the URLs. Then no need is required in > the POM, and we can also look at the version of Maven if we > want to mimic historic behavior. We could also try to > simply the form we currently have to simply allow > native expressions like: > > g...@github.com:sonatype/sonatype-aether.git > > And deal with those in the component if it's determined > it's possible. I think this method has the advantage of > requiring zero change to the POM, no trickery with Modello, > can be made flexible with relation to different versions of > Maven and will allow a progression toward using native > expressions. It would be a bit more code but are we sure we > can handle weirder cases like with Perforce or Clearcase > with just absolute and relative?. If someone can hack out a > little bit a Java code I think that's ultimately simpler > than trying to play with regular expressions, and modello. > > On Jul 28, 2011, at 6:59 PM, Mark Struberg wrote: > > > will try that too > > > > yup, just fine too with mvn-3.0.3 and mvn-2.2.1. > > > > So we now have either > > > > A.) > > scm:git:https://... > > > > or > > B.) > > absolute:scm:git:https://... > > > > Please decide folks ;) > > > > LieGrue, > > strub > > > > --- On Thu, 7/28/11, Stephen Connolly > wrote: > > > >> From: Stephen Connolly > >> Subject: Re: [DISCUSS] SCM child-project URL > composition > >> To: "Maven Developers List" > >> Date: Thursday, July 28, 2011, 10:47 PM > >> i think modelleo allows any random > >> attributes (as other pays them no heed... > >> not sure of ivy, and the others... but they are > likely only > >> looking at > >> dependencies... a garden problem alright) > >> > >> - 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 Jul 2011 23:38, "Benson Margulies" > >> wrote: > >>> attributes are special in XML schema. I plan > to check > >> and see if pom > >>> 4.0 really precludes unqualified attributes. > >>> > >>> On Jul 28, 2011, at 6:26 PM, John Casey > >> wrote: > >>> > >>>> > >>>> > >>>> On 7/28/11 6:12 PM, Mark Struberg wrote: > >>>>> Hi and txs 4 looking through the > proposal! > >>>>> > >>>>> is a neat > idea but > >> sadly requires us to change the > >> pom-4.0 schema. So I fear this is a no-go atm. > >>>>> > >>>>> I'm not sure if there is lots of code > which > >> parses the content of the > >> urls manually. It's not guaranteed what it > contains, and we > >> already apply &g
Re: [DISCUSS] SCM child-project URL composition
I would also propose C) A small bit of Java code in the form of a component for each SCM type and inject those into the inheritance assembler to deal with the URLs. Then no need is required in the POM, and we can also look at the version of Maven if we want to mimic historic behavior. We could also try to simply the form we currently have to simply allow native expressions like: g...@github.com:sonatype/sonatype-aether.git And deal with those in the component if it's determined it's possible. I think this method has the advantage of requiring zero change to the POM, no trickery with Modello, can be made flexible with relation to different versions of Maven and will allow a progression toward using native expressions. It would be a bit more code but are we sure we can handle weirder cases like with Perforce or Clearcase with just absolute and relative?. If someone can hack out a little bit a Java code I think that's ultimately simpler than trying to play with regular expressions, and modello. On Jul 28, 2011, at 6:59 PM, Mark Struberg wrote: > will try that too > > yup, just fine too with mvn-3.0.3 and mvn-2.2.1. > > So we now have either > > A.) > scm:git:https://... > > or > B.) > absolute:scm:git:https://... > > Please decide folks ;) > > LieGrue, > strub > > --- On Thu, 7/28/11, Stephen Connolly wrote: > >> From: Stephen Connolly >> Subject: Re: [DISCUSS] SCM child-project URL composition >> To: "Maven Developers List" >> Date: Thursday, July 28, 2011, 10:47 PM >> i think modelleo allows any random >> attributes (as other pays them no heed... >> not sure of ivy, and the others... but they are likely only >> looking at >> dependencies... a garden problem alright) >> >> - 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 Jul 2011 23:38, "Benson Margulies" >> wrote: >>> attributes are special in XML schema. I plan to check >> and see if pom >>> 4.0 really precludes unqualified attributes. >>> >>> On Jul 28, 2011, at 6:26 PM, John Casey >> wrote: >>> >>>> >>>> >>>> On 7/28/11 6:12 PM, Mark Struberg wrote: >>>>> Hi and txs 4 looking through the proposal! >>>>> >>>>> is a neat idea but >> sadly requires us to change the >> pom-4.0 schema. So I fear this is a no-go atm. >>>>> >>>>> I'm not sure if there is lots of code which >> parses the content of the >> urls manually. It's not guaranteed what it contains, and we >> already apply >> _lots_ of magic to those URLs (property expansion, etc). So >> anyone which >> does not use our stuff is on his own anyway. Actually the >> content is still a >> valid URL in the sense of RFC-1738. But it's our own >> protocol now ;) >>>>> >>>>> Just my $0.02 >>>>> >>>>> LieGrue, >>>>> strub >>>>> >>>>> PS: I really like the 'absolute:' protocol >> name Robert proposed (instead >> of 'static:'. >>>> >>>> +1 >>>> >>>>> >>>>> --- On Thu, 7/28/11, Benson Margulies >> wrote: >>>>> >>>>>> From: Benson Margulies >>>>>> Subject: Re: [DISCUSS] SCM child-project >> URL composition >>>>>> To: "Maven Developers List" >>>>>> Date: Thursday, July 28, 2011, 10:01 PM >>>>>> As well I know from MSITE-600. >>>>>> However, now I'm confused: you >>>>>> couldn't use the static business with >>>>>> /project/distributionManagement/site/url, >> since those are >>>>>> naked urls. >>>>>> The proposal above is not scm:static:, >> it's static:scm:. >>>>>> are you >>>>>> suggesting putting static:http: in >>>>>> /project/distributionManagement/site/url? >> That looks >>>>>> like a problem >>>>>> for anything that parses the pom and >> doesn't use the model >>>>>> code, and I >>>>>> thought we felt precluded from busting >> things like this. >>>>>> >>>>>> Yet Another Alternative: >>>>>> >>>>>> >
Re: [DISCUSS] SCM child-project URL composition
we already have the plugin config inheritance attributes in modello. On Jul 28, 2011, at 7:27 PM, Stephen Connolly wrote: > well the questions we need to ask then are: > > does modelleo now support attributes so we can read it out > > does this make a precident > > - 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 29 Jul 2011 00:06, "John Casey" wrote: >> Since the attributes work, let's go with that. It's cleaner than a >> mangled URL, IMO. That's my vote, anyway. >> >> -john >> >> On 7/28/11 6:59 PM, Mark Struberg wrote: >>> will try that too >>> >>> yup, just fine too with mvn-3.0.3 and mvn-2.2.1. >>> >>> So we now have either >>> >>> A.) >>> scm:git:https://... >>> >>> or >>> B.) >>> absolute:scm:git:https://... >>> >>> Please decide folks ;) >>> >>> LieGrue, >>> strub >>> >>> --- On Thu, 7/28/11, Stephen Connolly > wrote: >>> >>>> From: Stephen Connolly >>>> Subject: Re: [DISCUSS] SCM child-project URL composition >>>> To: "Maven Developers List" >>>> Date: Thursday, July 28, 2011, 10:47 PM >>>> i think modelleo allows any random >>>> attributes (as other pays them no heed... >>>> not sure of ivy, and the others... but they are likely only >>>> looking at >>>> dependencies... a garden problem alright) >>>> >>>> - 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 Jul 2011 23:38, "Benson Margulies" >>>> wrote: >>>>> attributes are special in XML schema. I plan to check >>>> and see if pom >>>>> 4.0 really precludes unqualified attributes. >>>>> >>>>> On Jul 28, 2011, at 6:26 PM, John Casey >>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On 7/28/11 6:12 PM, Mark Struberg wrote: >>>>>>> Hi and txs 4 looking through the proposal! >>>>>>> >>>>>>> is a neat idea but >>>> sadly requires us to change the >>>> pom-4.0 schema. So I fear this is a no-go atm. >>>>>>> >>>>>>> I'm not sure if there is lots of code which >>>> parses the content of the >>>> urls manually. It's not guaranteed what it contains, and we >>>> already apply >>>> _lots_ of magic to those URLs (property expansion, etc). So >>>> anyone which >>>> does not use our stuff is on his own anyway. Actually the >>>> content is still a >>>> valid URL in the sense of RFC-1738. But it's our own >>>> protocol now ;) >>>>>>> >>>>>>> Just my $0.02 >>>>>>> >>>>>>> LieGrue, >>>>>>> strub >>>>>>> >>>>>>> PS: I really like the 'absolute:' protocol >>>> name Robert proposed (instead >>>> of 'static:'. >>>>>> >>>>>> +1 >>>>>> >>>>>>> >>>>>>> --- On Thu, 7/28/11, Benson Margulies >>>> wrote: >>>>>>> >>>>>>>> From: Benson Margulies >>>>>>>> Subject: Re: [DISCUSS] SCM child-project >>>> URL composition >>>>>>>> To: "Maven Developers List" >>>>>>>> Date: Thursday, July 28, 2011, 10:01 PM >>>>>>>> As well I know from MSITE-600. >>>>>>>> However, now I'm confused: you >>>>>>>> couldn't use the static business with >>>>>>>> /project/distributionManagement/site/url, >>>> since those are >>>>>>>> naked urls. >>>>>>>> The proposal above is not scm:static:, >>>> it's static:scm:. >>>>>>>> are you >>>>>>>> suggesting putting static:http: in >>>>>>>> /project/distributionM
Re: [DISCUSS] SCM child-project URL composition
well the questions we need to ask then are: does modelleo now support attributes so we can read it out does this make a precident - 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 29 Jul 2011 00:06, "John Casey" wrote: > Since the attributes work, let's go with that. It's cleaner than a > mangled URL, IMO. That's my vote, anyway. > > -john > > On 7/28/11 6:59 PM, Mark Struberg wrote: >> will try that too >> >> yup, just fine too with mvn-3.0.3 and mvn-2.2.1. >> >> So we now have either >> >> A.) >> scm:git:https://... >> >> or >> B.) >> absolute:scm:git:https://... >> >> Please decide folks ;) >> >> LieGrue, >> strub >> >> --- On Thu, 7/28/11, Stephen Connolly wrote: >> >>> From: Stephen Connolly >>> Subject: Re: [DISCUSS] SCM child-project URL composition >>> To: "Maven Developers List" >>> Date: Thursday, July 28, 2011, 10:47 PM >>> i think modelleo allows any random >>> attributes (as other pays them no heed... >>> not sure of ivy, and the others... but they are likely only >>> looking at >>> dependencies... a garden problem alright) >>> >>> - 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 Jul 2011 23:38, "Benson Margulies" >>> wrote: >>>> attributes are special in XML schema. I plan to check >>> and see if pom >>>> 4.0 really precludes unqualified attributes. >>>> >>>> On Jul 28, 2011, at 6:26 PM, John Casey >>> wrote: >>>> >>>>> >>>>> >>>>> On 7/28/11 6:12 PM, Mark Struberg wrote: >>>>>> Hi and txs 4 looking through the proposal! >>>>>> >>>>>> is a neat idea but >>> sadly requires us to change the >>> pom-4.0 schema. So I fear this is a no-go atm. >>>>>> >>>>>> I'm not sure if there is lots of code which >>> parses the content of the >>> urls manually. It's not guaranteed what it contains, and we >>> already apply >>> _lots_ of magic to those URLs (property expansion, etc). So >>> anyone which >>> does not use our stuff is on his own anyway. Actually the >>> content is still a >>> valid URL in the sense of RFC-1738. But it's our own >>> protocol now ;) >>>>>> >>>>>> Just my $0.02 >>>>>> >>>>>> LieGrue, >>>>>> strub >>>>>> >>>>>> PS: I really like the 'absolute:' protocol >>> name Robert proposed (instead >>> of 'static:'. >>>>> >>>>> +1 >>>>> >>>>>> >>>>>> --- On Thu, 7/28/11, Benson Margulies >>> wrote: >>>>>> >>>>>>> From: Benson Margulies >>>>>>> Subject: Re: [DISCUSS] SCM child-project >>> URL composition >>>>>>> To: "Maven Developers List" >>>>>>> Date: Thursday, July 28, 2011, 10:01 PM >>>>>>> As well I know from MSITE-600. >>>>>>> However, now I'm confused: you >>>>>>> couldn't use the static business with >>>>>>> /project/distributionManagement/site/url, >>> since those are >>>>>>> naked urls. >>>>>>> The proposal above is not scm:static:, >>> it's static:scm:. >>>>>>> are you >>>>>>> suggesting putting static:http: in >>>>>>> /project/distributionManagement/site/url? >>> That looks >>>>>>> like a problem >>>>>>> for anything that parses the pom and >>> doesn't use the model >>>>>>> code, and I >>>>>>> thought we felt precluded from busting >>> things like this. >>>>>>> >>>>>>> Yet Another Alternative: >>>>>>> >>>>>>> >> static='true'>what-we-have-today >>>>>>> >>>>>>> would work for
Re: [DISCUSS] SCM child-project URL composition
Since the attributes work, let's go with that. It's cleaner than a
mangled URL, IMO. That's my vote, anyway.
-john
On 7/28/11 6:59 PM, Mark Struberg wrote:
will try that too
yup, just fine too with mvn-3.0.3 and mvn-2.2.1.
So we now have either
A.)
scm:git:https://...
or
B.)
absolute:scm:git:https://...
Please decide folks ;)
LieGrue,
strub
--- On Thu, 7/28/11, Stephen Connolly wrote:
From: Stephen Connolly
Subject: Re: [DISCUSS] SCM child-project URL composition
To: "Maven Developers List"
Date: Thursday, July 28, 2011, 10:47 PM
i think modelleo allows any random
attributes (as other pays them no heed...
not sure of ivy, and the others... but they are likely only
looking at
dependencies... a garden problem alright)
- 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 Jul 2011 23:38, "Benson Margulies"
wrote:
attributes are special in XML schema. I plan to check
and see if pom
4.0 really precludes unqualified attributes.
On Jul 28, 2011, at 6:26 PM, John Casey
wrote:
On 7/28/11 6:12 PM, Mark Struberg wrote:
Hi and txs 4 looking through the proposal!
is a neat idea but
sadly requires us to change the
pom-4.0 schema. So I fear this is a no-go atm.
I'm not sure if there is lots of code which
parses the content of the
urls manually. It's not guaranteed what it contains, and we
already apply
_lots_ of magic to those URLs (property expansion, etc). So
anyone which
does not use our stuff is on his own anyway. Actually the
content is still a
valid URL in the sense of RFC-1738. But it's our own
protocol now ;)
Just my $0.02
LieGrue,
strub
PS: I really like the 'absolute:' protocol
name Robert proposed (instead
of 'static:'.
+1
--- On Thu, 7/28/11, Benson Margulies
wrote:
From: Benson Margulies
Subject: Re: [DISCUSS] SCM child-project
URL composition
To: "Maven Developers List"
Date: Thursday, July 28, 2011, 10:01 PM
As well I know from MSITE-600.
However, now I'm confused: you
couldn't use the static business with
/project/distributionManagement/site/url,
since those are
naked urls.
The proposal above is not scm:static:,
it's static:scm:.
are you
suggesting putting static:http: in
/project/distributionManagement/site/url?
That looks
like a problem
for anything that parses the pom and
doesn't use the model
code, and I
thought we felt precluded from busting
things like this.
Yet Another Alternative:
static='true'>what-we-have-today
would work for scm and also for websites.
In my opinion,
the
'disconnected parent' issue has to be
fully taken on board,
and that
really calls for
inherit='false'>what-we-have-today
which would be a good thing for the
overall ASF pom.
On Thu, Jul 28, 2011 at 5:50 PM, John
Casey
wrote:
using scm2: you're not able to apply
the solution to
website urls, etc.
which have a similar
inheritance/calculation
problem...
On 7/28/11 5:45 PM, Benson Margulies
wrote:
Is static: really superior to
scm2: and then more
colons allowing
arbitrary keyword-value pairs?
On Thu, Jul 28, 2011 at 5:44 PM,
Mark
Struberg
wrote:
Hi!
A small update:
Benjamin mentioned that this
might also be
useful for site URLs if a user
like to define the effective
URLs of the
sub-module site via
${project.version}/${project.artifactId} or
similar.
So we just came up with
"static:" as prefix.
More soon via Jira.
LieGrue,
strub
--- On Thu, 7/28/11, Brian
Fox
wrote:
From: Brian Fox
Subject: Re: [DISCUSS] SCM
child-project
URL composition
To: "Maven Developers
List"
Date: Thursday, July 28,
2011, 9:32 PM
not crazy about the
syntax, but
generally yes i think that
makes sense.
I've long maintained that
we need
something similar for
properties to
balance between "resolve
at build time"
and "resolve at
fetch from
repo" type of issues.
On Thu, Jul 28, 2011 at
3:37 PM, Mark
Struberg
wrote:
Hi John, Brian
Just to make sure I
did understand
that correctly:
you propose to use a
special URL
prefix to tell the
maven
DefaultProjectBuilder to treat those
urls as static.
An example:
staticscm:git:ssh://myserver:/..
resulting in replacing
'staticscm'
with 'scm' and not
adding the child modules
to the URL.
Did I get this
correctly?
Tried that with
mvn-3.0.3 and
mvn-2.2.1 and a standard
build works just fine. Of
course a release
would only work
with the newer maven
versions!
LieGrue,
strub
--- On Thu, 7/28/11,
Brian Fox
wrote:
From: Brian
Fox
Subject: Re:
[DISCUSS] SCM
child-project URL
composition
To: "Maven
Developers List"
Date: Thursday,
July 28, 2011,
7:23 PM
On Thu, Jul 28,
2011 at 2:59 PM,
John
Casey
Re: [DISCUSS] SCM child-project URL composition
will try that too yup, just fine too with mvn-3.0.3 and mvn-2.2.1. So we now have either A.) scm:git:https://... or B.) absolute:scm:git:https://... Please decide folks ;) LieGrue, strub --- On Thu, 7/28/11, Stephen Connolly wrote: > From: Stephen Connolly > Subject: Re: [DISCUSS] SCM child-project URL composition > To: "Maven Developers List" > Date: Thursday, July 28, 2011, 10:47 PM > i think modelleo allows any random > attributes (as other pays them no heed... > not sure of ivy, and the others... but they are likely only > looking at > dependencies... a garden problem alright) > > - 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 Jul 2011 23:38, "Benson Margulies" > wrote: > > attributes are special in XML schema. I plan to check > and see if pom > > 4.0 really precludes unqualified attributes. > > > > On Jul 28, 2011, at 6:26 PM, John Casey > wrote: > > > >> > >> > >> On 7/28/11 6:12 PM, Mark Struberg wrote: > >>> Hi and txs 4 looking through the proposal! > >>> > >>> is a neat idea but > sadly requires us to change the > pom-4.0 schema. So I fear this is a no-go atm. > >>> > >>> I'm not sure if there is lots of code which > parses the content of the > urls manually. It's not guaranteed what it contains, and we > already apply > _lots_ of magic to those URLs (property expansion, etc). So > anyone which > does not use our stuff is on his own anyway. Actually the > content is still a > valid URL in the sense of RFC-1738. But it's our own > protocol now ;) > >>> > >>> Just my $0.02 > >>> > >>> LieGrue, > >>> strub > >>> > >>> PS: I really like the 'absolute:' protocol > name Robert proposed (instead > of 'static:'. > >> > >> +1 > >> > >>> > >>> --- On Thu, 7/28/11, Benson Margulies > wrote: > >>> > >>>> From: Benson Margulies > >>>> Subject: Re: [DISCUSS] SCM child-project > URL composition > >>>> To: "Maven Developers List" > >>>> Date: Thursday, July 28, 2011, 10:01 PM > >>>> As well I know from MSITE-600. > >>>> However, now I'm confused: you > >>>> couldn't use the static business with > >>>> /project/distributionManagement/site/url, > since those are > >>>> naked urls. > >>>> The proposal above is not scm:static:, > it's static:scm:. > >>>> are you > >>>> suggesting putting static:http: in > >>>> /project/distributionManagement/site/url? > That looks > >>>> like a problem > >>>> for anything that parses the pom and > doesn't use the model > >>>> code, and I > >>>> thought we felt precluded from busting > things like this. > >>>> > >>>> Yet Another Alternative: > >>>> > >>>> static='true'>what-we-have-today > >>>> > >>>> would work for scm and also for websites. > In my opinion, > >>>> the > >>>> 'disconnected parent' issue has to be > fully taken on board, > >>>> and that > >>>> really calls for > >>>> > >>>> >>>> > inherit='false'>what-we-have-today > >>>> > >>>> which would be a good thing for the > overall ASF pom. > >>>> > >>>> > >>>> On Thu, Jul 28, 2011 at 5:50 PM, John > Casey > >>>> wrote: > >>>>> using scm2: you're not able to apply > the solution to > >>>> website urls, etc. > >>>>> which have a similar > inheritance/calculation > >>>> problem... > >>>>> > >>>>> On 7/28/11 5:45 PM, Benson Margulies > wrote: > >>>>>> > >>>>>> Is static: really superior to > scm2: and then more > >>>> colons allowing > >>>>>> arbitrary keyword-value pairs? > >>>>>> > >>>>>> On Thu, Jul 28, 2011 at 5:44 PM, > Mark > >>>> Struberg > >>>> wrote: > >>>>>>> > >>>>>>> Hi! > >>>>
Re: [DISCUSS] SCM child-project URL composition
i think modelleo allows any random attributes (as other pays them no heed...
not sure of ivy, and the others... but they are likely only looking at
dependencies... a garden problem alright)
- 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 Jul 2011 23:38, "Benson Margulies" wrote:
> attributes are special in XML schema. I plan to check and see if pom
> 4.0 really precludes unqualified attributes.
>
> On Jul 28, 2011, at 6:26 PM, John Casey wrote:
>
>>
>>
>> On 7/28/11 6:12 PM, Mark Struberg wrote:
>>> Hi and txs 4 looking through the proposal!
>>>
>>> is a neat idea but sadly requires us to change the
pom-4.0 schema. So I fear this is a no-go atm.
>>>
>>> I'm not sure if there is lots of code which parses the content of the
urls manually. It's not guaranteed what it contains, and we already apply
_lots_ of magic to those URLs (property expansion, etc). So anyone which
does not use our stuff is on his own anyway. Actually the content is still a
valid URL in the sense of RFC-1738. But it's our own protocol now ;)
>>>
>>> Just my $0.02
>>>
>>> LieGrue,
>>> strub
>>>
>>> PS: I really like the 'absolute:' protocol name Robert proposed (instead
of 'static:'.
>>
>> +1
>>
>>>
>>> --- On Thu, 7/28/11, Benson Margulies wrote:
>>>
>>>> From: Benson Margulies
>>>> Subject: Re: [DISCUSS] SCM child-project URL composition
>>>> To: "Maven Developers List"
>>>> Date: Thursday, July 28, 2011, 10:01 PM
>>>> As well I know from MSITE-600.
>>>> However, now I'm confused: you
>>>> couldn't use the static business with
>>>> /project/distributionManagement/site/url, since those are
>>>> naked urls.
>>>> The proposal above is not scm:static:, it's static:scm:.
>>>> are you
>>>> suggesting putting static:http: in
>>>> /project/distributionManagement/site/url? That looks
>>>> like a problem
>>>> for anything that parses the pom and doesn't use the model
>>>> code, and I
>>>> thought we felt precluded from busting things like this.
>>>>
>>>> Yet Another Alternative:
>>>>
>>>> what-we-have-today
>>>>
>>>> would work for scm and also for websites. In my opinion,
>>>> the
>>>> 'disconnected parent' issue has to be fully taken on board,
>>>> and that
>>>> really calls for
>>>>
>>>> >>> inherit='false'>what-we-have-today
>>>>
>>>> which would be a good thing for the overall ASF pom.
>>>>
>>>>
>>>> On Thu, Jul 28, 2011 at 5:50 PM, John Casey
>>>> wrote:
>>>>> using scm2: you're not able to apply the solution to
>>>> website urls, etc.
>>>>> which have a similar inheritance/calculation
>>>> problem...
>>>>>
>>>>> On 7/28/11 5:45 PM, Benson Margulies wrote:
>>>>>>
>>>>>> Is static: really superior to scm2: and then more
>>>> colons allowing
>>>>>> arbitrary keyword-value pairs?
>>>>>>
>>>>>> On Thu, Jul 28, 2011 at 5:44 PM, Mark
>>>> Struberg
>>>> wrote:
>>>>>>>
>>>>>>> Hi!
>>>>>>>
>>>>>>> A small update:
>>>>>>>
>>>>>>> Benjamin mentioned that this might also be
>>>> useful for site URLs if a user
>>>>>>> like to define the effective URLs of the
>>>> sub-module site via
>>>>>>> ${project.version}/${project.artifactId} or
>>>> similar.
>>>>>>>
>>>>>>> So we just came up with "static:" as prefix.
>>>>>>>
>>>>>>> More soon via Jira.
>>>>>>>
>>>>>>> LieGrue,
>>>>>>> strub
>>>>>>>
>>>>>>> --- On Thu, 7/28/11, Brian Fox
>>>> wrote:
>>>>>>>
>>>>>>>> From: Brian Fox
>>>>>>>> Subject: Re: [DISCUSS] SCM child-project
>>>> URL composition
>>>>>>>> To: "Maven Developers List&q
Re: [DISCUSS] SCM child-project URL composition
attributes are special in XML schema. I plan to check and see if pom
4.0 really precludes unqualified attributes.
On Jul 28, 2011, at 6:26 PM, John Casey wrote:
>
>
> On 7/28/11 6:12 PM, Mark Struberg wrote:
>> Hi and txs 4 looking through the proposal!
>>
>> is a neat idea but sadly requires us to change the
>> pom-4.0 schema. So I fear this is a no-go atm.
>>
>> I'm not sure if there is lots of code which parses the content of the urls
>> manually. It's not guaranteed what it contains, and we already apply _lots_
>> of magic to those URLs (property expansion, etc). So anyone which does not
>> use our stuff is on his own anyway. Actually the content is still a valid
>> URL in the sense of RFC-1738. But it's our own protocol now ;)
>>
>> Just my $0.02
>>
>> LieGrue,
>> strub
>>
>> PS: I really like the 'absolute:' protocol name Robert proposed (instead of
>> 'static:'.
>
> +1
>
>>
>> --- On Thu, 7/28/11, Benson Margulies wrote:
>>
>>> From: Benson Margulies
>>> Subject: Re: [DISCUSS] SCM child-project URL composition
>>> To: "Maven Developers List"
>>> Date: Thursday, July 28, 2011, 10:01 PM
>>> As well I know from MSITE-600.
>>> However, now I'm confused: you
>>> couldn't use the static business with
>>> /project/distributionManagement/site/url, since those are
>>> naked urls.
>>> The proposal above is not scm:static:, it's static:scm:.
>>> are you
>>> suggesting putting static:http: in
>>> /project/distributionManagement/site/url? That looks
>>> like a problem
>>> for anything that parses the pom and doesn't use the model
>>> code, and I
>>> thought we felt precluded from busting things like this.
>>>
>>> Yet Another Alternative:
>>>
>>> what-we-have-today
>>>
>>> would work for scm and also for websites. In my opinion,
>>> the
>>> 'disconnected parent' issue has to be fully taken on board,
>>> and that
>>> really calls for
>>>
>>> >> inherit='false'>what-we-have-today
>>>
>>> which would be a good thing for the overall ASF pom.
>>>
>>>
>>> On Thu, Jul 28, 2011 at 5:50 PM, John Casey
>>> wrote:
>>>> using scm2: you're not able to apply the solution to
>>> website urls, etc.
>>>> which have a similar inheritance/calculation
>>> problem...
>>>>
>>>> On 7/28/11 5:45 PM, Benson Margulies wrote:
>>>>>
>>>>> Is static: really superior to scm2: and then more
>>> colons allowing
>>>>> arbitrary keyword-value pairs?
>>>>>
>>>>> On Thu, Jul 28, 2011 at 5:44 PM, Mark
>>> Struberg
>>> wrote:
>>>>>>
>>>>>> Hi!
>>>>>>
>>>>>> A small update:
>>>>>>
>>>>>> Benjamin mentioned that this might also be
>>> useful for site URLs if a user
>>>>>> like to define the effective URLs of the
>>> sub-module site via
>>>>>> ${project.version}/${project.artifactId} or
>>> similar.
>>>>>>
>>>>>> So we just came up with "static:" as prefix.
>>>>>>
>>>>>> More soon via Jira.
>>>>>>
>>>>>> LieGrue,
>>>>>> strub
>>>>>>
>>>>>> --- On Thu, 7/28/11, Brian Fox
>>> wrote:
>>>>>>
>>>>>>> From: Brian Fox
>>>>>>> Subject: Re: [DISCUSS] SCM child-project
>>> URL composition
>>>>>>> To: "Maven Developers List"
>>>>>>> Date: Thursday, July 28, 2011, 9:32 PM
>>>>>>> not crazy about the syntax, but
>>>>>>> generally yes i think that makes sense.
>>>>>>>
>>>>>>> I've long maintained that we need
>>> something similar for
>>>>>>> properties to
>>>>>>> balance between "resolve at build time"
>>> and "resolve at
>>>>>>> fetch from
>>>>>>> repo" type of issues.
>>>>>>>
>>>>>>> On Thu, Jul 28, 2011 at 3:37 PM, Mark
>>> Struberg
>>>>>>> wrote:
>>>>>>>>
Re: [DISCUSS] SCM child-project URL composition
On 7/28/11 6:12 PM, Mark Struberg wrote:
Hi and txs 4 looking through the proposal!
is a neat idea but sadly requires us to change the pom-4.0
schema. So I fear this is a no-go atm.
I'm not sure if there is lots of code which parses the content of the urls
manually. It's not guaranteed what it contains, and we already apply _lots_ of
magic to those URLs (property expansion, etc). So anyone which does not use our
stuff is on his own anyway. Actually the content is still a valid URL in the
sense of RFC-1738. But it's our own protocol now ;)
Just my $0.02
LieGrue,
strub
PS: I really like the 'absolute:' protocol name Robert proposed (instead of
'static:'.
+1
--- On Thu, 7/28/11, Benson Margulies wrote:
From: Benson Margulies
Subject: Re: [DISCUSS] SCM child-project URL composition
To: "Maven Developers List"
Date: Thursday, July 28, 2011, 10:01 PM
As well I know from MSITE-600.
However, now I'm confused: you
couldn't use the static business with
/project/distributionManagement/site/url, since those are
naked urls.
The proposal above is not scm:static:, it's static:scm:.
are you
suggesting putting static:http: in
/project/distributionManagement/site/url? That looks
like a problem
for anything that parses the pom and doesn't use the model
code, and I
thought we felt precluded from busting things like this.
Yet Another Alternative:
what-we-have-today
would work for scm and also for websites. In my opinion,
the
'disconnected parent' issue has to be fully taken on board,
and that
really calls for
what-we-have-today
which would be a good thing for the overall ASF pom.
On Thu, Jul 28, 2011 at 5:50 PM, John Casey
wrote:
using scm2: you're not able to apply the solution to
website urls, etc.
which have a similar inheritance/calculation
problem...
On 7/28/11 5:45 PM, Benson Margulies wrote:
Is static: really superior to scm2: and then more
colons allowing
arbitrary keyword-value pairs?
On Thu, Jul 28, 2011 at 5:44 PM, Mark
Struberg
wrote:
Hi!
A small update:
Benjamin mentioned that this might also be
useful for site URLs if a user
like to define the effective URLs of the
sub-module site via
${project.version}/${project.artifactId} or
similar.
So we just came up with "static:" as prefix.
More soon via Jira.
LieGrue,
strub
--- On Thu, 7/28/11, Brian Fox
wrote:
From: Brian Fox
Subject: Re: [DISCUSS] SCM child-project
URL composition
To: "Maven Developers List"
Date: Thursday, July 28, 2011, 9:32 PM
not crazy about the syntax, but
generally yes i think that makes sense.
I've long maintained that we need
something similar for
properties to
balance between "resolve at build time"
and "resolve at
fetch from
repo" type of issues.
On Thu, Jul 28, 2011 at 3:37 PM, Mark
Struberg
wrote:
Hi John, Brian
Just to make sure I did understand
that correctly:
you propose to use a special URL
prefix to tell the
maven DefaultProjectBuilder to treat those
urls as static.
An example:
staticscm:git:ssh://myserver:/..
resulting in replacing 'staticscm'
with 'scm' and not
adding the child modules to the URL.
Did I get this correctly?
Tried that with mvn-3.0.3 and
mvn-2.2.1 and a standard
build works just fine. Of course a release
would only work
with the newer maven versions!
LieGrue,
strub
--- On Thu, 7/28/11, Brian Fox
wrote:
From: Brian Fox
Subject: Re: [DISCUSS] SCM
child-project URL
composition
To: "Maven Developers List"
Date: Thursday, July 28, 2011,
7:23 PM
On Thu, Jul 28, 2011 at 2:59 PM,
John
Casey
wrote:
Would it be better to have a
syntax to mark a
URL as
literal, not to be
calculated or used as the
basis of
calculation?
Yes. I tried to fix this behavior
for urls back in
~2.0.6/7
ish and it
broke lots of stuff that depended
upon that
behavior.
That way, we don't have to
worry about
adjusting to
new SCMs or other places
where we want to use it...new
SCMs could be
added via
build extension, IIRC,
so this is particularly
important there.
WDYT?
On 7/28/11 12:46 PM, Mark
Struberg wrote:
Hi!
problem description
---
SCM URLs currently
automatically get
extended for
child modules.
E.g. from
svn://mycompany.com/myproject
in the parent pom, a child
module
'frontend' will
result in getting a SCM
URL
svn://mycompany.com/myproject/frontend
This is fine for SVN and
CVS, but broken
for GIT,
HG, etc because the SCM
URL is 'static' for them.
proposal
---
Since we cannot put this
information into
the
various scm plugins (because
of a 'definition cycle' as
explained here
[1]) we
could split the URL
construction into
scmUrlAppendChild=true/false and
make it configurable. The
configuration could be
controlled via a
Mode
Re: [DISCUSS] SCM child-project URL composition
Hi and txs 4 looking through the proposal!
is a neat idea but sadly requires us to change the pom-4.0
schema. So I fear this is a no-go atm.
I'm not sure if there is lots of code which parses the content of the urls
manually. It's not guaranteed what it contains, and we already apply _lots_ of
magic to those URLs (property expansion, etc). So anyone which does not use our
stuff is on his own anyway. Actually the content is still a valid URL in the
sense of RFC-1738. But it's our own protocol now ;)
Just my $0.02
LieGrue,
strub
PS: I really like the 'absolute:' protocol name Robert proposed (instead of
'static:'.
--- On Thu, 7/28/11, Benson Margulies wrote:
> From: Benson Margulies
> Subject: Re: [DISCUSS] SCM child-project URL composition
> To: "Maven Developers List"
> Date: Thursday, July 28, 2011, 10:01 PM
> As well I know from MSITE-600.
> However, now I'm confused: you
> couldn't use the static business with
> /project/distributionManagement/site/url, since those are
> naked urls.
> The proposal above is not scm:static:, it's static:scm:.
> are you
> suggesting putting static:http: in
> /project/distributionManagement/site/url? That looks
> like a problem
> for anything that parses the pom and doesn't use the model
> code, and I
> thought we felt precluded from busting things like this.
>
> Yet Another Alternative:
>
> what-we-have-today
>
> would work for scm and also for websites. In my opinion,
> the
> 'disconnected parent' issue has to be fully taken on board,
> and that
> really calls for
>
> inherit='false'>what-we-have-today
>
> which would be a good thing for the overall ASF pom.
>
>
> On Thu, Jul 28, 2011 at 5:50 PM, John Casey
> wrote:
> > using scm2: you're not able to apply the solution to
> website urls, etc.
> > which have a similar inheritance/calculation
> problem...
> >
> > On 7/28/11 5:45 PM, Benson Margulies wrote:
> >>
> >> Is static: really superior to scm2: and then more
> colons allowing
> >> arbitrary keyword-value pairs?
> >>
> >> On Thu, Jul 28, 2011 at 5:44 PM, Mark
> Struberg
> wrote:
> >>>
> >>> Hi!
> >>>
> >>> A small update:
> >>>
> >>> Benjamin mentioned that this might also be
> useful for site URLs if a user
> >>> like to define the effective URLs of the
> sub-module site via
> >>> ${project.version}/${project.artifactId} or
> similar.
> >>>
> >>> So we just came up with "static:" as prefix.
> >>>
> >>> More soon via Jira.
> >>>
> >>> LieGrue,
> >>> strub
> >>>
> >>> --- On Thu, 7/28/11, Brian Fox
> wrote:
> >>>
> >>>> From: Brian Fox
> >>>> Subject: Re: [DISCUSS] SCM child-project
> URL composition
> >>>> To: "Maven Developers List"
> >>>> Date: Thursday, July 28, 2011, 9:32 PM
> >>>> not crazy about the syntax, but
> >>>> generally yes i think that makes sense.
> >>>>
> >>>> I've long maintained that we need
> something similar for
> >>>> properties to
> >>>> balance between "resolve at build time"
> and "resolve at
> >>>> fetch from
> >>>> repo" type of issues.
> >>>>
> >>>> On Thu, Jul 28, 2011 at 3:37 PM, Mark
> Struberg
> >>>> wrote:
> >>>>>
> >>>>> Hi John, Brian
> >>>>>
> >>>>> Just to make sure I did understand
> that correctly:
> >>>>> you propose to use a special URL
> prefix to tell the
> >>>>
> >>>> maven DefaultProjectBuilder to treat those
> urls as static.
> >>>> An example:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> staticscm:git:ssh://myserver:/.. >>>>>
> >>>>> resulting in replacing 'staticscm'
> with 'scm' and not
> >>>>
> >>>> adding the child modules to the URL.
> >>>>>
> >>>>> Did I get this correctly?
> >>>>>
> >>>>> Tried that with mvn-3.0.3 and
> mvn-2.2.1 and a standard
> >>>>
> >>>> build works just fine. Of course a release
> would only work
> >>>> with the newe
Re: [DISCUSS] SCM child-project URL composition
As well I know from MSITE-600. However, now I'm confused: you
couldn't use the static business with
/project/distributionManagement/site/url, since those are naked urls.
The proposal above is not scm:static:, it's static:scm:. are you
suggesting putting static:http: in
/project/distributionManagement/site/url? That looks like a problem
for anything that parses the pom and doesn't use the model code, and I
thought we felt precluded from busting things like this.
Yet Another Alternative:
what-we-have-today
would work for scm and also for websites. In my opinion, the
'disconnected parent' issue has to be fully taken on board, and that
really calls for
what-we-have-today
which would be a good thing for the overall ASF pom.
On Thu, Jul 28, 2011 at 5:50 PM, John Casey wrote:
> using scm2: you're not able to apply the solution to website urls, etc.
> which have a similar inheritance/calculation problem...
>
> On 7/28/11 5:45 PM, Benson Margulies wrote:
>>
>> Is static: really superior to scm2: and then more colons allowing
>> arbitrary keyword-value pairs?
>>
>> On Thu, Jul 28, 2011 at 5:44 PM, Mark Struberg wrote:
>>>
>>> Hi!
>>>
>>> A small update:
>>>
>>> Benjamin mentioned that this might also be useful for site URLs if a user
>>> like to define the effective URLs of the sub-module site via
>>> ${project.version}/${project.artifactId} or similar.
>>>
>>> So we just came up with "static:" as prefix.
>>>
>>> More soon via Jira.
>>>
>>> LieGrue,
>>> strub
>>>
>>> --- On Thu, 7/28/11, Brian Fox wrote:
>>>
>>>> From: Brian Fox
>>>> Subject: Re: [DISCUSS] SCM child-project URL composition
>>>> To: "Maven Developers List"
>>>> Date: Thursday, July 28, 2011, 9:32 PM
>>>> not crazy about the syntax, but
>>>> generally yes i think that makes sense.
>>>>
>>>> I've long maintained that we need something similar for
>>>> properties to
>>>> balance between "resolve at build time" and "resolve at
>>>> fetch from
>>>> repo" type of issues.
>>>>
>>>> On Thu, Jul 28, 2011 at 3:37 PM, Mark Struberg
>>>> wrote:
>>>>>
>>>>> Hi John, Brian
>>>>>
>>>>> Just to make sure I did understand that correctly:
>>>>> you propose to use a special URL prefix to tell the
>>>>
>>>> maven DefaultProjectBuilder to treat those urls as static.
>>>> An example:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> staticscm:git:ssh://myserver:/..>>>>
>>>>> resulting in replacing 'staticscm' with 'scm' and not
>>>>
>>>> adding the child modules to the URL.
>>>>>
>>>>> Did I get this correctly?
>>>>>
>>>>> Tried that with mvn-3.0.3 and mvn-2.2.1 and a standard
>>>>
>>>> build works just fine. Of course a release would only work
>>>> with the newer maven versions!
>>>>>
>>>>> LieGrue,
>>>>> strub
>>>>>
>>>>> --- On Thu, 7/28/11, Brian Fox
>>>>
>>>> wrote:
>>>>>
>>>>>> From: Brian Fox
>>>>>> Subject: Re: [DISCUSS] SCM child-project URL
>>>>
>>>> composition
>>>>>>
>>>>>> To: "Maven Developers List"
>>>>>> Date: Thursday, July 28, 2011, 7:23 PM
>>>>>> On Thu, Jul 28, 2011 at 2:59 PM, John
>>>>>> Casey
>>>>>> wrote:
>>>>>>>
>>>>>>> Would it be better to have a syntax to mark a
>>>>
>>>> URL as
>>>>>>
>>>>>> literal, not to be
>>>>>>>
>>>>>>> calculated or used as the basis of
>>>>
>>>> calculation?
>>>>>>>
>>>>>>
>>>>>> Yes. I tried to fix this behavior for urls back in
>>>>
>>>> ~2.0.6/7
>>>>>>
>>>>>> ish and it
>>>>>> broke lots of stuff that depended upon that
>>>>
>>>> behavior.
>>>>>>
>>>>>>> That way, we don't have to worry about
>>>>
>>>> adjusting to
>>>>
Re: [DISCUSS] SCM child-project URL composition
using scm2: you're not able to apply the solution to website urls, etc.
which have a similar inheritance/calculation problem...
On 7/28/11 5:45 PM, Benson Margulies wrote:
Is static: really superior to scm2: and then more colons allowing
arbitrary keyword-value pairs?
On Thu, Jul 28, 2011 at 5:44 PM, Mark Struberg wrote:
Hi!
A small update:
Benjamin mentioned that this might also be useful for site URLs if a user like
to define the effective URLs of the sub-module site via
${project.version}/${project.artifactId} or similar.
So we just came up with "static:" as prefix.
More soon via Jira.
LieGrue,
strub
--- On Thu, 7/28/11, Brian Fox wrote:
From: Brian Fox
Subject: Re: [DISCUSS] SCM child-project URL composition
To: "Maven Developers List"
Date: Thursday, July 28, 2011, 9:32 PM
not crazy about the syntax, but
generally yes i think that makes sense.
I've long maintained that we need something similar for
properties to
balance between "resolve at build time" and "resolve at
fetch from
repo" type of issues.
On Thu, Jul 28, 2011 at 3:37 PM, Mark Struberg
wrote:
Hi John, Brian
Just to make sure I did understand that correctly:
you propose to use a special URL prefix to tell the
maven DefaultProjectBuilder to treat those urls as static.
An example:
staticscm:git:ssh://myserver:/..
resulting in replacing 'staticscm' with 'scm' and not
adding the child modules to the URL.
Did I get this correctly?
Tried that with mvn-3.0.3 and mvn-2.2.1 and a standard
build works just fine. Of course a release would only work
with the newer maven versions!
LieGrue,
strub
--- On Thu, 7/28/11, Brian Fox
wrote:
From: Brian Fox
Subject: Re: [DISCUSS] SCM child-project URL
composition
To: "Maven Developers List"
Date: Thursday, July 28, 2011, 7:23 PM
On Thu, Jul 28, 2011 at 2:59 PM, John
Casey
wrote:
Would it be better to have a syntax to mark a
URL as
literal, not to be
calculated or used as the basis of
calculation?
Yes. I tried to fix this behavior for urls back in
~2.0.6/7
ish and it
broke lots of stuff that depended upon that
behavior.
That way, we don't have to worry about
adjusting to
new SCMs or other places
where we want to use it...new SCMs could be
added via
build extension, IIRC,
so this is particularly important there.
WDYT?
On 7/28/11 12:46 PM, Mark Struberg wrote:
Hi!
problem description
---
SCM URLs currently automatically get
extended for
child modules.
E.g. from
svn://mycompany.com/myproject
in the parent pom, a child module
'frontend' will
result in getting a SCM
URL
svn://mycompany.com/myproject/frontend
This is fine for SVN and CVS, but broken
for GIT,
HG, etc because the SCM
URL is 'static' for them.
proposal
---
Since we cannot put this information into
the
various scm plugins (because
of a 'definition cycle' as explained here
[1]) we
could split the URL
construction into
scmUrlAppendChild=true/false and
make it configurable. The
configuration could be controlled via a
Modello
config, my suggestion would
be to just add them to toolchains.mdo.
I'd just add a String property which
holds a
regular expression which
parses the SCM URL and decides upon this
whether
the appending should get
activated, e.g. for all SCMs which
contain
'scm:svn:' or 'scm:cvs:' or the
java-svn (olamy, you know the plexus key
for
that?)
If there is a better place to put that
config or a
better way to get the
info, then please speak up now :)
I think this change would be backward
compatible
and doesn't need any pom
changes. It also could easily get
back-ported to
mvn2 if needed.
Are there other URLS which also need a
similar
distinction while building
the model?
WDYT?
txs and LieGrue,
strub
[1] http://markmail.org/message/npw3hp6aloa55ctf
-
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
Re: [DISCUSS] SCM child-project URL composition
yup something like
static:scm:git:https://...
And the trailing / is rather unhandy. Some scms just crash if you don't use the
correct trailing ;)
LieGrue,
strub
--- On Thu, 7/28/11, Benson Margulies wrote:
> From: Benson Margulies
> Subject: Re: [DISCUSS] SCM child-project URL composition
> To: "Maven Developers List"
> Date: Thursday, July 28, 2011, 9:45 PM
> Is static: really superior to scm2:
> and then more colons allowing
> arbitrary keyword-value pairs?
>
> On Thu, Jul 28, 2011 at 5:44 PM, Mark Struberg
> wrote:
> > Hi!
> >
> > A small update:
> >
> > Benjamin mentioned that this might also be useful for
> site URLs if a user like to define the effective URLs of the
> sub-module site via ${project.version}/${project.artifactId}
> or similar.
> >
> > So we just came up with "static:" as prefix.
> >
> > More soon via Jira.
> >
> > LieGrue,
> > strub
> >
> > --- On Thu, 7/28/11, Brian Fox
> wrote:
> >
> >> From: Brian Fox
> >> Subject: Re: [DISCUSS] SCM child-project URL
> composition
> >> To: "Maven Developers List"
> >> Date: Thursday, July 28, 2011, 9:32 PM
> >> not crazy about the syntax, but
> >> generally yes i think that makes sense.
> >>
> >> I've long maintained that we need something
> similar for
> >> properties to
> >> balance between "resolve at build time" and
> "resolve at
> >> fetch from
> >> repo" type of issues.
> >>
> >> On Thu, Jul 28, 2011 at 3:37 PM, Mark Struberg
>
> >> wrote:
> >> > Hi John, Brian
> >> >
> >> > Just to make sure I did understand that
> correctly:
> >> > you propose to use a special URL prefix to
> tell the
> >> maven DefaultProjectBuilder to treat those urls as
> static.
> >> An example:
> >> >
> >> >
> >> >
> >> >
> >>
> staticscm:git:ssh://myserver:/.. >> >
> >> > resulting in replacing 'staticscm' with 'scm'
> and not
> >> adding the child modules to the URL.
> >> > Did I get this correctly?
> >> >
> >> > Tried that with mvn-3.0.3 and mvn-2.2.1 and a
> standard
> >> build works just fine. Of course a release would
> only work
> >> with the newer maven versions!
> >> >
> >> > LieGrue,
> >> > strub
> >> >
> >> > --- On Thu, 7/28/11, Brian Fox
> >> wrote:
> >> >
> >> >> From: Brian Fox
> >> >> Subject: Re: [DISCUSS] SCM child-project
> URL
> >> composition
> >> >> To: "Maven Developers List"
> >> >> Date: Thursday, July 28, 2011, 7:23 PM
> >> >> On Thu, Jul 28, 2011 at 2:59 PM, John
> >> >> Casey
> >> >> wrote:
> >> >> > Would it be better to have a syntax
> to mark a
> >> URL as
> >> >> literal, not to be
> >> >> > calculated or used as the basis of
> >> calculation?
> >> >> >
> >> >>
> >> >> Yes. I tried to fix this behavior for
> urls back in
> >> ~2.0.6/7
> >> >> ish and it
> >> >> broke lots of stuff that depended upon
> that
> >> behavior.
> >> >>
> >> >> > That way, we don't have to worry
> about
> >> adjusting to
> >> >> new SCMs or other places
> >> >> > where we want to use it...new SCMs
> could be
> >> added via
> >> >> build extension, IIRC,
> >> >> > so this is particularly important
> there.
> >> >> >
> >> >> > WDYT?
> >> >> >
> >> >> > On 7/28/11 12:46 PM, Mark Struberg
> wrote:
> >> >> >>
> >> >> >> Hi!
> >> >> >>
> >> >> >> problem description
> >> >> >> ---
> >> >> >>
> >> >> >> SCM URLs currently automatically
> get
> >> extended for
> >> >> child modules.
> >> >> >> E.g. from
> >> >> >> svn://mycompany.com/myproject
> >> >> >> in the parent pom, a child
> module
> >> 'frontend' will
> >> >> result in getting a SCM
> >> >> >> URL
> >> >> >>
> svn:
Re: [DISCUSS] SCM child-project URL composition
On 7/28/11 5:43 PM, Benson Margulies wrote: I keep thinking that I read about a convention that used the presence or absence of a trailing '/' on the URL to control this. Does anyone else recall this? You mean overloading an explicit URL referencing a directory? Seems a tad confusing and maybe even a problem waiting to happen... On Thu, Jul 28, 2011 at 5:32 PM, Brian Fox wrote: not crazy about the syntax, but generally yes i think that makes sense. I've long maintained that we need something similar for properties to balance between "resolve at build time" and "resolve at fetch from repo" type of issues. On Thu, Jul 28, 2011 at 3:37 PM, Mark Struberg wrote: Hi John, Brian Just to make sure I did understand that correctly: you propose to use a special URL prefix to tell the maven DefaultProjectBuilder to treat those urls as static. An example: staticscm:git:ssh://myserver:/.. wrote: From: Brian Fox Subject: Re: [DISCUSS] SCM child-project URL composition To: "Maven Developers List" Date: Thursday, July 28, 2011, 7:23 PM On Thu, Jul 28, 2011 at 2:59 PM, John Casey wrote: Would it be better to have a syntax to mark a URL as literal, not to be calculated or used as the basis of calculation? Yes. I tried to fix this behavior for urls back in ~2.0.6/7 ish and it broke lots of stuff that depended upon that behavior. That way, we don't have to worry about adjusting to new SCMs or other places where we want to use it...new SCMs could be added via build extension, IIRC, so this is particularly important there. WDYT? On 7/28/11 12:46 PM, Mark Struberg wrote: Hi! problem description --- SCM URLs currently automatically get extended for child modules. E.g. from svn://mycompany.com/myproject in the parent pom, a child module 'frontend' will result in getting a SCM URL svn://mycompany.com/myproject/frontend This is fine for SVN and CVS, but broken for GIT, HG, etc because the SCM URL is 'static' for them. proposal --- Since we cannot put this information into the various scm plugins (because of a 'definition cycle' as explained here [1]) we could split the URL construction into scmUrlAppendChild=true/false and make it configurable. The configuration could be controlled via a Modello config, my suggestion would be to just add them to toolchains.mdo. I'd just add a String property which holds a regular expression which parses the SCM URL and decides upon this whether the appending should get activated, e.g. for all SCMs which contain 'scm:svn:' or 'scm:cvs:' or the java-svn (olamy, you know the plexus key for that?) If there is a better place to put that config or a better way to get the info, then please speak up now :) I think this change would be backward compatible and doesn't need any pom changes. It also could easily get back-ported to mvn2 if needed. Are there other URLS which also need a similar distinction while building the model? WDYT? txs and LieGrue, strub [1] http://markmail.org/message/npw3hp6aloa55ctf - 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 - 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
Re: [DISCUSS] SCM child-project URL composition
Is static: really superior to scm2: and then more colons allowing
arbitrary keyword-value pairs?
On Thu, Jul 28, 2011 at 5:44 PM, Mark Struberg wrote:
> Hi!
>
> A small update:
>
> Benjamin mentioned that this might also be useful for site URLs if a user
> like to define the effective URLs of the sub-module site via
> ${project.version}/${project.artifactId} or similar.
>
> So we just came up with "static:" as prefix.
>
> More soon via Jira.
>
> LieGrue,
> strub
>
> --- On Thu, 7/28/11, Brian Fox wrote:
>
>> From: Brian Fox
>> Subject: Re: [DISCUSS] SCM child-project URL composition
>> To: "Maven Developers List"
>> Date: Thursday, July 28, 2011, 9:32 PM
>> not crazy about the syntax, but
>> generally yes i think that makes sense.
>>
>> I've long maintained that we need something similar for
>> properties to
>> balance between "resolve at build time" and "resolve at
>> fetch from
>> repo" type of issues.
>>
>> On Thu, Jul 28, 2011 at 3:37 PM, Mark Struberg
>> wrote:
>> > Hi John, Brian
>> >
>> > Just to make sure I did understand that correctly:
>> > you propose to use a special URL prefix to tell the
>> maven DefaultProjectBuilder to treat those urls as static.
>> An example:
>> >
>> >
>> >
>> >
>> staticscm:git:ssh://myserver:/..> >
>> > resulting in replacing 'staticscm' with 'scm' and not
>> adding the child modules to the URL.
>> > Did I get this correctly?
>> >
>> > Tried that with mvn-3.0.3 and mvn-2.2.1 and a standard
>> build works just fine. Of course a release would only work
>> with the newer maven versions!
>> >
>> > LieGrue,
>> > strub
>> >
>> > --- On Thu, 7/28/11, Brian Fox
>> wrote:
>> >
>> >> From: Brian Fox
>> >> Subject: Re: [DISCUSS] SCM child-project URL
>> composition
>> >> To: "Maven Developers List"
>> >> Date: Thursday, July 28, 2011, 7:23 PM
>> >> On Thu, Jul 28, 2011 at 2:59 PM, John
>> >> Casey
>> >> wrote:
>> >> > Would it be better to have a syntax to mark a
>> URL as
>> >> literal, not to be
>> >> > calculated or used as the basis of
>> calculation?
>> >> >
>> >>
>> >> Yes. I tried to fix this behavior for urls back in
>> ~2.0.6/7
>> >> ish and it
>> >> broke lots of stuff that depended upon that
>> behavior.
>> >>
>> >> > That way, we don't have to worry about
>> adjusting to
>> >> new SCMs or other places
>> >> > where we want to use it...new SCMs could be
>> added via
>> >> build extension, IIRC,
>> >> > so this is particularly important there.
>> >> >
>> >> > WDYT?
>> >> >
>> >> > On 7/28/11 12:46 PM, Mark Struberg wrote:
>> >> >>
>> >> >> Hi!
>> >> >>
>> >> >> problem description
>> >> >> ---
>> >> >>
>> >> >> SCM URLs currently automatically get
>> extended for
>> >> child modules.
>> >> >> E.g. from
>> >> >> svn://mycompany.com/myproject
>> >> >> in the parent pom, a child module
>> 'frontend' will
>> >> result in getting a SCM
>> >> >> URL
>> >> >> svn://mycompany.com/myproject/frontend
>> >> >>
>> >> >> This is fine for SVN and CVS, but broken
>> for GIT,
>> >> HG, etc because the SCM
>> >> >> URL is 'static' for them.
>> >> >>
>> >> >>
>> >> >> proposal
>> >> >> ---
>> >> >>
>> >> >> Since we cannot put this information into
>> the
>> >> various scm plugins (because
>> >> >> of a 'definition cycle' as explained here
>> [1]) we
>> >> could split the URL
>> >> >> construction into
>> scmUrlAppendChild=true/false and
>> >> make it configurable. The
>> >> >> configuration could be controlled via a
>> Modello
>> >> config, my suggestion would
>> >> >> be to just add them to toolchains.mdo.
>> >> >> I'd just add a String property which
Re: [DISCUSS] SCM child-project URL composition
Hi!
A small update:
Benjamin mentioned that this might also be useful for site URLs if a user like
to define the effective URLs of the sub-module site via
${project.version}/${project.artifactId} or similar.
So we just came up with "static:" as prefix.
More soon via Jira.
LieGrue,
strub
--- On Thu, 7/28/11, Brian Fox wrote:
> From: Brian Fox
> Subject: Re: [DISCUSS] SCM child-project URL composition
> To: "Maven Developers List"
> Date: Thursday, July 28, 2011, 9:32 PM
> not crazy about the syntax, but
> generally yes i think that makes sense.
>
> I've long maintained that we need something similar for
> properties to
> balance between "resolve at build time" and "resolve at
> fetch from
> repo" type of issues.
>
> On Thu, Jul 28, 2011 at 3:37 PM, Mark Struberg
> wrote:
> > Hi John, Brian
> >
> > Just to make sure I did understand that correctly:
> > you propose to use a special URL prefix to tell the
> maven DefaultProjectBuilder to treat those urls as static.
> An example:
> >
> >
> >
> >
> staticscm:git:ssh://myserver:/.. >
> > resulting in replacing 'staticscm' with 'scm' and not
> adding the child modules to the URL.
> > Did I get this correctly?
> >
> > Tried that with mvn-3.0.3 and mvn-2.2.1 and a standard
> build works just fine. Of course a release would only work
> with the newer maven versions!
> >
> > LieGrue,
> > strub
> >
> > --- On Thu, 7/28/11, Brian Fox
> wrote:
> >
> >> From: Brian Fox
> >> Subject: Re: [DISCUSS] SCM child-project URL
> composition
> >> To: "Maven Developers List"
> >> Date: Thursday, July 28, 2011, 7:23 PM
> >> On Thu, Jul 28, 2011 at 2:59 PM, John
> >> Casey
> >> wrote:
> >> > Would it be better to have a syntax to mark a
> URL as
> >> literal, not to be
> >> > calculated or used as the basis of
> calculation?
> >> >
> >>
> >> Yes. I tried to fix this behavior for urls back in
> ~2.0.6/7
> >> ish and it
> >> broke lots of stuff that depended upon that
> behavior.
> >>
> >> > That way, we don't have to worry about
> adjusting to
> >> new SCMs or other places
> >> > where we want to use it...new SCMs could be
> added via
> >> build extension, IIRC,
> >> > so this is particularly important there.
> >> >
> >> > WDYT?
> >> >
> >> > On 7/28/11 12:46 PM, Mark Struberg wrote:
> >> >>
> >> >> Hi!
> >> >>
> >> >> problem description
> >> >> ---
> >> >>
> >> >> SCM URLs currently automatically get
> extended for
> >> child modules.
> >> >> E.g. from
> >> >> svn://mycompany.com/myproject
> >> >> in the parent pom, a child module
> 'frontend' will
> >> result in getting a SCM
> >> >> URL
> >> >> svn://mycompany.com/myproject/frontend
> >> >>
> >> >> This is fine for SVN and CVS, but broken
> for GIT,
> >> HG, etc because the SCM
> >> >> URL is 'static' for them.
> >> >>
> >> >>
> >> >> proposal
> >> >> ---
> >> >>
> >> >> Since we cannot put this information into
> the
> >> various scm plugins (because
> >> >> of a 'definition cycle' as explained here
> [1]) we
> >> could split the URL
> >> >> construction into
> scmUrlAppendChild=true/false and
> >> make it configurable. The
> >> >> configuration could be controlled via a
> Modello
> >> config, my suggestion would
> >> >> be to just add them to toolchains.mdo.
> >> >> I'd just add a String property which
> holds a
> >> regular expression which
> >> >> parses the SCM URL and decides upon this
> whether
> >> the appending should get
> >> >> activated, e.g. for all SCMs which
> contain
> >> 'scm:svn:' or 'scm:cvs:' or the
> >> >> java-svn (olamy, you know the plexus key
> for
> >> that?)
> >> >>
> >> >> If there is a better place to put that
> config or a
> >> better way to get the
> >> >> info, then please speak up now :)
> >> >>
> >
Re: [DISCUSS] SCM child-project URL composition
I keep thinking that I read about a convention that used the presence or absence of a trailing '/' on the URL to control this. Does anyone else recall this? On Thu, Jul 28, 2011 at 5:32 PM, Brian Fox wrote: > not crazy about the syntax, but generally yes i think that makes sense. > > I've long maintained that we need something similar for properties to > balance between "resolve at build time" and "resolve at fetch from > repo" type of issues. > > On Thu, Jul 28, 2011 at 3:37 PM, Mark Struberg wrote: >> Hi John, Brian >> >> Just to make sure I did understand that correctly: >> you propose to use a special URL prefix to tell the maven >> DefaultProjectBuilder to treat those urls as static. An example: >> >> >> >> staticscm:git:ssh://myserver:/..> >> resulting in replacing 'staticscm' with 'scm' and not adding the child >> modules to the URL. >> Did I get this correctly? >> >> Tried that with mvn-3.0.3 and mvn-2.2.1 and a standard build works just >> fine. Of course a release would only work with the newer maven versions! >> >> LieGrue, >> strub >> >> --- On Thu, 7/28/11, Brian Fox wrote: >> >>> From: Brian Fox >>> Subject: Re: [DISCUSS] SCM child-project URL composition >>> To: "Maven Developers List" >>> Date: Thursday, July 28, 2011, 7:23 PM >>> On Thu, Jul 28, 2011 at 2:59 PM, John >>> Casey >>> wrote: >>> > Would it be better to have a syntax to mark a URL as >>> literal, not to be >>> > calculated or used as the basis of calculation? >>> > >>> >>> Yes. I tried to fix this behavior for urls back in ~2.0.6/7 >>> ish and it >>> broke lots of stuff that depended upon that behavior. >>> >>> > That way, we don't have to worry about adjusting to >>> new SCMs or other places >>> > where we want to use it...new SCMs could be added via >>> build extension, IIRC, >>> > so this is particularly important there. >>> > >>> > WDYT? >>> > >>> > On 7/28/11 12:46 PM, Mark Struberg wrote: >>> >> >>> >> Hi! >>> >> >>> >> problem description >>> >> --- >>> >> >>> >> SCM URLs currently automatically get extended for >>> child modules. >>> >> E.g. from >>> >> svn://mycompany.com/myproject >>> >> in the parent pom, a child module 'frontend' will >>> result in getting a SCM >>> >> URL >>> >> svn://mycompany.com/myproject/frontend >>> >> >>> >> This is fine for SVN and CVS, but broken for GIT, >>> HG, etc because the SCM >>> >> URL is 'static' for them. >>> >> >>> >> >>> >> proposal >>> >> --- >>> >> >>> >> Since we cannot put this information into the >>> various scm plugins (because >>> >> of a 'definition cycle' as explained here [1]) we >>> could split the URL >>> >> construction into scmUrlAppendChild=true/false and >>> make it configurable. The >>> >> configuration could be controlled via a Modello >>> config, my suggestion would >>> >> be to just add them to toolchains.mdo. >>> >> I'd just add a String property which holds a >>> regular expression which >>> >> parses the SCM URL and decides upon this whether >>> the appending should get >>> >> activated, e.g. for all SCMs which contain >>> 'scm:svn:' or 'scm:cvs:' or the >>> >> java-svn (olamy, you know the plexus key for >>> that?) >>> >> >>> >> If there is a better place to put that config or a >>> better way to get the >>> >> info, then please speak up now :) >>> >> >>> >> I think this change would be backward compatible >>> and doesn't need any pom >>> >> changes. It also could easily get back-ported to >>> mvn2 if needed. >>> >> Are there other URLS which also need a similar >>> distinction while building >>> >> the model? >>> >> >>> >> WDYT? >>> >> >>> >> txs and LieGrue, >>> >> strub >>> >> >>> >> [1] http://markmail.org/message/np
Re: [DISCUSS] SCM child-project URL composition
not crazy about the syntax, but generally yes i think that makes sense. I've long maintained that we need something similar for properties to balance between "resolve at build time" and "resolve at fetch from repo" type of issues. On Thu, Jul 28, 2011 at 3:37 PM, Mark Struberg wrote: > Hi John, Brian > > Just to make sure I did understand that correctly: > you propose to use a special URL prefix to tell the maven > DefaultProjectBuilder to treat those urls as static. An example: > > > > staticscm:git:ssh://myserver:/.. > resulting in replacing 'staticscm' with 'scm' and not adding the child > modules to the URL. > Did I get this correctly? > > Tried that with mvn-3.0.3 and mvn-2.2.1 and a standard build works just fine. > Of course a release would only work with the newer maven versions! > > LieGrue, > strub > > --- On Thu, 7/28/11, Brian Fox wrote: > >> From: Brian Fox >> Subject: Re: [DISCUSS] SCM child-project URL composition >> To: "Maven Developers List" >> Date: Thursday, July 28, 2011, 7:23 PM >> On Thu, Jul 28, 2011 at 2:59 PM, John >> Casey >> wrote: >> > Would it be better to have a syntax to mark a URL as >> literal, not to be >> > calculated or used as the basis of calculation? >> > >> >> Yes. I tried to fix this behavior for urls back in ~2.0.6/7 >> ish and it >> broke lots of stuff that depended upon that behavior. >> >> > That way, we don't have to worry about adjusting to >> new SCMs or other places >> > where we want to use it...new SCMs could be added via >> build extension, IIRC, >> > so this is particularly important there. >> > >> > WDYT? >> > >> > On 7/28/11 12:46 PM, Mark Struberg wrote: >> >> >> >> Hi! >> >> >> >> problem description >> >> --- >> >> >> >> SCM URLs currently automatically get extended for >> child modules. >> >> E.g. from >> >> svn://mycompany.com/myproject >> >> in the parent pom, a child module 'frontend' will >> result in getting a SCM >> >> URL >> >> svn://mycompany.com/myproject/frontend >> >> >> >> This is fine for SVN and CVS, but broken for GIT, >> HG, etc because the SCM >> >> URL is 'static' for them. >> >> >> >> >> >> proposal >> >> --- >> >> >> >> Since we cannot put this information into the >> various scm plugins (because >> >> of a 'definition cycle' as explained here [1]) we >> could split the URL >> >> construction into scmUrlAppendChild=true/false and >> make it configurable. The >> >> configuration could be controlled via a Modello >> config, my suggestion would >> >> be to just add them to toolchains.mdo. >> >> I'd just add a String property which holds a >> regular expression which >> >> parses the SCM URL and decides upon this whether >> the appending should get >> >> activated, e.g. for all SCMs which contain >> 'scm:svn:' or 'scm:cvs:' or the >> >> java-svn (olamy, you know the plexus key for >> that?) >> >> >> >> If there is a better place to put that config or a >> better way to get the >> >> info, then please speak up now :) >> >> >> >> I think this change would be backward compatible >> and doesn't need any pom >> >> changes. It also could easily get back-ported to >> mvn2 if needed. >> >> Are there other URLS which also need a similar >> distinction while building >> >> the model? >> >> >> >> WDYT? >> >> >> >> txs and LieGrue, >> >> strub >> >> >> >> [1] http://markmail.org/message/npw3hp6aloa55ctf >> >> >> >> >> - >> >> 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
Re: [DISCUSS] SCM child-project URL composition
On 7/28/11 3:37 PM, Mark Struberg wrote: Hi John, Brian Just to make sure I did understand that correctly: you propose to use a special URL prefix to tell the maven DefaultProjectBuilder to treat those urls as static. An example: staticscm:git:ssh://myserver:/.. I think that's an acceptable compromise, personally. LieGrue, strub --- On Thu, 7/28/11, Brian Fox wrote: From: Brian Fox Subject: Re: [DISCUSS] SCM child-project URL composition To: "Maven Developers List" Date: Thursday, July 28, 2011, 7:23 PM On Thu, Jul 28, 2011 at 2:59 PM, John Casey wrote: Would it be better to have a syntax to mark a URL as literal, not to be calculated or used as the basis of calculation? Yes. I tried to fix this behavior for urls back in ~2.0.6/7 ish and it broke lots of stuff that depended upon that behavior. That way, we don't have to worry about adjusting to new SCMs or other places where we want to use it...new SCMs could be added via build extension, IIRC, so this is particularly important there. WDYT? On 7/28/11 12:46 PM, Mark Struberg wrote: Hi! problem description --- SCM URLs currently automatically get extended for child modules. E.g. from svn://mycompany.com/myproject in the parent pom, a child module 'frontend' will result in getting a SCM URL svn://mycompany.com/myproject/frontend This is fine for SVN and CVS, but broken for GIT, HG, etc because the SCM URL is 'static' for them. proposal --- Since we cannot put this information into the various scm plugins (because of a 'definition cycle' as explained here [1]) we could split the URL construction into scmUrlAppendChild=true/false and make it configurable. The configuration could be controlled via a Modello config, my suggestion would be to just add them to toolchains.mdo. I'd just add a String property which holds a regular expression which parses the SCM URL and decides upon this whether the appending should get activated, e.g. for all SCMs which contain 'scm:svn:' or 'scm:cvs:' or the java-svn (olamy, you know the plexus key for that?) If there is a better place to put that config or a better way to get the info, then please speak up now :) I think this change would be backward compatible and doesn't need any pom changes. It also could easily get back-ported to mvn2 if needed. Are there other URLS which also need a similar distinction while building the model? WDYT? txs and LieGrue, strub [1] http://markmail.org/message/npw3hp6aloa55ctf - 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 -- 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
Re: [DISCUSS] SCM child-project URL composition
Hi John, Brian Just to make sure I did understand that correctly: you propose to use a special URL prefix to tell the maven DefaultProjectBuilder to treat those urls as static. An example: staticscm:git:ssh://myserver:/.. wrote: > From: Brian Fox > Subject: Re: [DISCUSS] SCM child-project URL composition > To: "Maven Developers List" > Date: Thursday, July 28, 2011, 7:23 PM > On Thu, Jul 28, 2011 at 2:59 PM, John > Casey > wrote: > > Would it be better to have a syntax to mark a URL as > literal, not to be > > calculated or used as the basis of calculation? > > > > Yes. I tried to fix this behavior for urls back in ~2.0.6/7 > ish and it > broke lots of stuff that depended upon that behavior. > > > That way, we don't have to worry about adjusting to > new SCMs or other places > > where we want to use it...new SCMs could be added via > build extension, IIRC, > > so this is particularly important there. > > > > WDYT? > > > > On 7/28/11 12:46 PM, Mark Struberg wrote: > >> > >> Hi! > >> > >> problem description > >> --- > >> > >> SCM URLs currently automatically get extended for > child modules. > >> E.g. from > >> svn://mycompany.com/myproject > >> in the parent pom, a child module 'frontend' will > result in getting a SCM > >> URL > >> svn://mycompany.com/myproject/frontend > >> > >> This is fine for SVN and CVS, but broken for GIT, > HG, etc because the SCM > >> URL is 'static' for them. > >> > >> > >> proposal > >> --- > >> > >> Since we cannot put this information into the > various scm plugins (because > >> of a 'definition cycle' as explained here [1]) we > could split the URL > >> construction into scmUrlAppendChild=true/false and > make it configurable. The > >> configuration could be controlled via a Modello > config, my suggestion would > >> be to just add them to toolchains.mdo. > >> I'd just add a String property which holds a > regular expression which > >> parses the SCM URL and decides upon this whether > the appending should get > >> activated, e.g. for all SCMs which contain > 'scm:svn:' or 'scm:cvs:' or the > >> java-svn (olamy, you know the plexus key for > that?) > >> > >> If there is a better place to put that config or a > better way to get the > >> info, then please speak up now :) > >> > >> I think this change would be backward compatible > and doesn't need any pom > >> changes. It also could easily get back-ported to > mvn2 if needed. > >> Are there other URLS which also need a similar > distinction while building > >> the model? > >> > >> WDYT? > >> > >> txs and LieGrue, > >> strub > >> > >> [1] http://markmail.org/message/npw3hp6aloa55ctf > >> > >> > - > >> 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
Re: [DISCUSS] SCM child-project URL composition
On Thu, Jul 28, 2011 at 2:59 PM, John Casey wrote: > Would it be better to have a syntax to mark a URL as literal, not to be > calculated or used as the basis of calculation? > Yes. I tried to fix this behavior for urls back in ~2.0.6/7 ish and it broke lots of stuff that depended upon that behavior. > That way, we don't have to worry about adjusting to new SCMs or other places > where we want to use it...new SCMs could be added via build extension, IIRC, > so this is particularly important there. > > WDYT? > > On 7/28/11 12:46 PM, Mark Struberg wrote: >> >> Hi! >> >> problem description >> --- >> >> SCM URLs currently automatically get extended for child modules. >> E.g. from >> svn://mycompany.com/myproject >> in the parent pom, a child module 'frontend' will result in getting a SCM >> URL >> svn://mycompany.com/myproject/frontend >> >> This is fine for SVN and CVS, but broken for GIT, HG, etc because the SCM >> URL is 'static' for them. >> >> >> proposal >> --- >> >> Since we cannot put this information into the various scm plugins (because >> of a 'definition cycle' as explained here [1]) we could split the URL >> construction into scmUrlAppendChild=true/false and make it configurable. The >> configuration could be controlled via a Modello config, my suggestion would >> be to just add them to toolchains.mdo. >> I'd just add a String property which holds a regular expression which >> parses the SCM URL and decides upon this whether the appending should get >> activated, e.g. for all SCMs which contain 'scm:svn:' or 'scm:cvs:' or the >> java-svn (olamy, you know the plexus key for that?) >> >> If there is a better place to put that config or a better way to get the >> info, then please speak up now :) >> >> I think this change would be backward compatible and doesn't need any pom >> changes. It also could easily get back-ported to mvn2 if needed. >> Are there other URLS which also need a similar distinction while building >> the model? >> >> WDYT? >> >> txs and LieGrue, >> strub >> >> [1] http://markmail.org/message/npw3hp6aloa55ctf >> >> - >> 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
Re: [DISCUSS] SCM child-project URL composition
Would it be better to have a syntax to mark a URL as literal, not to be calculated or used as the basis of calculation? That way, we don't have to worry about adjusting to new SCMs or other places where we want to use it...new SCMs could be added via build extension, IIRC, so this is particularly important there. WDYT? On 7/28/11 12:46 PM, Mark Struberg wrote: Hi! problem description --- SCM URLs currently automatically get extended for child modules. E.g. from svn://mycompany.com/myproject in the parent pom, a child module 'frontend' will result in getting a SCM URL svn://mycompany.com/myproject/frontend This is fine for SVN and CVS, but broken for GIT, HG, etc because the SCM URL is 'static' for them. proposal --- Since we cannot put this information into the various scm plugins (because of a 'definition cycle' as explained here [1]) we could split the URL construction into scmUrlAppendChild=true/false and make it configurable. The configuration could be controlled via a Modello config, my suggestion would be to just add them to toolchains.mdo. I'd just add a String property which holds a regular expression which parses the SCM URL and decides upon this whether the appending should get activated, e.g. for all SCMs which contain 'scm:svn:' or 'scm:cvs:' or the java-svn (olamy, you know the plexus key for that?) If there is a better place to put that config or a better way to get the info, then please speak up now :) I think this change would be backward compatible and doesn't need any pom changes. It also could easily get back-ported to mvn2 if needed. Are there other URLS which also need a similar distinction while building the model? WDYT? txs and LieGrue, strub [1] http://markmail.org/message/npw3hp6aloa55ctf - 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
[DISCUSS] SCM child-project URL composition
Hi! problem description --- SCM URLs currently automatically get extended for child modules. E.g. from svn://mycompany.com/myproject in the parent pom, a child module 'frontend' will result in getting a SCM URL svn://mycompany.com/myproject/frontend This is fine for SVN and CVS, but broken for GIT, HG, etc because the SCM URL is 'static' for them. proposal --- Since we cannot put this information into the various scm plugins (because of a 'definition cycle' as explained here [1]) we could split the URL construction into scmUrlAppendChild=true/false and make it configurable. The configuration could be controlled via a Modello config, my suggestion would be to just add them to toolchains.mdo. I'd just add a String property which holds a regular expression which parses the SCM URL and decides upon this whether the appending should get activated, e.g. for all SCMs which contain 'scm:svn:' or 'scm:cvs:' or the java-svn (olamy, you know the plexus key for that?) If there is a better place to put that config or a better way to get the info, then please speak up now :) I think this change would be backward compatible and doesn't need any pom changes. It also could easily get back-ported to mvn2 if needed. Are there other URLS which also need a similar distinction while building the model? WDYT? txs and LieGrue, strub [1] http://markmail.org/message/npw3hp6aloa55ctf - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
