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 jdca...@commonjava.org wrote: On 7/29/11 7:45 AM, Benson Margulies wrote: thereof? Does anyone hate it? I'm just a bit behind on mail, but need a clarification - in Maven the XSD is an end result of the model that is generated, but you seem to describe it here as an input. Am I misreading? I've been assuming that the XSD file is a manual production, but I didn't actually check. I guess that modello might be in the business of excreting XSD files, too. So my more recent email is a bit wrong. Yes, Modello is used to generate the XSD. So the next question that comes up is: can we generate an XSD like you describe using Modello? If we can, I think this is a pretty decent plan, actually...the best of limited options, IMO. If we get the alternative format work done later, then we escape the need to live with the format forever too. So, the danger that we're adding to our ball of tape and chewing gum is limited by that. If you're suggesting a change to the model that is backwards compat API-wise with 4.0.0, and has identical behaviour (or graceful degradation) when read from the repository by= 3.0.3, then I don't see any problem with a particular change. Yes, that's precisely the idea. Some new accessors appear in the model, and if you don't bother them, they won't bother you. - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- John Casey Developer, PMC Chair - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
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 url/ elements. So adding them can't break it. Now, anyone who adds the attributes has to use a new enough maven-release-plugin to get the benefit of them. On Sat, Jul 30, 2011 at 4:55 AM, Ralph Goers ralph.go...@dslextreme.com wrote: i think I'm missing something. My understanding has been that any file named pom.xml that isn't compliant with 4.0.0 is going to break Maven 2 users. Am I misunderstanding something about what is being proposed? Ralph On Jul 29, 2011, at 8:04 AM, Benson Margulies wrote: I think Herve said so. On Jul 29, 2011, at 10:50 AM, John Casey jdca...@commonjava.org wrote: On 7/29/11 7:45 AM, Benson Margulies wrote: thereof? Does anyone hate it? I'm just a bit behind on mail, but need a clarification - in Maven the XSD is an end result of the model that is generated, but you seem to describe it here as an input. Am I misreading? I've been assuming that the XSD file is a manual production, but I didn't actually check. I guess that modello might be in the business of excreting XSD files, too. So my more recent email is a bit wrong. Yes, Modello is used to generate the XSD. So the next question that comes up is: can we generate an XSD like you describe using Modello? If we can, I think this is a pretty decent plan, actually...the best of limited options, IMO. If we get the alternative format work done later, then we escape the need to live with the format forever too. So, the danger that we're adding to our ball of tape and chewing gum is limited by that. If you're suggesting a change to the model that is backwards compat API-wise with 4.0.0, and has identical behaviour (or graceful degradation) when read from the repository by= 3.0.3, then I don't see any problem with a particular change. Yes, that's precisely the idea. Some new accessors appear in the model, and if you don't bother them, they won't bother you. - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- John Casey Developer, PMC Chair - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
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 url/ elements. So adding them can't break it. Now, anyone who adds the attributes has to use a new enough maven-release-plugin to get the benefit of them. On Sat, Jul 30, 2011 at 4:55 AM, Ralph Goers ralph.go...@dslextreme.com wrote: i think I'm missing something. My understanding has been that any file named pom.xml that isn't compliant with 4.0.0 is going to break Maven 2 users. Am I misunderstanding something about what is being proposed? Ralph On Jul 29, 2011, at 8:04 AM, Benson Margulies wrote: I think Herve said so. On Jul 29, 2011, at 10:50 AM, John Casey jdca...@commonjava.org wrote: On 7/29/11 7:45 AM, Benson Margulies wrote: thereof? Does anyone hate it? I'm just a bit behind on mail, but need a clarification - in Maven the XSD is an end result of the model that is generated, but you seem to describe it here as an input. Am I misreading? I've been assuming that the XSD file is a manual production, but I didn't actually check. I guess that modello might be in the business of excreting XSD files, too. So my more recent email is a bit wrong. Yes, Modello is used to generate the XSD. So the next question that comes up is: can we generate an XSD like you describe using Modello? If we can, I think this is a pretty decent plan, actually...the best of limited options, IMO. If we get the alternative format work done later, then we escape the need to live with the format forever too. So, the danger that we're adding to our ball of tape and chewing gum is limited by that. If you're suggesting a change to the model that is backwards compat API-wise with 4.0.0, and has identical behaviour (or graceful degradation) when read from the repository by= 3.0.3, then I don't see any problem with a particular change. Yes, that's precisely the idea. Some new accessors appear in the model, and if you don't bother them, they won't bother you. - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- John Casey Developer, PMC Chair - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - 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 Sat, Jul 30, 2011 at 1:07 PM, Ralph Goers ralph.go...@dslextreme.com 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 url/ elements. So adding them can't break it. Now, anyone who adds the attributes has to use a new enough maven-release-plugin to get the benefit of them. On Sat, Jul 30, 2011 at 4:55 AM, Ralph Goers ralph.go...@dslextreme.com wrote: i think I'm missing something. My understanding has been that any file named pom.xml that isn't compliant with 4.0.0 is going to break Maven 2 users. Am I misunderstanding something about what is being proposed? Ralph On Jul 29, 2011, at 8:04 AM, Benson Margulies wrote: I think Herve said so. On Jul 29, 2011, at 10:50 AM, John Casey jdca...@commonjava.org wrote: On 7/29/11 7:45 AM, Benson Margulies wrote: thereof? Does anyone hate it? I'm just a bit behind on mail, but need a clarification - in Maven the XSD is an end result of the model that is generated, but you seem to describe it here as an input. Am I misreading? I've been assuming that the XSD file is a manual production, but I didn't actually check. I guess that modello might be in the business of excreting XSD files, too. So my more recent email is a bit wrong. Yes, Modello is used to generate the XSD. So the next question that comes up is: can we generate an XSD like you describe using Modello? If we can, I think this is a pretty decent plan, actually...the best of limited options, IMO. If we get the alternative format work done later, then we escape the need to live with the format forever too. So, the danger that we're adding to our ball of tape and chewing gum is limited by that. If you're suggesting a change to the model that is backwards compat API-wise with 4.0.0, and has identical behaviour (or graceful degradation) when read from the repository by= 3.0.3, then I don't see any problem with a particular change. Yes, that's precisely the idea. Some new accessors appear in the model, and if you don't bother them, they won't bother you. - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- John Casey Developer, PMC Chair - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - 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
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 ja...@sonatype.com wrote: From: Jason van Zyl ja...@sonatype.com Subject: Re: [DISCUSS] SCM child-project URL composition To: Maven Developers List dev@maven.apache.org 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 ja...@sonatype.com wrote: From: Jason van Zyl ja...@sonatype.com Subject: Re: [DISCUSS] SCM child-project URL composition To: Maven Developers List dev@maven.apache.org 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
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 herve.bout...@free.fr wrote: From: Hervé BOUTEMY herve.bout...@free.fr Subject: Re: [DISCUSS] SCM child-project URL composition To: Maven Developers List dev@maven.apache.org 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 ja...@sonatype.com wrote: From: Jason van Zyl ja...@sonatype.com Subject: Re: [DISCUSS] SCM child-project URL composition To: Maven Developers List dev@maven.apache.org 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
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
gnah sorry :( I explicitly tested the schema validation, but obviously using a new tool (I'm new to macs...) at 3 o clock in the morning isn't producing reliable results :/ But your idea with the XSD-4.0.1 sound really great. Almost too good to believe! That would probably allow us to implement most of the new features like mixins and stuff _without_ getting incompatible. Maybe we could not implement all the new stuff, but it's worth thinking about it. Otoh I'm not sure if such a change should be done in a bugfix release. Or better said: I'm pretty sure that we should _not_ do such a change in a bugfix release ;) LieGrue, strub --- On Fri, 7/29/11, Benson Margulies bimargul...@gmail.com wrote: From: Benson Margulies bimargul...@gmail.com Subject: Re: [DISCUSS] SCM child-project URL composition To: Maven Developers List dev@maven.apache.org Date: Friday, July 29, 2011, 2:01 AM I have some perhaps minor bad news about attributes. Attributes on the url/ element won't validate against the current schema. I had hoped to discover otherwise, but no such luck. The combine.children trick passes because it is inside of the 'any' inside the plugin configuration. I claim that the following is tolerable from a compatibility standpoint: 1) create a 4.0.1 XSD file that adds the necessary xs:anyAttribute (or specific attributes, if you prefer) to the url/ element. 2) Change default archetypes and the release plugin and friends to add this schema instead of the 4.0.0 schema. In other words, Mark's experiments show that, in *practical* terms, adding the attributes works. That leave the question of programs that actually pay attention to the schema itself. The only bad case would be some program out there which for some reason always validates against the 4.0.0 schema even if the schema declared at the top is 4.0.1. I don't believe in this. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
How about coming at this from a different track... scmscm:parent:/path/in/parent/scm that is an SCM that is the same as parent with a path in the parent. the parent scm provider would look up the parent's scm and could use some rules to derive the effective path, acting like a delegate and giving us the correct path. It does mean that unless prerequmaven3.1/maven/prerequ users would have to specify the scm in all initial child modules. On 29 July 2011 08:39, Mark Struberg strub...@yahoo.de wrote: gnah sorry :( I explicitly tested the schema validation, but obviously using a new tool (I'm new to macs...) at 3 o clock in the morning isn't producing reliable results :/ But your idea with the XSD-4.0.1 sound really great. Almost too good to believe! That would probably allow us to implement most of the new features like mixins and stuff _without_ getting incompatible. Maybe we could not implement all the new stuff, but it's worth thinking about it. Otoh I'm not sure if such a change should be done in a bugfix release. Or better said: I'm pretty sure that we should _not_ do such a change in a bugfix release ;) LieGrue, strub --- On Fri, 7/29/11, Benson Margulies bimargul...@gmail.com wrote: From: Benson Margulies bimargul...@gmail.com Subject: Re: [DISCUSS] SCM child-project URL composition To: Maven Developers List dev@maven.apache.org Date: Friday, July 29, 2011, 2:01 AM I have some perhaps minor bad news about attributes. Attributes on the url/ element won't validate against the current schema. I had hoped to discover otherwise, but no such luck. The combine.children trick passes because it is inside of the 'any' inside the plugin configuration. I claim that the following is tolerable from a compatibility standpoint: 1) create a 4.0.1 XSD file that adds the necessary xs:anyAttribute (or specific attributes, if you prefer) to the url/ element. 2) Change default archetypes and the release plugin and friends to add this schema instead of the 4.0.0 schema. In other words, Mark's experiments show that, in *practical* terms, adding the attributes works. That leave the question of programs that actually pay attention to the schema itself. The only bad case would be some program out there which for some reason always validates against the 4.0.0 schema even if the schema declared at the top is 4.0.1. I don't believe in this. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
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 stephen.alan.conno...@gmail.com wrote: How about coming at this from a different track... scmscm:parent:/path/in/parent/scm that is an SCM that is the same as parent with a path in the parent. the parent scm provider would look up the parent's scm and could use some rules to derive the effective path, acting like a delegate and giving us the correct path. It does mean that unless prerequmaven3.1/maven/prerequ users would have to specify the scm in all initial child modules. On 29 July 2011 08:39, Mark Struberg strub...@yahoo.de wrote: gnah sorry :( I explicitly tested the schema validation, but obviously using a new tool (I'm new to macs...) at 3 o clock in the morning isn't producing reliable results :/ But your idea with the XSD-4.0.1 sound really great. Almost too good to believe! That would probably allow us to implement most of the new features like mixins and stuff _without_ getting incompatible. Maybe we could not implement all the new stuff, but it's worth thinking about it. Otoh I'm not sure if such a change should be done in a bugfix release. Or better said: I'm pretty sure that we should _not_ do such a change in a bugfix release ;) LieGrue, strub --- On Fri, 7/29/11, Benson Margulies bimargul...@gmail.com wrote: From: Benson Margulies bimargul...@gmail.com Subject: Re: [DISCUSS] SCM child-project URL composition To: Maven Developers List dev@maven.apache.org Date: Friday, July 29, 2011, 2:01 AM I have some perhaps minor bad news about attributes. Attributes on the url/ element won't validate against the current schema. I had hoped to discover otherwise, but no such luck. The combine.children trick passes because it is inside of the 'any' inside the plugin configuration. I claim that the following is tolerable from a compatibility standpoint: 1) create a 4.0.1 XSD file that adds the necessary xs:anyAttribute (or specific attributes, if you prefer) to the url/ element. 2) Change default archetypes and the release plugin and friends to add this schema instead of the 4.0.0 schema. In other words, Mark's experiments show that, in *practical* terms, adding the attributes works. That leave the question of programs that actually pay attention to the schema itself. The only bad case would be some program out there which for some reason always validates against the 4.0.0 schema even if the schema declared at the top is 4.0.1. I don't believe in this. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
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
On 29 July 2011 12:35, Benson Margulies bimargul...@gmail.com 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 stephen.alan.conno...@gmail.com wrote: How about coming at this from a different track... scmscm:parent:/path/in/parent/scm that is an SCM that is the same as parent with a path in the parent. the parent scm provider would look up the parent's scm and could use some rules to derive the effective path, acting like a delegate and giving us the correct path. It does mean that unless prerequmaven3.1/maven/prerequ users would have to specify the scm in all initial child modules. On 29 July 2011 08:39, Mark Struberg strub...@yahoo.de wrote: gnah sorry :( I explicitly tested the schema validation, but obviously using a new tool (I'm new to macs...) at 3 o clock in the morning isn't producing reliable results :/ But your idea with the XSD-4.0.1 sound really great. Almost too good to believe! That would probably allow us to implement most of the new features like mixins and stuff _without_ getting incompatible. Maybe we could not implement all the new stuff, but it's worth thinking about it. Otoh I'm not sure if such a change should be done in a bugfix release. Or better said: I'm pretty sure that we should _not_ do such a change in a bugfix release ;) LieGrue, strub --- On Fri, 7/29/11, Benson Margulies bimargul...@gmail.com wrote: From: Benson Margulies bimargul...@gmail.com Subject: Re: [DISCUSS] SCM child-project URL composition To: Maven Developers List dev@maven.apache.org Date: Friday, July 29, 2011, 2:01 AM I have some perhaps minor bad news about attributes. Attributes on the url/ element won't validate against the current schema. I had hoped to discover otherwise, but no such luck. The combine.children trick passes because it is inside of the 'any' inside the plugin configuration. I claim that the following is tolerable from a compatibility standpoint: 1) create a 4.0.1 XSD file that adds the necessary xs:anyAttribute (or specific attributes, if you prefer) to the url/ element. 2) Change default archetypes and the release plugin and friends to add this schema instead of the 4.0.0 schema. In other words, Mark's experiments show that, in *practical* terms, adding the attributes works. That leave the question of programs that actually pay attention to the schema itself. The only bad case would be some program out there which for some reason always validates against the 4.0.0 schema even if the schema declared at the top is 4.0.1. I don't believe in this. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
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 bimargul...@gmail.com wrote: From: Benson Margulies bimargul...@gmail.com Subject: Re: [DISCUSS] SCM child-project URL composition To: Maven Developers List dev@maven.apache.org Date: Friday, July 29, 2011, 11:35 AM I'm in favor of the policy (since I suggested it), that maven 3.0.X can deliver pom XSD 4.0.Y, where the changes the the XSD are proven to be harmless to popular old versions and common sense characterizes them as unlikely to blow anything up. I submit that adding some inheritance control attributes would come under that rubric. Do we need to vote this, or otherwise clarify consensus or the lack thereof? Does anyone hate it? On Fri, Jul 29, 2011 at 4:26 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: How about coming at this from a different track... scmscm:parent:/path/in/parent/scm that is an SCM that is the same as parent with a path in the parent. the parent scm provider would look up the parent's scm and could use some rules to derive the effective path, acting like a delegate and giving us the correct path. It does mean that unless prerequmaven3.1/maven/prerequ users would have to specify the scm in all initial child modules. On 29 July 2011 08:39, Mark Struberg strub...@yahoo.de wrote: gnah sorry :( I explicitly tested the schema validation, but obviously using a new tool (I'm new to macs...) at 3 o clock in the morning isn't producing reliable results :/ But your idea with the XSD-4.0.1 sound really great. Almost too good to believe! That would probably allow us to implement most of the new features like mixins and stuff _without_ getting incompatible. Maybe we could not implement all the new stuff, but it's worth thinking about it. Otoh I'm not sure if such a change should be done in a bugfix release. Or better said: I'm pretty sure that we should _not_ do such a change in a bugfix release ;) LieGrue, strub --- On Fri, 7/29/11, Benson Margulies bimargul...@gmail.com wrote: From: Benson Margulies bimargul...@gmail.com Subject: Re: [DISCUSS] SCM child-project URL composition To: Maven Developers List dev@maven.apache.org Date: Friday, July 29, 2011, 2:01 AM I have some perhaps minor bad news about attributes. Attributes on the url/ element won't validate against the current schema. I had hoped to discover otherwise, but no such luck. The combine.children trick passes because it is inside of the 'any' inside the plugin configuration. I claim that the following is tolerable from a compatibility standpoint: 1) create a 4.0.1 XSD file that adds the necessary xs:anyAttribute (or specific attributes, if you prefer) to the url/ element. 2) Change default archetypes and the release plugin and friends to add this schema instead of the 4.0.0 schema. In other words, Mark's experiments show that, in *practical* terms, adding the attributes works. That leave the question of programs that actually pay attention to the schema itself. The only bad case would be some program out there which for some reason always validates against the 4.0.0 schema even if the schema declared at the top is 4.0.1. I don't believe in this. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
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 bimargul...@gmail.com wrote: I'm in favor of the policy (since I suggested it), that maven 3.0.X can deliver pom XSD 4.0.Y, where the changes the the XSD are proven to be harmless to popular old versions and common sense characterizes them as unlikely to blow anything up. I submit that adding some inheritance control attributes would come under that rubric. Do we need to vote this, or otherwise clarify consensus or the lack thereof? Does anyone hate it? On Fri, Jul 29, 2011 at 4:26 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: How about coming at this from a different track... scmscm:parent:/path/in/parent/scm that is an SCM that is the same as parent with a path in the parent. the parent scm provider would look up the parent's scm and could use some rules to derive the effective path, acting like a delegate and giving us the correct path. It does mean that unless prerequmaven3.1/maven/prerequ users would have to specify the scm in all initial child modules. On 29 July 2011 08:39, Mark Struberg strub...@yahoo.de wrote: gnah sorry :( I explicitly tested the schema validation, but obviously using a new tool (I'm new to macs...) at 3 o clock in the morning isn't producing reliable results :/ But your idea with the XSD-4.0.1 sound really great. Almost too good to believe! That would probably allow us to implement most of the new features like mixins and stuff _without_ getting incompatible. Maybe we could not implement all the new stuff, but it's worth thinking about it. Otoh I'm not sure if such a change should be done in a bugfix release. Or better said: I'm pretty sure that we should _not_ do such a change in a bugfix release ;) LieGrue, strub --- On Fri, 7/29/11, Benson Margulies bimargul...@gmail.com wrote: From: Benson Margulies bimargul...@gmail.com Subject: Re: [DISCUSS] SCM child-project URL composition To: Maven Developers List dev@maven.apache.org Date: Friday, July 29, 2011, 2:01 AM I have some perhaps minor bad news about attributes. Attributes on the url/ element won't validate against the current schema. I had hoped to discover otherwise, but no such luck. The combine.children trick passes because it is inside of the 'any' inside the plugin configuration. I claim that the following is tolerable from a compatibility standpoint: 1) create a 4.0.1 XSD file that adds the necessary xs:anyAttribute (or specific attributes, if you prefer) to the url/ element. 2) Change default archetypes and the release plugin and friends to add this schema instead of the 4.0.0 schema. In other words, Mark's experiments show that, in *practical* terms, adding the attributes works. That leave the question of programs that actually pay attention to the schema itself. The only bad case would be some program out there which for some reason always validates against the 4.0.0 schema even if the schema declared at the top is 4.0.1. I don't believe in this. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
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
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
I think Herve said so. On Jul 29, 2011, at 10:50 AM, John Casey jdca...@commonjava.org wrote: On 7/29/11 7:45 AM, Benson Margulies wrote: thereof? Does anyone hate it? I'm just a bit behind on mail, but need a clarification - in Maven the XSD is an end result of the model that is generated, but you seem to describe it here as an input. Am I misreading? I've been assuming that the XSD file is a manual production, but I didn't actually check. I guess that modello might be in the business of excreting XSD files, too. So my more recent email is a bit wrong. Yes, Modello is used to generate the XSD. So the next question that comes up is: can we generate an XSD like you describe using Modello? If we can, I think this is a pretty decent plan, actually...the best of limited options, IMO. If we get the alternative format work done later, then we escape the need to live with the format forever too. So, the danger that we're adding to our ball of tape and chewing gum is limited by that. If you're suggesting a change to the model that is backwards compat API-wise with 4.0.0, and has identical behaviour (or graceful degradation) when read from the repository by= 3.0.3, then I don't see any problem with a particular change. Yes, that's precisely the idea. Some new accessors appear in the model, and if you don't bother them, they won't bother you. - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- John Casey Developer, PMC Chair - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[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
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
Re: [DISCUSS] SCM child-project URL composition
On Thu, Jul 28, 2011 at 2:59 PM, John Casey jdca...@commonjava.org 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
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: scm developerConnectionstaticscm:git:ssh://myserver:/../developerConnection 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 bri...@infinity.nu wrote: From: Brian Fox bri...@infinity.nu Subject: Re: [DISCUSS] SCM child-project URL composition To: Maven Developers List dev@maven.apache.org Date: Thursday, July 28, 2011, 7:23 PM On Thu, Jul 28, 2011 at 2:59 PM, John Casey jdca...@commonjava.org 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 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: scm developerConnectionstaticscm:git:ssh://myserver:/../developerConnection 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! I think that's an acceptable compromise, personally. LieGrue, strub --- On Thu, 7/28/11, Brian Foxbri...@infinity.nu wrote: From: Brian Foxbri...@infinity.nu Subject: Re: [DISCUSS] SCM child-project URL composition To: Maven Developers Listdev@maven.apache.org Date: Thursday, July 28, 2011, 7:23 PM On Thu, Jul 28, 2011 at 2:59 PM, John Caseyjdca...@commonjava.org 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
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 strub...@yahoo.de 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: scm developerConnectionstaticscm:git:ssh://myserver:/../developerConnection 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 bri...@infinity.nu wrote: From: Brian Fox bri...@infinity.nu Subject: Re: [DISCUSS] SCM child-project URL composition To: Maven Developers List dev@maven.apache.org Date: Thursday, July 28, 2011, 7:23 PM On Thu, Jul 28, 2011 at 2:59 PM, John Casey jdca...@commonjava.org 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
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 bri...@infinity.nu 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 strub...@yahoo.de 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: scm developerConnectionstaticscm:git:ssh://myserver:/../developerConnection 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 bri...@infinity.nu wrote: From: Brian Fox bri...@infinity.nu Subject: Re: [DISCUSS] SCM child-project URL composition To: Maven Developers List dev@maven.apache.org Date: Thursday, July 28, 2011, 7:23 PM On Thu, Jul 28, 2011 at 2:59 PM, John Casey jdca...@commonjava.org 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
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 bri...@infinity.nu wrote:
From: Brian Fox bri...@infinity.nu
Subject: Re: [DISCUSS] SCM child-project URL composition
To: Maven Developers List dev@maven.apache.org
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 strub...@yahoo.de
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:
scm
developerConnectionstaticscm:git:ssh://myserver:/../developerConnection
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 bri...@infinity.nu
wrote:
From: Brian Fox bri...@infinity.nu
Subject: Re: [DISCUSS] SCM child-project URL
composition
To: Maven Developers List dev@maven.apache.org
Date: Thursday, July 28, 2011, 7:23 PM
On Thu, Jul 28, 2011 at 2:59 PM, John
Casey jdca...@commonjava.org
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
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 strub...@yahoo.de 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 bri...@infinity.nu wrote:
From: Brian Fox bri...@infinity.nu
Subject: Re: [DISCUSS] SCM child-project URL composition
To: Maven Developers List dev@maven.apache.org
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 strub...@yahoo.de
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:
scm
developerConnectionstaticscm:git:ssh://myserver:/../developerConnection
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 bri...@infinity.nu
wrote:
From: Brian Fox bri...@infinity.nu
Subject: Re: [DISCUSS] SCM child-project URL
composition
To: Maven Developers List dev@maven.apache.org
Date: Thursday, July 28, 2011, 7:23 PM
On Thu, Jul 28, 2011 at 2:59 PM, John
Casey jdca...@commonjava.org
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 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 Foxbri...@infinity.nu 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 Strubergstrub...@yahoo.de 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: scm developerConnectionstaticscm:git:ssh://myserver:/../developerConnection 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 Foxbri...@infinity.nu wrote: From: Brian Foxbri...@infinity.nu Subject: Re: [DISCUSS] SCM child-project URL composition To: Maven Developers Listdev@maven.apache.org Date: Thursday, July 28, 2011, 7:23 PM On Thu, Jul 28, 2011 at 2:59 PM, John Caseyjdca...@commonjava.org 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
Re: [DISCUSS] SCM child-project URL composition
yup something like
developerConnectionstatic: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 bimargul...@gmail.com wrote:
From: Benson Margulies bimargul...@gmail.com
Subject: Re: [DISCUSS] SCM child-project URL composition
To: Maven Developers List dev@maven.apache.org
Date: 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 strub...@yahoo.de
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 bri...@infinity.nu
wrote:
From: Brian Fox bri...@infinity.nu
Subject: Re: [DISCUSS] SCM child-project URL
composition
To: Maven Developers List dev@maven.apache.org
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
strub...@yahoo.de
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:
scm
developerConnectionstaticscm:git:ssh://myserver:/../developerConnection
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 bri...@infinity.nu
wrote:
From: Brian Fox bri...@infinity.nu
Subject: Re: [DISCUSS] SCM child-project
URL
composition
To: Maven Developers List dev@maven.apache.org
Date: Thursday, July 28, 2011, 7:23 PM
On Thu, Jul 28, 2011 at 2:59 PM, John
Casey jdca...@commonjava.org
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
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 Strubergstrub...@yahoo.de 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 Foxbri...@infinity.nu wrote:
From: Brian Foxbri...@infinity.nu
Subject: Re: [DISCUSS] SCM child-project URL composition
To: Maven Developers Listdev@maven.apache.org
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 Strubergstrub...@yahoo.de
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:
scm
developerConnectionstaticscm:git:ssh://myserver:/../developerConnection
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 Foxbri...@infinity.nu
wrote:
From: Brian Foxbri...@infinity.nu
Subject: Re: [DISCUSS] SCM child-project URL
composition
To: Maven Developers Listdev@maven.apache.org
Date: Thursday, July 28, 2011, 7:23 PM
On Thu, Jul 28, 2011 at 2:59 PM, John
Caseyjdca...@commonjava.org
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
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:
url static='true'what-we-have-today/url
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
url inherit='false'what-we-have-today/url
which would be a good thing for the overall ASF pom.
On Thu, Jul 28, 2011 at 5:50 PM, John Casey jdca...@commonjava.org 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 Strubergstrub...@yahoo.de 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 Foxbri...@infinity.nu wrote:
From: Brian Foxbri...@infinity.nu
Subject: Re: [DISCUSS] SCM child-project URL composition
To: Maven Developers Listdev@maven.apache.org
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 Strubergstrub...@yahoo.de
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:
scm
developerConnectionstaticscm:git:ssh://myserver:/../developerConnection
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 Foxbri...@infinity.nu
wrote:
From: Brian Foxbri...@infinity.nu
Subject: Re: [DISCUSS] SCM child-project URL
composition
To: Maven Developers Listdev@maven.apache.org
Date: Thursday, July 28, 2011, 7:23 PM
On Thu, Jul 28, 2011 at 2:59 PM, John
Caseyjdca...@commonjava.org
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
Re: [DISCUSS] SCM child-project URL composition
Hi and txs 4 looking through the proposal!
url static=true 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 bimargul...@gmail.com wrote:
From: Benson Margulies bimargul...@gmail.com
Subject: Re: [DISCUSS] SCM child-project URL composition
To: Maven Developers List dev@maven.apache.org
Date: 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:
url static='true'what-we-have-today/url
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
url
inherit='false'what-we-have-today/url
which would be a good thing for the overall ASF pom.
On Thu, Jul 28, 2011 at 5:50 PM, John Casey jdca...@commonjava.org
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
Strubergstrub...@yahoo.de
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 Foxbri...@infinity.nu
wrote:
From: Brian Foxbri...@infinity.nu
Subject: Re: [DISCUSS] SCM child-project
URL composition
To: Maven Developers Listdev@maven.apache.org
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
Strubergstrub...@yahoo.de
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:
scm
developerConnectionstaticscm:git:ssh://myserver:/../developerConnection
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 Foxbri...@infinity.nu
wrote:
From: Brian Foxbri...@infinity.nu
Subject: Re: [DISCUSS] SCM
child-project URL
composition
To: Maven Developers Listdev@maven.apache.org
Date: Thursday, July 28, 2011,
7:23 PM
On Thu, Jul 28, 2011 at 2:59 PM,
John
Caseyjdca...@commonjava.org
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
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!
url static=true 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 Marguliesbimargul...@gmail.com wrote:
From: Benson Marguliesbimargul...@gmail.com
Subject: Re: [DISCUSS] SCM child-project URL composition
To: Maven Developers Listdev@maven.apache.org
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:
url static='true'what-we-have-today/url
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
url
inherit='false'what-we-have-today/url
which would be a good thing for the overall ASF pom.
On Thu, Jul 28, 2011 at 5:50 PM, John Caseyjdca...@commonjava.org
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
Strubergstrub...@yahoo.de
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 Foxbri...@infinity.nu
wrote:
From: Brian Foxbri...@infinity.nu
Subject: Re: [DISCUSS] SCM child-project
URL composition
To: Maven Developers Listdev@maven.apache.org
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
Strubergstrub...@yahoo.de
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:
scm
developerConnectionstaticscm:git:ssh://myserver:/../developerConnection
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 Foxbri...@infinity.nu
wrote:
From: Brian Foxbri...@infinity.nu
Subject: Re: [DISCUSS] SCM
child-project URL
composition
To: Maven Developers Listdev@maven.apache.org
Date: Thursday, July 28, 2011,
7:23 PM
On Thu, Jul 28, 2011 at 2:59 PM,
John
Caseyjdca...@commonjava.org
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
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 jdca...@commonjava.org wrote:
On 7/28/11 6:12 PM, Mark Struberg wrote:
Hi and txs 4 looking through the proposal!
url static=true 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 Marguliesbimargul...@gmail.com wrote:
From: Benson Marguliesbimargul...@gmail.com
Subject: Re: [DISCUSS] SCM child-project URL composition
To: Maven Developers Listdev@maven.apache.org
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:
url static='true'what-we-have-today/url
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
url
inherit='false'what-we-have-today/url
which would be a good thing for the overall ASF pom.
On Thu, Jul 28, 2011 at 5:50 PM, John Caseyjdca...@commonjava.org
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
Strubergstrub...@yahoo.de
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 Foxbri...@infinity.nu
wrote:
From: Brian Foxbri...@infinity.nu
Subject: Re: [DISCUSS] SCM child-project
URL composition
To: Maven Developers Listdev@maven.apache.org
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
Strubergstrub...@yahoo.de
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:
scm
developerConnectionstaticscm:git:ssh://myserver:/../developerConnection
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 Foxbri...@infinity.nu
wrote:
From: Brian Foxbri...@infinity.nu
Subject: Re: [DISCUSS] SCM
child-project URL
composition
To: Maven Developers Listdev@maven.apache.org
Date: Thursday, July 28, 2011,
7:23 PM
On Thu, Jul 28, 2011 at 2:59 PM,
John
Caseyjdca...@commonjava.org
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
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 bimargul...@gmail.com 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 jdca...@commonjava.org wrote:
On 7/28/11 6:12 PM, Mark Struberg wrote:
Hi and txs 4 looking through the proposal!
url static=true 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 Marguliesbimargul...@gmail.com wrote:
From: Benson Marguliesbimargul...@gmail.com
Subject: Re: [DISCUSS] SCM child-project URL composition
To: Maven Developers Listdev@maven.apache.org
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:
url static='true'what-we-have-today/url
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
url
inherit='false'what-we-have-today/url
which would be a good thing for the overall ASF pom.
On Thu, Jul 28, 2011 at 5:50 PM, John Caseyjdca...@commonjava.org
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
Strubergstrub...@yahoo.de
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 Foxbri...@infinity.nu
wrote:
From: Brian Foxbri...@infinity.nu
Subject: Re: [DISCUSS] SCM child-project
URL composition
To: Maven Developers Listdev@maven.apache.org
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
Strubergstrub...@yahoo.de
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:
scm
developerConnectionstaticscm:git:ssh://myserver:/../developerConnection
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 Foxbri...@infinity.nu
wrote:
From: Brian Foxbri...@infinity.nu
Subject: Re: [DISCUSS] SCM
child-project URL
composition
To: Maven Developers Listdev@maven.apache.org
Date: Thursday, July 28, 2011,
7:23 PM
On Thu, Jul 28, 2011 at 2:59 PM,
John
Caseyjdca...@commonjava.org
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
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.)
url absolute=truescm:git:https://...
or
B.)
urlabsolute:scm:git:https://...
Please decide folks ;)
LieGrue,
strub
--- On Thu, 7/28/11, Stephen Connolly stephen.alan.conno...@gmail.com wrote:
From: Stephen Connolly stephen.alan.conno...@gmail.com
Subject: Re: [DISCUSS] SCM child-project URL composition
To: Maven Developers List dev@maven.apache.org
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 bimargul...@gmail.com
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 jdca...@commonjava.org
wrote:
On 7/28/11 6:12 PM, Mark Struberg wrote:
Hi and txs 4 looking through the proposal!
url static=true 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 Marguliesbimargul...@gmail.com
wrote:
From: Benson Marguliesbimargul...@gmail.com
Subject: Re: [DISCUSS] SCM child-project
URL composition
To: Maven Developers Listdev@maven.apache.org
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:
url
static='true'what-we-have-today/url
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
url
inherit='false'what-we-have-today/url
which would be a good thing for the
overall ASF pom.
On Thu, Jul 28, 2011 at 5:50 PM, John
Caseyjdca...@commonjava.org
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
Strubergstrub...@yahoo.de
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
Foxbri...@infinity.nu
wrote:
From: Brian Foxbri...@infinity.nu
Subject: Re: [DISCUSS] SCM
child-project
URL composition
To: Maven Developers
Listdev@maven.apache.org
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
Strubergstrub...@yahoo.de
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:
scm
developerConnectionstaticscm:git:ssh://myserver:/../developerConnection
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
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.)
url absolute=truescm:git:https://...
or
B.)
urlabsolute:scm:git:https://...
Please decide folks ;)
LieGrue,
strub
--- On Thu, 7/28/11, Stephen Connollystephen.alan.conno...@gmail.com wrote:
From: Stephen Connollystephen.alan.conno...@gmail.com
Subject: Re: [DISCUSS] SCM child-project URL composition
To: Maven Developers Listdev@maven.apache.org
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 Marguliesbimargul...@gmail.com
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 Caseyjdca...@commonjava.org
wrote:
On 7/28/11 6:12 PM, Mark Struberg wrote:
Hi and txs 4 looking through the proposal!
url static=true 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 Marguliesbimargul...@gmail.com
wrote:
From: Benson Marguliesbimargul...@gmail.com
Subject: Re: [DISCUSS] SCM child-project
URL composition
To: Maven Developers Listdev@maven.apache.org
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:
url
static='true'what-we-have-today/url
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
url
inherit='false'what-we-have-today/url
which would be a good thing for the
overall ASF pom.
On Thu, Jul 28, 2011 at 5:50 PM, John
Caseyjdca...@commonjava.org
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
Strubergstrub...@yahoo.de
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
Foxbri...@infinity.nu
wrote:
From: Brian Foxbri...@infinity.nu
Subject: Re: [DISCUSS] SCM
child-project
URL composition
To: Maven Developers
Listdev@maven.apache.org
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
Strubergstrub...@yahoo.de
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:
scm
developerConnectionstaticscm:git:ssh://myserver:/../developerConnection
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 Foxbri...@infinity.nu
wrote:
From: Brian
Foxbri
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 jdca...@commonjava.org 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.)
url absolute=truescm:git:https://...
or
B.)
urlabsolute:scm:git:https://...
Please decide folks ;)
LieGrue,
strub
--- On Thu, 7/28/11, Stephen Connollystephen.alan.conno...@gmail.com
wrote:
From: Stephen Connollystephen.alan.conno...@gmail.com
Subject: Re: [DISCUSS] SCM child-project URL composition
To: Maven Developers Listdev@maven.apache.org
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 Marguliesbimargul...@gmail.com
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 Caseyjdca...@commonjava.org
wrote:
On 7/28/11 6:12 PM, Mark Struberg wrote:
Hi and txs 4 looking through the proposal!
url static=true 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 Marguliesbimargul...@gmail.com
wrote:
From: Benson Marguliesbimargul...@gmail.com
Subject: Re: [DISCUSS] SCM child-project
URL composition
To: Maven Developers Listdev@maven.apache.org
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:
url
static='true'what-we-have-today/url
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
url
inherit='false'what-we-have-today/url
which would be a good thing for the
overall ASF pom.
On Thu, Jul 28, 2011 at 5:50 PM, John
Caseyjdca...@commonjava.org
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
Strubergstrub...@yahoo.de
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
Foxbri...@infinity.nu
wrote:
From: Brian Foxbri...@infinity.nu
Subject: Re: [DISCUSS] SCM
child-project
URL composition
To: Maven Developers
Listdev@maven.apache.org
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
Strubergstrub...@yahoo.de
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:
scm
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
stephen.alan.conno...@gmail.com 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 jdca...@commonjava.org 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.)
url absolute=truescm:git:https://...
or
B.)
urlabsolute:scm:git:https://...
Please decide folks ;)
LieGrue,
strub
--- On Thu, 7/28/11, Stephen Connollystephen.alan.conno...@gmail.com
wrote:
From: Stephen Connollystephen.alan.conno...@gmail.com
Subject: Re: [DISCUSS] SCM child-project URL composition
To: Maven Developers Listdev@maven.apache.org
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 Marguliesbimargul...@gmail.com
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 Caseyjdca...@commonjava.org
wrote:
On 7/28/11 6:12 PM, Mark Struberg wrote:
Hi and txs 4 looking through the proposal!
url static=true 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 Marguliesbimargul...@gmail.com
wrote:
From: Benson Marguliesbimargul...@gmail.com
Subject: Re: [DISCUSS] SCM child-project
URL composition
To: Maven Developers Listdev@maven.apache.org
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:
url
static='true'what-we-have-today/url
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
url
inherit='false'what-we-have-today/url
which would be a good thing for the
overall ASF pom.
On Thu, Jul 28, 2011 at 5:50 PM, John
Caseyjdca...@commonjava.org
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
Strubergstrub...@yahoo.de
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
Foxbri...@infinity.nu
wrote:
From: Brian Foxbri...@infinity.nu
Subject: Re: [DISCUSS] SCM
child-project
URL composition
To: Maven Developers
Listdev@maven.apache.org
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
Strubergstrub...@yahoo.de
wrote:
Hi John, Brian
Just to make sure I
did understand
that correctly
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.)
url absolute=truescm:git:https://...
or
B.)
urlabsolute:scm:git:https://...
Please decide folks ;)
LieGrue,
strub
--- On Thu, 7/28/11, Stephen Connolly stephen.alan.conno...@gmail.com wrote:
From: Stephen Connolly stephen.alan.conno...@gmail.com
Subject: Re: [DISCUSS] SCM child-project URL composition
To: Maven Developers List dev@maven.apache.org
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 bimargul...@gmail.com
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 jdca...@commonjava.org
wrote:
On 7/28/11 6:12 PM, Mark Struberg wrote:
Hi and txs 4 looking through the proposal!
url static=true 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 Marguliesbimargul...@gmail.com
wrote:
From: Benson Marguliesbimargul...@gmail.com
Subject: Re: [DISCUSS] SCM child-project
URL composition
To: Maven Developers Listdev@maven.apache.org
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:
url
static='true'what-we-have-today/url
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
url
inherit='false'what-we-have-today/url
which would be a good thing for the
overall ASF pom.
On Thu, Jul 28, 2011 at 5:50 PM, John
Caseyjdca...@commonjava.org
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
Strubergstrub...@yahoo.de
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
Foxbri...@infinity.nu
wrote:
From: Brian Foxbri...@infinity.nu
Subject: Re: [DISCUSS] SCM
child-project
URL composition
To: Maven Developers
Listdev@maven.apache.org
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 ja...@sonatype.com wrote: From: Jason van Zyl ja...@sonatype.com Subject: Re: [DISCUSS] SCM child-project URL composition To: Maven Developers List dev@maven.apache.org 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.) url absolute=truescm:git:https://... or B.) urlabsolute:scm:git:https://... Please decide folks ;) LieGrue, strub --- On Thu, 7/28/11, Stephen Connolly stephen.alan.conno...@gmail.com wrote: From: Stephen Connolly stephen.alan.conno...@gmail.com Subject: Re: [DISCUSS] SCM child-project URL composition To: Maven Developers List dev@maven.apache.org 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 bimargul...@gmail.com 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 jdca...@commonjava.org wrote: On 7/28/11 6:12 PM, Mark Struberg wrote: Hi and txs 4 looking through the proposal! url static=true 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 Marguliesbimargul...@gmail.com wrote: From: Benson Marguliesbimargul...@gmail.com Subject: Re: [DISCUSS] SCM child-project URL composition To: Maven Developers Listdev@maven.apache.org 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
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 ja...@sonatype.com wrote: From: Jason van Zyl ja...@sonatype.com Subject: Re: [DISCUSS] SCM child-project URL composition To: Maven Developers List dev@maven.apache.org 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.) url absolute=truescm:git:https://... or B.) urlabsolute:scm:git:https://... Please decide folks ;) LieGrue, strub --- On Thu, 7/28/11, Stephen Connolly stephen.alan.conno...@gmail.com wrote: From: Stephen Connolly stephen.alan.conno...@gmail.com Subject: Re: [DISCUSS] SCM child-project URL composition To: Maven Developers List dev@maven.apache.org 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 bimargul...@gmail.com 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 jdca...@commonjava.org wrote: On 7/28/11 6:12 PM, Mark Struberg
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 ja...@sonatype.com wrote: From: Jason van Zyl ja...@sonatype.com Subject: Re: [DISCUSS] SCM child-project URL composition To: Maven Developers List dev@maven.apache.org 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 ja...@sonatype.com wrote: From: Jason van Zyl ja...@sonatype.com Subject: Re: [DISCUSS] SCM child-project URL composition To: Maven Developers List dev@maven.apache.org 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
Re: [DISCUSS] SCM child-project URL composition
I have some perhaps minor bad news about attributes. Attributes on the url/ element won't validate against the current schema. I had hoped to discover otherwise, but no such luck. The combine.children trick passes because it is inside of the 'any' inside the plugin configuration. I claim that the following is tolerable from a compatibility standpoint: 1) create a 4.0.1 XSD file that adds the necessary xs:anyAttribute (or specific attributes, if you prefer) to the url/ element. 2) Change default archetypes and the release plugin and friends to add this schema instead of the 4.0.0 schema. In other words, Mark's experiments show that, in *practical* terms, adding the attributes works. That leave the question of programs that actually pay attention to the schema itself. The only bad case would be some program out there which for some reason always validates against the 4.0.0 schema even if the schema declared at the top is 4.0.1. I don't believe in this. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
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 jdca...@commonjava.org 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 Foxbri...@infinity.nu 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 Strubergstrub...@yahoo.de 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: scm developerConnectionstaticscm:git:ssh://myserver:/../developerConnection 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 Foxbri...@infinity.nu wrote: From: Brian Foxbri...@infinity.nu Subject: Re: [DISCUSS] SCM child-project URL composition To: Maven Developers Listdev@maven.apache.org Date: Thursday, July 28, 2011, 7:23 PM On Thu, Jul 28, 2011 at 2:59 PM, John Caseyjdca...@commonjava.org 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
