You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Mark Struberg <st...@yahoo.de> on 2011/07/28 18:46:45 UTC
[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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
Posted by Benson Margulies <bi...@gmail.com>.
we already have the plugin config inheritance attributes in modello.
On Jul 28, 2011, at 7:27 PM, Stephen Connolly
<st...@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" <jd...@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="true">scm:git:https://...
>>>
>>> or
>>> B.)
>>> <url>absolute:scm:git:https://...
>>>
>>> Please decide folks ;)
>>>
>>> LieGrue,
>>> strub
>>>
>>> --- On Thu, 7/28/11, Stephen Connolly<st...@gmail.com>
> wrote:
>>>
>>>> From: Stephen Connolly<st...@gmail.com>
>>>> Subject: Re: [DISCUSS] SCM child-project URL composition
>>>> To: "Maven Developers List"<de...@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"<bi...@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<jd...@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 Margulies<bi...@gmail.com>
>>>> wrote:
>>>>>>>
>>>>>>>> From: Benson Margulies<bi...@gmail.com>
>>>>>>>> Subject: Re: [DISCUSS] SCM child-project
>>>> URL composition
>>>>>>>> To: "Maven Developers List"<de...@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<jd...@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
>>>>>>>> Struberg<st...@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<br...@infinity.nu>
>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> From: Brian Fox<br...@infinity.nu>
>>>>>>>>>>>> Subject: Re: [DISCUSS] SCM
>>>> child-project
>>>>>>>> URL composition
>>>>>>>>>>>> To: "Maven Developers
>>>> List"<de...@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<st...@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>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>
>>>>
> <developerConnection>staticscm: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<br...@infinity.nu>
>>>>>>>>>>>>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> From: Brian
>>>> Fox<br...@infinity.nu>
>>>>>>>>>>>>>> Subject: Re:
>>>> [DISCUSS] SCM
>>>>>>>> child-project URL
>>>>>>>>>>>>
>>>>>>>>>>>> composition
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> To: "Maven
>>>> Developers List"<de...@maven.apache.org>
>>>>>>>>>>>>>> Date: Thursday,
>>>> July 28, 2011,
>>>>>>>> 7:23 PM
>>>>>>>>>>>>>> On Thu, Jul 28,
>>>> 2011 at 2:59 PM,
>>>>>>>> John
>>>>>>>>>>>>>> Casey<jd...@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-unsubscribe@maven.apache.org
>>>>>>>>>>>>>>>> For
>>>> additional commands,
>>>>>>>> e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> John Casey
>>>>>>>>>>>>>>> Developer, PMC
>>>> Chair - Apache
>>>>>>>> Maven (http://maven.apache.org)
>>>>>>>>>>>>>>> Blog: http://www.johnofalltrades.name/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> To
>>>> unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>>>>> For additional
>>>> commands,
>>>>>>>> e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> To unsubscribe,
>>>> e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>>>> For additional
>>>> commands, e-mail:
>>>>>>>> dev-help@maven.apache.org
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>
>>>>>>>>>>>>> To unsubscribe,
>>>> e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>>> For additional
>>>> commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>> For additional commands,
>>>> e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>> For additional commands,
>>>> e-mail: dev-help@maven.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>> For additional commands, e-mail:
>>>> dev-help@maven.apache.org
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> John Casey
>>>>>>>>> Developer, PMC Chair - Apache Maven
>>>> (http://maven.apache.org)
>>>>>>>>> Blog: http://www.johnofalltrades.name/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> John Casey
>>>>>> Developer, PMC Chair - Apache Maven (http://maven.apache.org)
>>>>>> Blog: http://www.johnofalltrades.name/
>>>>>>
>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> --
>> John Casey
>> Developer, PMC Chair - Apache Maven (http://maven.apache.org)
>> Blog: http://www.johnofalltrades.name/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
Posted by Stephen Connolly <st...@gmail.com>.
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" <jd...@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="true">scm:git:https://...
>>
>> or
>> B.)
>> <url>absolute:scm:git:https://...
>>
>> Please decide folks ;)
>>
>> LieGrue,
>> strub
>>
>> --- On Thu, 7/28/11, Stephen Connolly<st...@gmail.com>
wrote:
>>
>>> From: Stephen Connolly<st...@gmail.com>
>>> Subject: Re: [DISCUSS] SCM child-project URL composition
>>> To: "Maven Developers List"<de...@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"<bi...@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<jd...@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 Margulies<bi...@gmail.com>
>>> wrote:
>>>>>>
>>>>>>> From: Benson Margulies<bi...@gmail.com>
>>>>>>> Subject: Re: [DISCUSS] SCM child-project
>>> URL composition
>>>>>>> To: "Maven Developers List"<de...@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<jd...@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
>>>>>>> Struberg<st...@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<br...@infinity.nu>
>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> From: Brian Fox<br...@infinity.nu>
>>>>>>>>>>> Subject: Re: [DISCUSS] SCM
>>> child-project
>>>>>>> URL composition
>>>>>>>>>>> To: "Maven Developers
>>> List"<de...@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<st...@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>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>
>>>
<developerConnection>staticscm: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<br...@infinity.nu>
>>>>>>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> From: Brian
>>> Fox<br...@infinity.nu>
>>>>>>>>>>>>> Subject: Re:
>>> [DISCUSS] SCM
>>>>>>> child-project URL
>>>>>>>>>>>
>>>>>>>>>>> composition
>>>>>>>>>>>>>
>>>>>>>>>>>>> To: "Maven
>>> Developers List"<de...@maven.apache.org>
>>>>>>>>>>>>> Date: Thursday,
>>> July 28, 2011,
>>>>>>> 7:23 PM
>>>>>>>>>>>>> On Thu, Jul 28,
>>> 2011 at 2:59 PM,
>>>>>>> John
>>>>>>>>>>>>> Casey<jd...@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-unsubscribe@maven.apache.org
>>>>>>>>>>>>>>> For
>>> additional commands,
>>>>>>> e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> John Casey
>>>>>>>>>>>>>> Developer, PMC
>>> Chair - Apache
>>>>>>> Maven (http://maven.apache.org)
>>>>>>>>>>>>>> Blog: http://www.johnofalltrades.name/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> To
>>> unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>>>> For additional
>>> commands,
>>>>>>> e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>
>>>>>>>>>>>>> To unsubscribe,
>>> e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>>> For additional
>>> commands, e-mail:
>>>>>>> dev-help@maven.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>>>>>>>
>>>>>>>>>>>> To unsubscribe,
>>> e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>> For additional
>>> commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>> For additional commands,
>>> e-mail: dev-help@maven.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>> For additional commands,
>>> e-mail: dev-help@maven.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail:
>>> dev-help@maven.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> John Casey
>>>>>>>> Developer, PMC Chair - Apache Maven
>>> (http://maven.apache.org)
>>>>>>>> Blog: http://www.johnofalltrades.name/
>>>>>>>>
>>>>>>>>
>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>
>>>>> --
>>>>> John Casey
>>>>> Developer, PMC Chair - Apache Maven (http://maven.apache.org)
>>>>> Blog: http://www.johnofalltrades.name/
>>>>>
>>>>>
>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> --
> John Casey
> Developer, PMC Chair - Apache Maven (http://maven.apache.org)
> Blog: http://www.johnofalltrades.name/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Re: [DISCUSS] SCM child-project URL composition
Posted by John Casey <jd...@commonjava.org>.
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="true">scm:git:https://...
>
> or
> B.)
> <url>absolute:scm:git:https://...
>
> Please decide folks ;)
>
> LieGrue,
> strub
>
> --- On Thu, 7/28/11, Stephen Connolly<st...@gmail.com> wrote:
>
>> From: Stephen Connolly<st...@gmail.com>
>> Subject: Re: [DISCUSS] SCM child-project URL composition
>> To: "Maven Developers List"<de...@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"<bi...@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<jd...@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 Margulies<bi...@gmail.com>
>> wrote:
>>>>>
>>>>>> From: Benson Margulies<bi...@gmail.com>
>>>>>> Subject: Re: [DISCUSS] SCM child-project
>> URL composition
>>>>>> To: "Maven Developers List"<de...@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<jd...@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
>>>>>> Struberg<st...@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<br...@infinity.nu>
>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> From: Brian Fox<br...@infinity.nu>
>>>>>>>>>> Subject: Re: [DISCUSS] SCM
>> child-project
>>>>>> URL composition
>>>>>>>>>> To: "Maven Developers
>> List"<de...@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<st...@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>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>> <developerConnection>staticscm: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<br...@infinity.nu>
>>>>>>>>>>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> From: Brian
>> Fox<br...@infinity.nu>
>>>>>>>>>>>> Subject: Re:
>> [DISCUSS] SCM
>>>>>> child-project URL
>>>>>>>>>>
>>>>>>>>>> composition
>>>>>>>>>>>>
>>>>>>>>>>>> To: "Maven
>> Developers List"<de...@maven.apache.org>
>>>>>>>>>>>> Date: Thursday,
>> July 28, 2011,
>>>>>> 7:23 PM
>>>>>>>>>>>> On Thu, Jul 28,
>> 2011 at 2:59 PM,
>>>>>> John
>>>>>>>>>>>> Casey<jd...@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-unsubscribe@maven.apache.org
>>>>>>>>>>>>>> For
>> additional commands,
>>>>>> e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> John Casey
>>>>>>>>>>>>> Developer, PMC
>> Chair - Apache
>>>>>> Maven (http://maven.apache.org)
>>>>>>>>>>>>> Blog: http://www.johnofalltrades.name/
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>>>>>>>
>>>>>>>>>>>>> To
>> unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>>> For additional
>> commands,
>>>>>> e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>>>>>>
>>>>>>>>>>>> To unsubscribe,
>> e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>> For additional
>> commands, e-mail:
>>>>>> dev-help@maven.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>> To unsubscribe,
>> e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>> For additional
>> commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>> For additional commands,
>> e-mail: dev-help@maven.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands,
>> e-mail: dev-help@maven.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail:
>> dev-help@maven.apache.org
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> John Casey
>>>>>>> Developer, PMC Chair - Apache Maven
>> (http://maven.apache.org)
>>>>>>> Blog: http://www.johnofalltrades.name/
>>>>>>>
>>>>>>>
>>>>>>
>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>> --
>>>> John Casey
>>>> Developer, PMC Chair - Apache Maven (http://maven.apache.org)
>>>> Blog: http://www.johnofalltrades.name/
>>>>
>>>>
>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>>
>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
John Casey
Developer, PMC Chair - Apache Maven (http://maven.apache.org)
Blog: http://www.johnofalltrades.name/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
Posted by Mark Struberg <st...@yahoo.de>.
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 <bi...@gmail.com> wrote:
> From: Benson Margulies <bi...@gmail.com>
> Subject: Re: [DISCUSS] SCM child-project URL composition
> To: "Maven Developers List" <de...@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
> <st...@gmail.com>
> wrote:
> > How about coming at this from a different track...
> >
> > <scm>scm:parent:/path/in/parent</scm>
> >
> > that is an SCM that is the same as parent with a path
> in the parent.
> >
> > the parent scm provider would look up the parent's scm
> and could use
> > some rules to derive the effective path, acting like a
> delegate and
> > giving us the correct path.
> >
> > It does mean that unless
> <prerequ><maven>3.1</maven></prerequ>
> users
> > would have to specify the scm in all initial child
> modules.
> >
> > On 29 July 2011 08:39, Mark Struberg <st...@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 <bi...@gmail.com>
> wrote:
> >>
> >>> From: Benson Margulies <bi...@gmail.com>
> >>> Subject: Re: [DISCUSS] SCM child-project URL
> composition
> >>> To: "Maven Developers List" <de...@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-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>
> >>>
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
Posted by Stephen Connolly <st...@gmail.com>.
On 29 July 2011 12:35, Benson Margulies <bi...@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
> <st...@gmail.com> wrote:
>> How about coming at this from a different track...
>>
>> <scm>scm:parent:/path/in/parent</scm>
>>
>> that is an SCM that is the same as parent with a path in the parent.
>>
>> the parent scm provider would look up the parent's scm and could use
>> some rules to derive the effective path, acting like a delegate and
>> giving us the correct path.
>>
>> It does mean that unless <prerequ><maven>3.1</maven></prerequ> users
>> would have to specify the scm in all initial child modules.
>>
>> On 29 July 2011 08:39, Mark Struberg <st...@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 <bi...@gmail.com> wrote:
>>>
>>>> From: Benson Margulies <bi...@gmail.com>
>>>> Subject: Re: [DISCUSS] SCM child-project URL composition
>>>> To: "Maven Developers List" <de...@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-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
Posted by Benson Margulies <bi...@gmail.com>.
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 <bi...@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
> <st...@gmail.com> wrote:
>> How about coming at this from a different track...
>>
>> <scm>scm:parent:/path/in/parent</scm>
>>
>> that is an SCM that is the same as parent with a path in the parent.
>>
>> the parent scm provider would look up the parent's scm and could use
>> some rules to derive the effective path, acting like a delegate and
>> giving us the correct path.
>>
>> It does mean that unless <prerequ><maven>3.1</maven></prerequ> users
>> would have to specify the scm in all initial child modules.
>>
>> On 29 July 2011 08:39, Mark Struberg <st...@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 <bi...@gmail.com> wrote:
>>>
>>>> From: Benson Margulies <bi...@gmail.com>
>>>> Subject: Re: [DISCUSS] SCM child-project URL composition
>>>> To: "Maven Developers List" <de...@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-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
Posted by Benson Margulies <bi...@gmail.com>.
On Sat, Jul 30, 2011 at 1:07 PM, Ralph Goers <ra...@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 <ra...@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 <jd...@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
>>>>>>> brett@apache.org
>>>>>>> http://brettporter.wordpress.com/
>>>>>>> http://au.linkedin.com/in/brettporter
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>
>>>>> --
>>>>> John Casey
>>>>> Developer, PMC Chair - Apache Maven (http://maven.apache.org)
>>>>> Blog: http://www.johnofalltrades.name/
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <ra...@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 <jd...@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
>>>>>> brett@apache.org
>>>>>> http://brettporter.wordpress.com/
>>>>>> http://au.linkedin.com/in/brettporter
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>> --
>>>> John Casey
>>>> Developer, PMC Chair - Apache Maven (http://maven.apache.org)
>>>> Blog: http://www.johnofalltrades.name/
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
Posted by Benson Margulies <bi...@gmail.com>.
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 <ra...@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 <jd...@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
>>>>> brett@apache.org
>>>>> http://brettporter.wordpress.com/
>>>>> http://au.linkedin.com/in/brettporter
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> --
>>> John Casey
>>> Developer, PMC Chair - Apache Maven (http://maven.apache.org)
>>> Blog: http://www.johnofalltrades.name/
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <jd...@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
>>>> brett@apache.org
>>>> http://brettporter.wordpress.com/
>>>> http://au.linkedin.com/in/brettporter
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> --
>> John Casey
>> Developer, PMC Chair - Apache Maven (http://maven.apache.org)
>> Blog: http://www.johnofalltrades.name/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
Posted by Benson Margulies <bi...@gmail.com>.
I think Herve said so.
On Jul 29, 2011, at 10:50 AM, John Casey <jd...@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
>>> brett@apache.org
>>> http://brettporter.wordpress.com/
>>> http://au.linkedin.com/in/brettporter
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> --
> John Casey
> Developer, PMC Chair - Apache Maven (http://maven.apache.org)
> Blog: http://www.johnofalltrades.name/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
Posted by John Casey <jd...@commonjava.org>.
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
>> brett@apache.org
>> http://brettporter.wordpress.com/
>> http://au.linkedin.com/in/brettporter
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
John Casey
Developer, PMC Chair - Apache Maven (http://maven.apache.org)
Blog: http://www.johnofalltrades.name/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
Posted by Benson Margulies <bi...@gmail.com>.
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
> brett@apache.org
> http://brettporter.wordpress.com/
> http://au.linkedin.com/in/brettporter
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
Posted by Brett Porter <br...@apache.org>.
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
brett@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
Posted by Benson Margulies <bi...@gmail.com>.
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
<st...@gmail.com> wrote:
> How about coming at this from a different track...
>
> <scm>scm:parent:/path/in/parent</scm>
>
> that is an SCM that is the same as parent with a path in the parent.
>
> the parent scm provider would look up the parent's scm and could use
> some rules to derive the effective path, acting like a delegate and
> giving us the correct path.
>
> It does mean that unless <prerequ><maven>3.1</maven></prerequ> users
> would have to specify the scm in all initial child modules.
>
> On 29 July 2011 08:39, Mark Struberg <st...@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 <bi...@gmail.com> wrote:
>>
>>> From: Benson Margulies <bi...@gmail.com>
>>> Subject: Re: [DISCUSS] SCM child-project URL composition
>>> To: "Maven Developers List" <de...@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-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
Posted by Stephen Connolly <st...@gmail.com>.
How about coming at this from a different track...
<scm>scm:parent:/path/in/parent</scm>
that is an SCM that is the same as parent with a path in the parent.
the parent scm provider would look up the parent's scm and could use
some rules to derive the effective path, acting like a delegate and
giving us the correct path.
It does mean that unless <prerequ><maven>3.1</maven></prerequ> users
would have to specify the scm in all initial child modules.
On 29 July 2011 08:39, Mark Struberg <st...@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 <bi...@gmail.com> wrote:
>
>> From: Benson Margulies <bi...@gmail.com>
>> Subject: Re: [DISCUSS] SCM child-project URL composition
>> To: "Maven Developers List" <de...@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
Posted by Mark Struberg <st...@yahoo.de>.
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 <bi...@gmail.com> wrote:
> From: Benson Margulies <bi...@gmail.com>
> Subject: Re: [DISCUSS] SCM child-project URL composition
> To: "Maven Developers List" <de...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
Posted by Benson Margulies <bi...@gmail.com>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
Posted by Mark Struberg <st...@yahoo.de>.
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 <he...@free.fr> wrote:
> From: Hervé BOUTEMY <he...@free.fr>
> Subject: Re: [DISCUSS] SCM child-project URL composition
> To: "Maven Developers List" <de...@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" <de...@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" <de...@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:
> > > >>
> > > >> git@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="true">scm:git:https://...
> > >
> > > >>> or
> > > >>> B.)
> > > >>>
> <url>absolute:scm:git:https://...
> > > >>>
> > > >>> Please decide folks ;)
> > > >>>
> > > >>> LieGrue,
> > > >>> strub
> > > >>>
> > > >>> --- On Thu, 7/28/11, Stephen
> Connolly
> > > >>> <st...@gmail.com>
> > > >>
> > > >> wrote:
> > > >>>> From: Stephen Connolly <st...@gmail.com>
> > > >>>> Subject: Re: [DISCUSS] SCM
> child-project
> > >
> > > URL
> > >
> > > >> composition
> > > >>
> > > >>>> To: "Maven Developers List"
> <de...@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"
> > >
> > > <bi...@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 <jd...@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
> > > >>
> > > >> Margulies<bi...@gmail.com>
> > > >>
> > > >>>> wrote:
> > > >>>>>>>> From: Benson
> > >
> > > Margulies<bi...@gmail.com>
> > >
> > > >>>>>>>> Subject: Re:
> [DISCUSS]
> > >
> > > SCM
> > >
> > > >> child-project
> > > >>
> > > >>>> URL composition
> > > >>>>
> > > >>>>>>>> To: "Maven
> Developers
> > >
> > > List"<de...@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<jd...@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
> > > >>>>
> > > >>>>>>>> Struberg<st...@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<br...@infinity.nu>
> > > >>>>
> > > >>>>>>>> wrote:
> > > >>>>>>>>>>>>
> From:
> > > Brian
> > >
> > > >> Fox<br...@infinity.nu>
> > > >>
> > > >>>>>>>>>>>>
> Subject:
> > > Re:
> > > >> [DISCUSS] SCM
> > > >>
> > > >>>> child-project
> > > >>>>
> > > >>>>>>>> URL composition
> > > >>>>>>>>
> > > >>>>>>>>>>>>
> To:
> > > "Maven
> > >
> > > >> Developers
> > > >>
> > > >>>> List"<de...@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<st...@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>
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> <developerConnection>staticscm:git:ssh://myserver:/..</developerConnectio
> > > n
> > >
> > >
> > > 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<br...@infinity.nu>
> > > >>>>
> > > >>>>>>>>>>>>
> wrote:
> > > From:
> > > >> Brian
> > > >>
> > > >>>> Fox<br...@infinity.nu>
> > >
> > > Subject:
> > > >> Re:
> > > >>>> [DISCUSS] SCM
> > > >>>>
> > > >>>>>>>> child-project
> URL
> > >
> > > composition
> > >
> > > To:
> > > >> "Maven
> > > >>
> > > >>>> Developers List"<de...@maven.apache.org>
> > >
> > > Date:
> > > >> Thursday,
> > > >>
> > > >>>> July 28, 2011,
> > > >>>>
> > > >>>>>>>> 7:23 PM
> > > >>>>>>>>
> > >
> >>>>>>>>>>>>>> On
> > >
> > > Thu,
> > >
> > > >> Jul 28,
> > > >>
> > > >>>> 2011 at 2:59 PM,
> > > >>>>
> > > >>>>>>>> John
> > > >>
> > > >> Casey<jd...@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-unsubscribe@maven.apache.org
> > > >>
> > > >> For
> > > >>
> > > >>>> additional commands,
> > > >>>>
> > > >>>>>>>> e-mail: dev-help@maven.apache.org
> > >
> > > --
> > >
> > > John
> > >
> > > >> Casey
> > > >>
> > > >>
> > > >> Developer, PMC
> > > >>
> > > >>>> Chair - Apache
> > > >>>>
> > > >>>>>>>> Maven (http://maven.apache.org)
> > >
> > > Blog:
> > > >> http://www.johnofalltrades.name/
> > >
> > >
> ---------------------------------------------------------------------
> > >
> > >
> > >
> > > To
> > >
> > > >>>> unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >
> > > For
> > >
> > > >> additional
> > > >>
> > > >>>> commands,
> > > >>>>
> > > >>>>>>>> e-mail: dev-help@maven.apache.org
> > >
> > >
> ---------------------------------------------------------------------
> > >
> > >
> > > To
> > >
> > > >> unsubscribe,
> > > >>
> > > >>>> e-mail: dev-unsubscribe@maven.apache.org
> > >
> > > For
> > >
> > > >> additional
> > > >>
> > > >>>> commands, e-mail:
> > > >>>>>>>> dev-help@maven.apache.org
> > >
> > >
> ---------------------------------------------------------------------
> > >
> > >
> >>>>>>>>>>>>> To
> > > >>
> > > >> unsubscribe,
> > > >>
> > > >>>> e-mail: dev-unsubscribe@maven.apache.org
> > > >>>>
> > >
> >>>>>>>>>>>>> For
> > > >>
> > > >> additional
> > > >>
> > > >>>> commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> ---------------------------------------------------------------------
> > >
> > > >>>>>>>>>>>>
> To
> > >
> > > unsubscribe,
> > >
> > > >> e-mail: dev-unsubscribe@maven.apache.org
> > > >>
> > > >>>>>>>>>>>>
> For
> > >
> > > additional
> > >
> > > >> commands,
> > > >>
> > > >>>> e-mail: dev-help@maven.apache.org
> > >
> > >
> ---------------------------------------------------------------------
> > >
> > > >>>>>>>>>>> To
> > >
> > > unsubscribe,
> > >
> > > >> e-mail: dev-unsubscribe@maven.apache.org
> > > >>
> > > >>>>>>>>>>> For
> > >
> > > additional
> > >
> > > >> commands,
> > > >>
> > > >>>> e-mail: dev-help@maven.apache.org
> > >
> > >
> ---------------------------------------------------------------------
> > >
> > > >>>>>>>>>> To
> unsubscribe,
> > >
> > > e-mail: dev-unsubscribe@maven.apache.org
> > >
> > > >>>>>>>>>> For
> additional
> > >
> > > commands,
> > >
> > > >> e-mail:
> > > >>>> dev-help@maven.apache.org
> > > >>>>
> > > >>>>>>>>> --
> > > >>>>>>>>> John Casey
> > > >>>>>>>>> Developer,
> PMC Chair -
> > >
> > > Apache
> > >
> > > >> Maven
> > > >>
> > > >>>> (http://maven.apache.org)
> > > >>>>
> > > >>>>>>>>> Blog: http://www.johnofalltrades.name/
> > >
> > >
> ---------------------------------------------------------------------
> > >
> > > >>>>>>>>> To
> unsubscribe,
> > >
> > > e-mail: dev-unsubscribe@maven.apache.org
> > >
> > > >>>>>>>>> For
> additional
> > >
> > > commands,
> > >
> > > >> e-mail: dev-help@maven.apache.org
> > >
> > >
> ---------------------------------------------------------------------
> > >
> > > >>>>>>>> To unsubscribe,
> e-mail: dev-unsubscribe@maven.apache.org
> > > >>>>>>>> For additional
> commands,
> > >
> > > e-mail:
> > > >> dev-help@maven.apache.org
> > >
> > >
> ---------------------------------------------------------------------
> > >
> > > >>>>>>> To unsubscribe,
> e-mail: dev-unsubscribe@maven.apache.org
> > > >>>>>>> For additional
> commands,
> > >
> > > e-mail: dev-help@maven.apache.org
> > >
> > > >>>>>> --
> > > >>>>>> John Casey
> > > >>>>>> Developer, PMC Chair -
> Apache
> > >
> > > Maven (http://maven.apache.org)
> > >
> > > >>>>>> Blog: http://www.johnofalltrades.name/
> > >
> > >
> ---------------------------------------------------------------------
> > >
> > > >>>>>> To unsubscribe, e-mail:
> dev-unsubscribe@maven.apache.org
> > >
> > > >>>>>> For additional commands,
> e-mail:
> > > dev-help@maven.apache.org
> > >
> > >
> > >
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > >
> > > >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > >>>>> For additional commands,
> e-mail: dev-help@maven.apache.org
> > >
> > >
> ---------------------------------------------------------------------
> > >
> > > >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > >>> For additional commands, e-mail: dev-help@maven.apache.org
> > > >>
> > > >> Thanks,
> > > >>
> > > >> Jason
> > >
> > >
> ----------------------------------------------------------
> > >
> > > >> Jason van Zyl
> > > >> Founder, Apache Maven
> > > >> http://twitter.com/jvanzyl
> > >
> > >
> ---------------------------------------------------------
> > >
> > > >> You are never dedicated to something you
> have
> > >
> > > complete
> > >
> > > >> confidence in.
> > > >> No one is fanatically shouting that the
> sun is
> > >
> > > going to
> > >
> > > >> rise tomorrow.
> > > >> They know it is going to rise tomorrow.
> When
> > >
> > > people are
> > >
> > > >> fanatically
> > > >> dedicated to political or religious
> faiths or any
> > >
> > > other
> > >
> > > >> kind of
> > > >> dogmas or goals, it's always because
> these dogmas
> > >
> > > or
> > >
> > > >> goals are in doubt.
> > > >>
> > > >> -- Robert Pirzig, Zen
> and the Art
> > >
> > > of Motorcycle
> > >
> > > >> Maintenance
> > >
> > >
> ---------------------------------------------------------------------
> > >
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > > Thanks,
> > >
> > > Jason
> > >
> > >
> ----------------------------------------------------------
> > > Jason van Zyl
> > > Founder, Apache Maven
> > > http://twitter.com/jvanzyl
> > >
> ---------------------------------------------------------
> > >
> > > What matters is not ideas, but the people who
> have them.
> > > Good people can fix bad ideas, but good ideas
> can't save bad
> > > people.
> > >
> > > -- Paul Graham
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
Posted by Hervé BOUTEMY <he...@free.fr>.
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" <de...@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" <de...@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:
> > >>
> > >> git@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="true">scm:git:https://...
> >
> > >>> or
> > >>> B.)
> > >>> <url>absolute:scm:git:https://...
> > >>>
> > >>> Please decide folks ;)
> > >>>
> > >>> LieGrue,
> > >>> strub
> > >>>
> > >>> --- On Thu, 7/28/11, Stephen Connolly
> > >>> <st...@gmail.com>
> > >>
> > >> wrote:
> > >>>> From: Stephen Connolly <st...@gmail.com>
> > >>>> Subject: Re: [DISCUSS] SCM child-project
> >
> > URL
> >
> > >> composition
> > >>
> > >>>> To: "Maven Developers List" <de...@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"
> >
> > <bi...@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 <jd...@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
> > >>
> > >> Margulies<bi...@gmail.com>
> > >>
> > >>>> wrote:
> > >>>>>>>> From: Benson
> >
> > Margulies<bi...@gmail.com>
> >
> > >>>>>>>> Subject: Re: [DISCUSS]
> >
> > SCM
> >
> > >> child-project
> > >>
> > >>>> URL composition
> > >>>>
> > >>>>>>>> To: "Maven Developers
> >
> > List"<de...@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<jd...@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
> > >>>>
> > >>>>>>>> Struberg<st...@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<br...@infinity.nu>
> > >>>>
> > >>>>>>>> wrote:
> > >>>>>>>>>>>> From:
> > Brian
> >
> > >> Fox<br...@infinity.nu>
> > >>
> > >>>>>>>>>>>> Subject:
> > Re:
> > >> [DISCUSS] SCM
> > >>
> > >>>> child-project
> > >>>>
> > >>>>>>>> URL composition
> > >>>>>>>>
> > >>>>>>>>>>>> To:
> > "Maven
> >
> > >> Developers
> > >>
> > >>>> List"<de...@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<st...@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>
> >
> >
> >
> >
> >
> >
> > <developerConnection>staticscm:git:ssh://myserver:/..</developerConnectio
> > n
> >
> >
> > 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<br...@infinity.nu>
> > >>>>
> > >>>>>>>>>>>> wrote:
> > From:
> > >> Brian
> > >>
> > >>>> Fox<br...@infinity.nu>
> >
> > Subject:
> > >> Re:
> > >>>> [DISCUSS] SCM
> > >>>>
> > >>>>>>>> child-project URL
> >
> > composition
> >
> > To:
> > >> "Maven
> > >>
> > >>>> Developers List"<de...@maven.apache.org>
> >
> > Date:
> > >> Thursday,
> > >>
> > >>>> July 28, 2011,
> > >>>>
> > >>>>>>>> 7:23 PM
> > >>>>>>>>
> > >>>>>>>>>>>>>> On
> >
> > Thu,
> >
> > >> Jul 28,
> > >>
> > >>>> 2011 at 2:59 PM,
> > >>>>
> > >>>>>>>> John
> > >>
> > >> Casey<jd...@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-unsubscribe@maven.apache.org
> > >>
> > >> For
> > >>
> > >>>> additional commands,
> > >>>>
> > >>>>>>>> e-mail: dev-help@maven.apache.org
> >
> > --
> >
> > John
> >
> > >> Casey
> > >>
> > >>
> > >> Developer, PMC
> > >>
> > >>>> Chair - Apache
> > >>>>
> > >>>>>>>> Maven (http://maven.apache.org)
> >
> > Blog:
> > >> http://www.johnofalltrades.name/
> >
> > ---------------------------------------------------------------------
> >
> >
> >
> > To
> >
> > >>>> unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >
> > For
> >
> > >> additional
> > >>
> > >>>> commands,
> > >>>>
> > >>>>>>>> e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> >
> >
> > To
> >
> > >> unsubscribe,
> > >>
> > >>>> e-mail: dev-unsubscribe@maven.apache.org
> >
> > For
> >
> > >> additional
> > >>
> > >>>> commands, e-mail:
> > >>>>>>>> dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> >
> > >>>>>>>>>>>>> To
> > >>
> > >> unsubscribe,
> > >>
> > >>>> e-mail: dev-unsubscribe@maven.apache.org
> > >>>>
> > >>>>>>>>>>>>> For
> > >>
> > >> additional
> > >>
> > >>>> commands, e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> >
> > >>>>>>>>>>>> To
> >
> > unsubscribe,
> >
> > >> e-mail: dev-unsubscribe@maven.apache.org
> > >>
> > >>>>>>>>>>>> For
> >
> > additional
> >
> > >> commands,
> > >>
> > >>>> e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> >
> > >>>>>>>>>>> To
> >
> > unsubscribe,
> >
> > >> e-mail: dev-unsubscribe@maven.apache.org
> > >>
> > >>>>>>>>>>> For
> >
> > additional
> >
> > >> commands,
> > >>
> > >>>> e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> >
> > >>>>>>>>>> To unsubscribe,
> >
> > e-mail: dev-unsubscribe@maven.apache.org
> >
> > >>>>>>>>>> For additional
> >
> > commands,
> >
> > >> e-mail:
> > >>>> dev-help@maven.apache.org
> > >>>>
> > >>>>>>>>> --
> > >>>>>>>>> John Casey
> > >>>>>>>>> Developer, PMC Chair -
> >
> > Apache
> >
> > >> Maven
> > >>
> > >>>> (http://maven.apache.org)
> > >>>>
> > >>>>>>>>> Blog: http://www.johnofalltrades.name/
> >
> > ---------------------------------------------------------------------
> >
> > >>>>>>>>> To unsubscribe,
> >
> > e-mail: dev-unsubscribe@maven.apache.org
> >
> > >>>>>>>>> For additional
> >
> > commands,
> >
> > >> e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> >
> > >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >>>>>>>> For additional commands,
> >
> > e-mail:
> > >> dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> >
> > >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >>>>>>> For additional commands,
> >
> > e-mail: dev-help@maven.apache.org
> >
> > >>>>>> --
> > >>>>>> John Casey
> > >>>>>> Developer, PMC Chair - Apache
> >
> > Maven (http://maven.apache.org)
> >
> > >>>>>> Blog: http://www.johnofalltrades.name/
> >
> > ---------------------------------------------------------------------
> >
> > >>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >
> > >>>>>> For additional commands, e-mail:
> > dev-help@maven.apache.org
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> >
> > >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> >
> > >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >>> For additional commands, e-mail: dev-help@maven.apache.org
> > >>
> > >> Thanks,
> > >>
> > >> Jason
> >
> > ----------------------------------------------------------
> >
> > >> Jason van Zyl
> > >> Founder, Apache Maven
> > >> http://twitter.com/jvanzyl
> >
> > ---------------------------------------------------------
> >
> > >> You are never dedicated to something you have
> >
> > complete
> >
> > >> confidence in.
> > >> No one is fanatically shouting that the sun is
> >
> > going to
> >
> > >> rise tomorrow.
> > >> They know it is going to rise tomorrow. When
> >
> > people are
> >
> > >> fanatically
> > >> dedicated to political or religious faiths or any
> >
> > other
> >
> > >> kind of
> > >> dogmas or goals, it's always because these dogmas
> >
> > or
> >
> > >> goals are in doubt.
> > >>
> > >> -- Robert Pirzig, Zen and the Art
> >
> > of Motorcycle
> >
> > >> Maintenance
> >
> > ---------------------------------------------------------------------
> >
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> >
> > Thanks,
> >
> > Jason
> >
> > ----------------------------------------------------------
> > Jason van Zyl
> > Founder, Apache Maven
> > http://twitter.com/jvanzyl
> > ---------------------------------------------------------
> >
> > What matters is not ideas, but the people who have them.
> > Good people can fix bad ideas, but good ideas can't save bad
> > people.
> >
> > -- Paul Graham
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
Posted by Mark Struberg <st...@yahoo.de>.
> 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" <de...@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" <de...@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:
> >>
> >> git@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="true">scm:git:https://...
> >>>
> >>> or
> >>> B.)
> >>> <url>absolute:scm:git:https://...
> >>>
> >>> Please decide folks ;)
> >>>
> >>> LieGrue,
> >>> strub
> >>>
> >>> --- On Thu, 7/28/11, Stephen Connolly <st...@gmail.com>
> >> wrote:
> >>>
> >>>> From: Stephen Connolly <st...@gmail.com>
> >>>> Subject: Re: [DISCUSS] SCM child-project
> URL
> >> composition
> >>>> To: "Maven Developers List" <de...@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"
> <bi...@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 <jd...@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
> >> Margulies<bi...@gmail.com>
> >>>> wrote:
> >>>>>>>
> >>>>>>>> From: Benson
> Margulies<bi...@gmail.com>
> >>>>>>>> Subject: Re: [DISCUSS]
> SCM
> >> child-project
> >>>> URL composition
> >>>>>>>> To: "Maven Developers
> List"<de...@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<jd...@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
> >>>>>>>> Struberg<st...@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<br...@infinity.nu>
> >>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> From:
> Brian
> >> Fox<br...@infinity.nu>
> >>>>>>>>>>>> Subject:
> Re:
> >> [DISCUSS] SCM
> >>>> child-project
> >>>>>>>> URL composition
> >>>>>>>>>>>> To:
> "Maven
> >> Developers
> >>>> List"<de...@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<st...@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>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>
> >>>>
> >>
> <developerConnection>staticscm: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<br...@infinity.nu>
> >>>>>>>>>>>>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> From:
> >> Brian
> >>>> Fox<br...@infinity.nu>
> >>>>>>>>>>>>>>
> Subject:
> >> Re:
> >>>> [DISCUSS] SCM
> >>>>>>>> child-project URL
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> composition
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> To:
> >> "Maven
> >>>> Developers List"<de...@maven.apache.org>
> >>>>>>>>>>>>>>
> Date:
> >> Thursday,
> >>>> July 28, 2011,
> >>>>>>>> 7:23 PM
> >>>>>>>>>>>>>> On
> Thu,
> >> Jul 28,
> >>>> 2011 at 2:59 PM,
> >>>>>>>> John
> >>>>>>>>>>>>>>
> >> Casey<jd...@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-unsubscribe@maven.apache.org
> >>>>>>>>>>>>>>>>
>
> >> For
> >>>> additional commands,
> >>>>>>>> e-mail: dev-help@maven.apache.org
> >>>>>>>>>>>>>>>>
>
> >>>>>>>>>>>>>>>
>
> >>>>>>>>>>>>>>>
> --
> >>>>>>>>>>>>>>>
> John
> >> Casey
> >>>>>>>>>>>>>>>
>
> >> Developer, PMC
> >>>> Chair - Apache
> >>>>>>>> Maven (http://maven.apache.org)
> >>>>>>>>>>>>>>>
> Blog:
> >> http://www.johnofalltrades.name/
> >>>>>>>>>>>>>>>
>
> >>>>>>>>>>>>>>>
>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>
> >>>>
> >>
> ---------------------------------------------------------------------
> >>>>>>>>>>>>>>>
>
> >>>>>>>>>>>>>>>
> To
> >>>> unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>>>>>>>>>
> For
> >> additional
> >>>> commands,
> >>>>>>>> e-mail: dev-help@maven.apache.org
> >>>>>>>>>>>>>>>
>
> >>>>>>>>>>>>>>>
>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>
> >>>>
> >>
> ---------------------------------------------------------------------
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> To
> >> unsubscribe,
> >>>> e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>>>>>>>>
> For
> >> additional
> >>>> commands, e-mail:
> >>>>>>>> dev-help@maven.apache.org
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>
> >>>>
> >>
> ---------------------------------------------------------------------
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> To
> >> unsubscribe,
> >>>> e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>>>>>>> For
> >> additional
> >>>> commands, e-mail: dev-help@maven.apache.org
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>
> >>>>
> >>
> ---------------------------------------------------------------------
> >>>>>>>>>>>> To
> unsubscribe,
> >> e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>>>>>> For
> additional
> >> commands,
> >>>> e-mail: dev-help@maven.apache.org
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>
> >>>>
> >>
> ---------------------------------------------------------------------
> >>>>>>>>>>> To
> unsubscribe,
> >> e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>>>>> For
> additional
> >> commands,
> >>>> e-mail: dev-help@maven.apache.org
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>
> >>
> ---------------------------------------------------------------------
> >>>>>>>>>> To unsubscribe,
> e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>>>> For additional
> commands,
> >> e-mail:
> >>>> dev-help@maven.apache.org
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> John Casey
> >>>>>>>>> Developer, PMC Chair -
> Apache
> >> Maven
> >>>> (http://maven.apache.org)
> >>>>>>>>> Blog: http://www.johnofalltrades.name/
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>
> >>
> ---------------------------------------------------------------------
> >>>>>>>>> To unsubscribe,
> e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>>> For additional
> commands,
> >> e-mail: dev-help@maven.apache.org
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>
> >>
> ---------------------------------------------------------------------
> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>> For additional commands,
> e-mail:
> >> dev-help@maven.apache.org
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>
> >>
> ---------------------------------------------------------------------
> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>> For additional commands,
> e-mail: dev-help@maven.apache.org
> >>>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> John Casey
> >>>>>> Developer, PMC Chair - Apache
> Maven (http://maven.apache.org)
> >>>>>> Blog: http://www.johnofalltrades.name/
> >>>>>>
> >>>>>>
> >>>>
> >>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>> For additional commands, e-mail:
> dev-help@maven.apache.org
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>
> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>
> >>>>
> >>>
> >>>
> >>
> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>
> >>
> >> Thanks,
> >>
> >> Jason
> >>
> >>
> ----------------------------------------------------------
> >> Jason van Zyl
> >> Founder, Apache Maven
> >> http://twitter.com/jvanzyl
> >>
> ---------------------------------------------------------
> >>
> >> You are never dedicated to something you have
> complete
> >> confidence in.
> >> No one is fanatically shouting that the sun is
> going to
> >> rise tomorrow.
> >> They know it is going to rise tomorrow. When
> people are
> >> fanatically
> >> dedicated to political or religious faiths or any
> other
> >> kind of
> >> dogmas or goals, it's always because these dogmas
> or
> >> goals are in doubt.
> >>
> >> -- Robert Pirzig, Zen and the Art
> of Motorcycle
> >> Maintenance
> >>
> >>
> >>
> >>
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> What matters is not ideas, but the people who have them.
> Good people can fix bad ideas, but good ideas can't save bad
> people.
>
> -- Paul Graham
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
Posted by Jason van Zyl <ja...@sonatype.com>.
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" <de...@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:
>>
>> git@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="true">scm:git:https://...
>>>
>>> or
>>> B.)
>>> <url>absolute:scm:git:https://...
>>>
>>> Please decide folks ;)
>>>
>>> LieGrue,
>>> strub
>>>
>>> --- On Thu, 7/28/11, Stephen Connolly <st...@gmail.com>
>> wrote:
>>>
>>>> From: Stephen Connolly <st...@gmail.com>
>>>> Subject: Re: [DISCUSS] SCM child-project URL
>> composition
>>>> To: "Maven Developers List" <de...@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" <bi...@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 <jd...@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
>> Margulies<bi...@gmail.com>
>>>> wrote:
>>>>>>>
>>>>>>>> From: Benson Margulies<bi...@gmail.com>
>>>>>>>> Subject: Re: [DISCUSS] SCM
>> child-project
>>>> URL composition
>>>>>>>> To: "Maven Developers List"<de...@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<jd...@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
>>>>>>>> Struberg<st...@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<br...@infinity.nu>
>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> From: Brian
>> Fox<br...@infinity.nu>
>>>>>>>>>>>> Subject: Re:
>> [DISCUSS] SCM
>>>> child-project
>>>>>>>> URL composition
>>>>>>>>>>>> To: "Maven
>> Developers
>>>> List"<de...@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<st...@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>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>
>>>>
>> <developerConnection>staticscm: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<br...@infinity.nu>
>>>>>>>>>>>>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> From:
>> Brian
>>>> Fox<br...@infinity.nu>
>>>>>>>>>>>>>> Subject:
>> Re:
>>>> [DISCUSS] SCM
>>>>>>>> child-project URL
>>>>>>>>>>>>
>>>>>>>>>>>> composition
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> To:
>> "Maven
>>>> Developers List"<de...@maven.apache.org>
>>>>>>>>>>>>>> Date:
>> Thursday,
>>>> July 28, 2011,
>>>>>>>> 7:23 PM
>>>>>>>>>>>>>> On Thu,
>> Jul 28,
>>>> 2011 at 2:59 PM,
>>>>>>>> John
>>>>>>>>>>>>>>
>> Casey<jd...@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-unsubscribe@maven.apache.org
>>>>>>>>>>>>>>>>
>> For
>>>> additional commands,
>>>>>>>> e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> John
>> Casey
>>>>>>>>>>>>>>>
>> Developer, PMC
>>>> Chair - Apache
>>>>>>>> Maven (http://maven.apache.org)
>>>>>>>>>>>>>>> Blog:
>> http://www.johnofalltrades.name/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>
>>>>
>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> To
>>>> unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>>>>> For
>> additional
>>>> commands,
>>>>>>>> e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>
>>>>
>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> To
>> unsubscribe,
>>>> e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>>>> For
>> additional
>>>> commands, e-mail:
>>>>>>>> dev-help@maven.apache.org
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>
>>>>
>> ---------------------------------------------------------------------
>>>>>>>>>>>>>
>>>>>>>>>>>>> To
>> unsubscribe,
>>>> e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>>> For
>> additional
>>>> commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>
>>>>
>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe,
>> e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>> For additional
>> commands,
>>>> e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>
>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe,
>> e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>> For additional
>> commands,
>>>> e-mail: dev-help@maven.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>
>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>> For additional commands,
>> e-mail:
>>>> dev-help@maven.apache.org
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> John Casey
>>>>>>>>> Developer, PMC Chair - Apache
>> Maven
>>>> (http://maven.apache.org)
>>>>>>>>> Blog: http://www.johnofalltrades.name/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>
>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands,
>> e-mail: dev-help@maven.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>
>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail:
>> dev-help@maven.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> John Casey
>>>>>> Developer, PMC Chair - Apache Maven (http://maven.apache.org)
>>>>>> Blog: http://www.johnofalltrades.name/
>>>>>>
>>>>>>
>>>>
>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>
>>>>>
>>>>
>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>
>>>
>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> http://twitter.com/jvanzyl
>> ---------------------------------------------------------
>>
>> You are never dedicated to something you have complete
>> confidence in.
>> No one is fanatically shouting that the sun is going to
>> rise tomorrow.
>> They know it is going to rise tomorrow. When people are
>> fanatically
>> dedicated to political or religious faiths or any other
>> kind of
>> dogmas or goals, it's always because these dogmas or
>> goals are in doubt.
>>
>> -- Robert Pirzig, Zen and the Art of Motorcycle
>> Maintenance
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people.
-- Paul Graham
Re: [DISCUSS] SCM child-project URL composition
Posted by Mark Struberg <st...@yahoo.de>.
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" <de...@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:
>
> git@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="true">scm:git:https://...
> >
> > or
> > B.)
> > <url>absolute:scm:git:https://...
> >
> > Please decide folks ;)
> >
> > LieGrue,
> > strub
> >
> > --- On Thu, 7/28/11, Stephen Connolly <st...@gmail.com>
> wrote:
> >
> >> From: Stephen Connolly <st...@gmail.com>
> >> Subject: Re: [DISCUSS] SCM child-project URL
> composition
> >> To: "Maven Developers List" <de...@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" <bi...@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 <jd...@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
> Margulies<bi...@gmail.com>
> >> wrote:
> >>>>>
> >>>>>> From: Benson Margulies<bi...@gmail.com>
> >>>>>> Subject: Re: [DISCUSS] SCM
> child-project
> >> URL composition
> >>>>>> To: "Maven Developers List"<de...@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<jd...@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
> >>>>>> Struberg<st...@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<br...@infinity.nu>
> >>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> From: Brian
> Fox<br...@infinity.nu>
> >>>>>>>>>> Subject: Re:
> [DISCUSS] SCM
> >> child-project
> >>>>>> URL composition
> >>>>>>>>>> To: "Maven
> Developers
> >> List"<de...@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<st...@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>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>
> >>
> <developerConnection>staticscm: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<br...@infinity.nu>
> >>>>>>>>>>
> >>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> From:
> Brian
> >> Fox<br...@infinity.nu>
> >>>>>>>>>>>> Subject:
> Re:
> >> [DISCUSS] SCM
> >>>>>> child-project URL
> >>>>>>>>>>
> >>>>>>>>>> composition
> >>>>>>>>>>>>
> >>>>>>>>>>>> To:
> "Maven
> >> Developers List"<de...@maven.apache.org>
> >>>>>>>>>>>> Date:
> Thursday,
> >> July 28, 2011,
> >>>>>> 7:23 PM
> >>>>>>>>>>>> On Thu,
> Jul 28,
> >> 2011 at 2:59 PM,
> >>>>>> John
> >>>>>>>>>>>>
> Casey<jd...@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-unsubscribe@maven.apache.org
> >>>>>>>>>>>>>>
> For
> >> additional commands,
> >>>>>> e-mail: dev-help@maven.apache.org
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> --
> >>>>>>>>>>>>> John
> Casey
> >>>>>>>>>>>>>
> Developer, PMC
> >> Chair - Apache
> >>>>>> Maven (http://maven.apache.org)
> >>>>>>>>>>>>> Blog:
> http://www.johnofalltrades.name/
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>
> >>
> ---------------------------------------------------------------------
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> To
> >> unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>>>>>>> For
> additional
> >> commands,
> >>>>>> e-mail: dev-help@maven.apache.org
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>
> >>
> ---------------------------------------------------------------------
> >>>>>>>>>>>>
> >>>>>>>>>>>> To
> unsubscribe,
> >> e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>>>>>> For
> additional
> >> commands, e-mail:
> >>>>>> dev-help@maven.apache.org
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>
> >>
> ---------------------------------------------------------------------
> >>>>>>>>>>>
> >>>>>>>>>>> To
> unsubscribe,
> >> e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>>>>> For
> additional
> >> commands, e-mail: dev-help@maven.apache.org
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>
> >>
> ---------------------------------------------------------------------
> >>>>>>>>>> To unsubscribe,
> e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>>>> For additional
> commands,
> >> e-mail: dev-help@maven.apache.org
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>
> >>
> ---------------------------------------------------------------------
> >>>>>>>>> To unsubscribe,
> e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>>> For additional
> commands,
> >> e-mail: dev-help@maven.apache.org
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>
> ---------------------------------------------------------------------
> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>> For additional commands,
> e-mail:
> >> dev-help@maven.apache.org
> >>>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> John Casey
> >>>>>>> Developer, PMC Chair - Apache
> Maven
> >> (http://maven.apache.org)
> >>>>>>> Blog: http://www.johnofalltrades.name/
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>
> ---------------------------------------------------------------------
> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>> For additional commands,
> e-mail: dev-help@maven.apache.org
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>> For additional commands, e-mail:
> dev-help@maven.apache.org
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>
> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>
> >>>>
> >>>> --
> >>>> John Casey
> >>>> Developer, PMC Chair - Apache Maven (http://maven.apache.org)
> >>>> Blog: http://www.johnofalltrades.name/
> >>>>
> >>>>
> >>
> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>
> >>>
> >>>
> >>
> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>
> >>
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> You are never dedicated to something you have complete
> confidence in.
> No one is fanatically shouting that the sun is going to
> rise tomorrow.
> They know it is going to rise tomorrow. When people are
> fanatically
> dedicated to political or religious faiths or any other
> kind of
> dogmas or goals, it's always because these dogmas or
> goals are in doubt.
>
> -- Robert Pirzig, Zen and the Art of Motorcycle
> Maintenance
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
Posted by Jason van Zyl <ja...@sonatype.com>.
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:
git@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="true">scm:git:https://...
>
> or
> B.)
> <url>absolute:scm:git:https://...
>
> Please decide folks ;)
>
> LieGrue,
> strub
>
> --- On Thu, 7/28/11, Stephen Connolly <st...@gmail.com> wrote:
>
>> From: Stephen Connolly <st...@gmail.com>
>> Subject: Re: [DISCUSS] SCM child-project URL composition
>> To: "Maven Developers List" <de...@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" <bi...@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 <jd...@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 Margulies<bi...@gmail.com>
>> wrote:
>>>>>
>>>>>> From: Benson Margulies<bi...@gmail.com>
>>>>>> Subject: Re: [DISCUSS] SCM child-project
>> URL composition
>>>>>> To: "Maven Developers List"<de...@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<jd...@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
>>>>>> Struberg<st...@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<br...@infinity.nu>
>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> From: Brian Fox<br...@infinity.nu>
>>>>>>>>>> Subject: Re: [DISCUSS] SCM
>> child-project
>>>>>> URL composition
>>>>>>>>>> To: "Maven Developers
>> List"<de...@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<st...@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>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>> <developerConnection>staticscm: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<br...@infinity.nu>
>>>>>>>>>>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> From: Brian
>> Fox<br...@infinity.nu>
>>>>>>>>>>>> Subject: Re:
>> [DISCUSS] SCM
>>>>>> child-project URL
>>>>>>>>>>
>>>>>>>>>> composition
>>>>>>>>>>>>
>>>>>>>>>>>> To: "Maven
>> Developers List"<de...@maven.apache.org>
>>>>>>>>>>>> Date: Thursday,
>> July 28, 2011,
>>>>>> 7:23 PM
>>>>>>>>>>>> On Thu, Jul 28,
>> 2011 at 2:59 PM,
>>>>>> John
>>>>>>>>>>>> Casey<jd...@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-unsubscribe@maven.apache.org
>>>>>>>>>>>>>> For
>> additional commands,
>>>>>> e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> John Casey
>>>>>>>>>>>>> Developer, PMC
>> Chair - Apache
>>>>>> Maven (http://maven.apache.org)
>>>>>>>>>>>>> Blog: http://www.johnofalltrades.name/
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>>>>>>>
>>>>>>>>>>>>> To
>> unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>>> For additional
>> commands,
>>>>>> e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>>>>>>
>>>>>>>>>>>> To unsubscribe,
>> e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>> For additional
>> commands, e-mail:
>>>>>> dev-help@maven.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>> To unsubscribe,
>> e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>> For additional
>> commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>> For additional commands,
>> e-mail: dev-help@maven.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands,
>> e-mail: dev-help@maven.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail:
>> dev-help@maven.apache.org
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> John Casey
>>>>>>> Developer, PMC Chair - Apache Maven
>> (http://maven.apache.org)
>>>>>>> Blog: http://www.johnofalltrades.name/
>>>>>>>
>>>>>>>
>>>>>>
>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>> --
>>>> John Casey
>>>> Developer, PMC Chair - Apache Maven (http://maven.apache.org)
>>>> Blog: http://www.johnofalltrades.name/
>>>>
>>>>
>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>>
>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
You are never dedicated to something you have complete confidence in.
No one is fanatically shouting that the sun is going to rise tomorrow.
They know it is going to rise tomorrow. When people are fanatically
dedicated to political or religious faiths or any other kind of
dogmas or goals, it's always because these dogmas or
goals are in doubt.
-- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
Re: [DISCUSS] SCM child-project URL composition
Posted by Mark Struberg <st...@yahoo.de>.
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="true">scm:git:https://...
or
B.)
<url>absolute:scm:git:https://...
Please decide folks ;)
LieGrue,
strub
--- On Thu, 7/28/11, Stephen Connolly <st...@gmail.com> wrote:
> From: Stephen Connolly <st...@gmail.com>
> Subject: Re: [DISCUSS] SCM child-project URL composition
> To: "Maven Developers List" <de...@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" <bi...@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 <jd...@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 Margulies<bi...@gmail.com>
> wrote:
> >>>
> >>>> From: Benson Margulies<bi...@gmail.com>
> >>>> Subject: Re: [DISCUSS] SCM child-project
> URL composition
> >>>> To: "Maven Developers List"<de...@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<jd...@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
> >>>> Struberg<st...@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<br...@infinity.nu>
> >>>> wrote:
> >>>>>>>
> >>>>>>>> From: Brian Fox<br...@infinity.nu>
> >>>>>>>> Subject: Re: [DISCUSS] SCM
> child-project
> >>>> URL composition
> >>>>>>>> To: "Maven Developers
> List"<de...@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<st...@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>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>
> <developerConnection>staticscm: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<br...@infinity.nu>
> >>>>>>>>
> >>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> From: Brian
> Fox<br...@infinity.nu>
> >>>>>>>>>> Subject: Re:
> [DISCUSS] SCM
> >>>> child-project URL
> >>>>>>>>
> >>>>>>>> composition
> >>>>>>>>>>
> >>>>>>>>>> To: "Maven
> Developers List"<de...@maven.apache.org>
> >>>>>>>>>> Date: Thursday,
> July 28, 2011,
> >>>> 7:23 PM
> >>>>>>>>>> On Thu, Jul 28,
> 2011 at 2:59 PM,
> >>>> John
> >>>>>>>>>> Casey<jd...@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-unsubscribe@maven.apache.org
> >>>>>>>>>>>> For
> additional commands,
> >>>> e-mail: dev-help@maven.apache.org
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> --
> >>>>>>>>>>> John Casey
> >>>>>>>>>>> Developer, PMC
> Chair - Apache
> >>>> Maven (http://maven.apache.org)
> >>>>>>>>>>> Blog: http://www.johnofalltrades.name/
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>
> ---------------------------------------------------------------------
> >>>>>>>>>>>
> >>>>>>>>>>> To
> unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>>>>> For additional
> commands,
> >>>> e-mail: dev-help@maven.apache.org
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>
> ---------------------------------------------------------------------
> >>>>>>>>>>
> >>>>>>>>>> To unsubscribe,
> e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>>>> For additional
> commands, e-mail:
> >>>> dev-help@maven.apache.org
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>
> ---------------------------------------------------------------------
> >>>>>>>>>
> >>>>>>>>> To unsubscribe,
> e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>>> For additional
> commands, e-mail: dev-help@maven.apache.org
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>
> ---------------------------------------------------------------------
> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>> For additional commands,
> e-mail: dev-help@maven.apache.org
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>
> ---------------------------------------------------------------------
> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>> For additional commands,
> e-mail: dev-help@maven.apache.org
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>> For additional commands, e-mail:
> dev-help@maven.apache.org
> >>>>>>
> >>>>>
> >>>>> --
> >>>>> John Casey
> >>>>> Developer, PMC Chair - Apache Maven
> (http://maven.apache.org)
> >>>>> Blog: http://www.johnofalltrades.name/
> >>>>>
> >>>>>
> >>>>
> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>
> >>>>>
> >>>>
> >>>>
> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>
> >>>>
> >>>
> >>>
> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>
> >>
> >> --
> >> John Casey
> >> Developer, PMC Chair - Apache Maven (http://maven.apache.org)
> >> Blog: http://www.johnofalltrades.name/
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
Posted by Stephen Connolly <st...@gmail.com>.
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" <bi...@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 <jd...@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 Margulies<bi...@gmail.com> wrote:
>>>
>>>> From: Benson Margulies<bi...@gmail.com>
>>>> Subject: Re: [DISCUSS] SCM child-project URL composition
>>>> To: "Maven Developers List"<de...@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<jd...@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
>>>> Struberg<st...@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<br...@infinity.nu>
>>>> wrote:
>>>>>>>
>>>>>>>> From: Brian Fox<br...@infinity.nu>
>>>>>>>> Subject: Re: [DISCUSS] SCM child-project
>>>> URL composition
>>>>>>>> To: "Maven Developers List"<de...@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<st...@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>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>
<developerConnection>staticscm: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<br...@infinity.nu>
>>>>>>>>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> From: Brian Fox<br...@infinity.nu>
>>>>>>>>>> Subject: Re: [DISCUSS] SCM
>>>> child-project URL
>>>>>>>>
>>>>>>>> composition
>>>>>>>>>>
>>>>>>>>>> To: "Maven Developers List"<de...@maven.apache.org>
>>>>>>>>>> Date: Thursday, July 28, 2011,
>>>> 7:23 PM
>>>>>>>>>> On Thu, Jul 28, 2011 at 2:59 PM,
>>>> John
>>>>>>>>>> Casey<jd...@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-unsubscribe@maven.apache.org
>>>>>>>>>>>> For additional commands,
>>>> e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> John Casey
>>>>>>>>>>> Developer, PMC Chair - Apache
>>>> Maven (http://maven.apache.org)
>>>>>>>>>>> Blog: http://www.johnofalltrades.name/
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>> For additional commands,
>>>> e-mail: dev-help@maven.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>> For additional commands, e-mail:
>>>> dev-help@maven.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>
>>>>> --
>>>>> John Casey
>>>>> Developer, PMC Chair - Apache Maven (http://maven.apache.org)
>>>>> Blog: http://www.johnofalltrades.name/
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> --
>> John Casey
>> Developer, PMC Chair - Apache Maven (http://maven.apache.org)
>> Blog: http://www.johnofalltrades.name/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Re: [DISCUSS] SCM child-project URL composition
Posted by Benson Margulies <bi...@gmail.com>.
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 <jd...@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 Margulies<bi...@gmail.com> wrote:
>>
>>> From: Benson Margulies<bi...@gmail.com>
>>> Subject: Re: [DISCUSS] SCM child-project URL composition
>>> To: "Maven Developers List"<de...@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<jd...@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
>>> Struberg<st...@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<br...@infinity.nu>
>>> wrote:
>>>>>>
>>>>>>> From: Brian Fox<br...@infinity.nu>
>>>>>>> Subject: Re: [DISCUSS] SCM child-project
>>> URL composition
>>>>>>> To: "Maven Developers List"<de...@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<st...@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>
>>>>>>>>
>>>>>>>
>>>>>>>
>>> <developerConnection>staticscm: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<br...@infinity.nu>
>>>>>>>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> From: Brian Fox<br...@infinity.nu>
>>>>>>>>> Subject: Re: [DISCUSS] SCM
>>> child-project URL
>>>>>>>
>>>>>>> composition
>>>>>>>>>
>>>>>>>>> To: "Maven Developers List"<de...@maven.apache.org>
>>>>>>>>> Date: Thursday, July 28, 2011,
>>> 7:23 PM
>>>>>>>>> On Thu, Jul 28, 2011 at 2:59 PM,
>>> John
>>>>>>>>> Casey<jd...@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-unsubscribe@maven.apache.org
>>>>>>>>>>> For additional commands,
>>> e-mail: dev-help@maven.apache.org
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> John Casey
>>>>>>>>>> Developer, PMC Chair - Apache
>>> Maven (http://maven.apache.org)
>>>>>>>>>> Blog: http://www.johnofalltrades.name/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>> For additional commands,
>>> e-mail: dev-help@maven.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail:
>>> dev-help@maven.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>> --
>>>> John Casey
>>>> Developer, PMC Chair - Apache Maven (http://maven.apache.org)
>>>> Blog: http://www.johnofalltrades.name/
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> --
> John Casey
> Developer, PMC Chair - Apache Maven (http://maven.apache.org)
> Blog: http://www.johnofalltrades.name/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
Posted by John Casey <jd...@commonjava.org>.
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 Margulies<bi...@gmail.com> wrote:
>
>> From: Benson Margulies<bi...@gmail.com>
>> Subject: Re: [DISCUSS] SCM child-project URL composition
>> To: "Maven Developers List"<de...@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<jd...@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
>> Struberg<st...@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<br...@infinity.nu>
>> wrote:
>>>>>
>>>>>> From: Brian Fox<br...@infinity.nu>
>>>>>> Subject: Re: [DISCUSS] SCM child-project
>> URL composition
>>>>>> To: "Maven Developers List"<de...@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<st...@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>
>>>>>>>
>>>>>>
>>>>>>
>> <developerConnection>staticscm: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<br...@infinity.nu>
>>>>>>
>>>>>> wrote:
>>>>>>>
>>>>>>>> From: Brian Fox<br...@infinity.nu>
>>>>>>>> Subject: Re: [DISCUSS] SCM
>> child-project URL
>>>>>>
>>>>>> composition
>>>>>>>>
>>>>>>>> To: "Maven Developers List"<de...@maven.apache.org>
>>>>>>>> Date: Thursday, July 28, 2011,
>> 7:23 PM
>>>>>>>> On Thu, Jul 28, 2011 at 2:59 PM,
>> John
>>>>>>>> Casey<jd...@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-unsubscribe@maven.apache.org
>>>>>>>>>> For additional commands,
>> e-mail: dev-help@maven.apache.org
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> John Casey
>>>>>>>>> Developer, PMC Chair - Apache
>> Maven (http://maven.apache.org)
>>>>>>>>> Blog: http://www.johnofalltrades.name/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands,
>> e-mail: dev-help@maven.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail:
>> dev-help@maven.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>
>>>>
>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> --
>>> John Casey
>>> Developer, PMC Chair - Apache Maven (http://maven.apache.org)
>>> Blog: http://www.johnofalltrades.name/
>>>
>>>
>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
John Casey
Developer, PMC Chair - Apache Maven (http://maven.apache.org)
Blog: http://www.johnofalltrades.name/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
Posted by Mark Struberg <st...@yahoo.de>.
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 <bi...@gmail.com> wrote:
> From: Benson Margulies <bi...@gmail.com>
> Subject: Re: [DISCUSS] SCM child-project URL composition
> To: "Maven Developers List" <de...@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 <jd...@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
> Struberg<st...@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<br...@infinity.nu>
> wrote:
> >>>
> >>>> From: Brian Fox<br...@infinity.nu>
> >>>> Subject: Re: [DISCUSS] SCM child-project
> URL composition
> >>>> To: "Maven Developers List"<de...@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<st...@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>
> >>>>>
> >>>>
> >>>>
> <developerConnection>staticscm: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<br...@infinity.nu>
> >>>>
> >>>> wrote:
> >>>>>
> >>>>>> From: Brian Fox<br...@infinity.nu>
> >>>>>> Subject: Re: [DISCUSS] SCM
> child-project URL
> >>>>
> >>>> composition
> >>>>>>
> >>>>>> To: "Maven Developers List"<de...@maven.apache.org>
> >>>>>> Date: Thursday, July 28, 2011,
> 7:23 PM
> >>>>>> On Thu, Jul 28, 2011 at 2:59 PM,
> John
> >>>>>> Casey<jd...@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-unsubscribe@maven.apache.org
> >>>>>>>> For additional commands,
> e-mail: dev-help@maven.apache.org
> >>>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> John Casey
> >>>>>>> Developer, PMC Chair - Apache
> Maven (http://maven.apache.org)
> >>>>>>> Blog: http://www.johnofalltrades.name/
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> ---------------------------------------------------------------------
> >>>>>>>
> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>> For additional commands,
> e-mail: dev-help@maven.apache.org
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>
> ---------------------------------------------------------------------
> >>>>>>
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>> For additional commands, e-mail:
> dev-help@maven.apache.org
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> ---------------------------------------------------------------------
> >>>>>
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>
> >>>>>
> >>>>
> >>>>
> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>
> >>>>
> >>>
> >>>
> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>
> >>>
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >
> > --
> > John Casey
> > Developer, PMC Chair - Apache Maven (http://maven.apache.org)
> > Blog: http://www.johnofalltrades.name/
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
Posted by Benson Margulies <bi...@gmail.com>.
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 <jd...@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 Struberg<st...@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<br...@infinity.nu> wrote:
>>>
>>>> From: Brian Fox<br...@infinity.nu>
>>>> Subject: Re: [DISCUSS] SCM child-project URL composition
>>>> To: "Maven Developers List"<de...@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<st...@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>
>>>>>
>>>>
>>>> <developerConnection>staticscm: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<br...@infinity.nu>
>>>>
>>>> wrote:
>>>>>
>>>>>> From: Brian Fox<br...@infinity.nu>
>>>>>> Subject: Re: [DISCUSS] SCM child-project URL
>>>>
>>>> composition
>>>>>>
>>>>>> To: "Maven Developers List"<de...@maven.apache.org>
>>>>>> Date: Thursday, July 28, 2011, 7:23 PM
>>>>>> On Thu, Jul 28, 2011 at 2:59 PM, John
>>>>>> Casey<jd...@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-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> John Casey
>>>>>>> Developer, PMC Chair - Apache Maven (http://maven.apache.org)
>>>>>>> Blog: http://www.johnofalltrades.name/
>>>>>>>
>>>>>>>
>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>>>
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> --
> John Casey
> Developer, PMC Chair - Apache Maven (http://maven.apache.org)
> Blog: http://www.johnofalltrades.name/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
Posted by John Casey <jd...@commonjava.org>.
using scm2: you're not able to apply the solution to website urls, etc.
which have a similar inheritance/calculation problem...
On 7/28/11 5:45 PM, Benson Margulies wrote:
> Is static: really superior to scm2: and then more colons allowing
> arbitrary keyword-value pairs?
>
> On Thu, Jul 28, 2011 at 5:44 PM, Mark Struberg<st...@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<br...@infinity.nu> wrote:
>>
>>> From: Brian Fox<br...@infinity.nu>
>>> Subject: Re: [DISCUSS] SCM child-project URL composition
>>> To: "Maven Developers List"<de...@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<st...@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>
>>>>
>>> <developerConnection>staticscm: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<br...@infinity.nu>
>>> wrote:
>>>>
>>>>> From: Brian Fox<br...@infinity.nu>
>>>>> Subject: Re: [DISCUSS] SCM child-project URL
>>> composition
>>>>> To: "Maven Developers List"<de...@maven.apache.org>
>>>>> Date: Thursday, July 28, 2011, 7:23 PM
>>>>> On Thu, Jul 28, 2011 at 2:59 PM, John
>>>>> Casey<jd...@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-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> John Casey
>>>>>> Developer, PMC Chair - Apache Maven (http://maven.apache.org)
>>>>>> Blog: http://www.johnofalltrades.name/
>>>>>>
>>>>>>
>>>>>
>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
John Casey
Developer, PMC Chair - Apache Maven (http://maven.apache.org)
Blog: http://www.johnofalltrades.name/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
Posted by Mark Struberg <st...@yahoo.de>.
yup something like
<developerConnection>static:scm:git:https://...
And the trailing / is rather unhandy. Some scms just crash if you don't use the correct trailing ;)
LieGrue,
strub
--- On Thu, 7/28/11, Benson Margulies <bi...@gmail.com> wrote:
> From: Benson Margulies <bi...@gmail.com>
> Subject: Re: [DISCUSS] SCM child-project URL composition
> To: "Maven Developers List" <de...@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 <st...@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 <br...@infinity.nu>
> wrote:
> >
> >> From: Brian Fox <br...@infinity.nu>
> >> Subject: Re: [DISCUSS] SCM child-project URL
> composition
> >> To: "Maven Developers List" <de...@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
> <st...@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>
> >> >
> >>
> <developerConnection>staticscm: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 <br...@infinity.nu>
> >> wrote:
> >> >
> >> >> From: Brian Fox <br...@infinity.nu>
> >> >> Subject: Re: [DISCUSS] SCM child-project
> URL
> >> composition
> >> >> To: "Maven Developers List" <de...@maven.apache.org>
> >> >> Date: Thursday, July 28, 2011, 7:23 PM
> >> >> On Thu, Jul 28, 2011 at 2:59 PM, John
> >> >> Casey <jd...@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-unsubscribe@maven.apache.org
> >> >> >> For additional commands, e-mail:
> dev-help@maven.apache.org
> >> >> >>
> >> >> >
> >> >> > --
> >> >> > John Casey
> >> >> > Developer, PMC Chair - Apache Maven
> (http://maven.apache.org)
> >> >> > Blog: http://www.johnofalltrades.name/
> >> >> >
> >> >> >
> >> >>
> >>
> ---------------------------------------------------------------------
> >> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> > For additional commands, e-mail: dev-help@maven.apache.org
> >> >> >
> >> >> >
> >> >>
> >> >>
> >>
> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> For additional commands, e-mail: dev-help@maven.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >>
> ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> > For additional commands, e-mail: dev-help@maven.apache.org
> >> >
> >> >
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
Posted by Benson Margulies <bi...@gmail.com>.
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 <st...@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 <br...@infinity.nu> wrote:
>
>> From: Brian Fox <br...@infinity.nu>
>> Subject: Re: [DISCUSS] SCM child-project URL composition
>> To: "Maven Developers List" <de...@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 <st...@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>
>> >
>> <developerConnection>staticscm: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 <br...@infinity.nu>
>> wrote:
>> >
>> >> From: Brian Fox <br...@infinity.nu>
>> >> Subject: Re: [DISCUSS] SCM child-project URL
>> composition
>> >> To: "Maven Developers List" <de...@maven.apache.org>
>> >> Date: Thursday, July 28, 2011, 7:23 PM
>> >> On Thu, Jul 28, 2011 at 2:59 PM, John
>> >> Casey <jd...@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-unsubscribe@maven.apache.org
>> >> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >> >>
>> >> >
>> >> > --
>> >> > John Casey
>> >> > Developer, PMC Chair - Apache Maven (http://maven.apache.org)
>> >> > Blog: http://www.johnofalltrades.name/
>> >> >
>> >> >
>> >>
>> ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> > For additional commands, e-mail: dev-help@maven.apache.org
>> >> >
>> >> >
>> >>
>> >>
>> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >>
>> >>
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
Posted by Brian Fox <br...@infinity.nu>.
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 <jd...@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 Fox<br...@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<st...@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>
>>>>
>>>> <developerConnection>staticscm: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<br...@infinity.nu> wrote:
>>>>
>>>>> From: Brian Fox<br...@infinity.nu>
>>>>> Subject: Re: [DISCUSS] SCM child-project URL composition
>>>>> To: "Maven Developers List"<de...@maven.apache.org>
>>>>> Date: Thursday, July 28, 2011, 7:23 PM
>>>>> On Thu, Jul 28, 2011 at 2:59 PM, John
>>>>> Casey<jd...@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-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> John Casey
>>>>>> Developer, PMC Chair - Apache Maven (http://maven.apache.org)
>>>>>> Blog: http://www.johnofalltrades.name/
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> --
> John Casey
> Developer, PMC Chair - Apache Maven (http://maven.apache.org)
> Blog: http://www.johnofalltrades.name/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
Posted by John Casey <jd...@commonjava.org>.
On 7/28/11 5:43 PM, Benson Margulies wrote:
> I keep thinking that I read about a convention that used the presence
> or absence of a trailing '/' on the URL to control this. Does anyone
> else recall this?
You mean overloading an explicit URL referencing a directory? Seems a
tad confusing and maybe even a problem waiting to happen...
>
> On Thu, Jul 28, 2011 at 5:32 PM, Brian Fox<br...@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<st...@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>
>>> <developerConnection>staticscm: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<br...@infinity.nu> wrote:
>>>
>>>> From: Brian Fox<br...@infinity.nu>
>>>> Subject: Re: [DISCUSS] SCM child-project URL composition
>>>> To: "Maven Developers List"<de...@maven.apache.org>
>>>> Date: Thursday, July 28, 2011, 7:23 PM
>>>> On Thu, Jul 28, 2011 at 2:59 PM, John
>>>> Casey<jd...@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-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>
>>>>> --
>>>>> John Casey
>>>>> Developer, PMC Chair - Apache Maven (http://maven.apache.org)
>>>>> Blog: http://www.johnofalltrades.name/
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
John Casey
Developer, PMC Chair - Apache Maven (http://maven.apache.org)
Blog: http://www.johnofalltrades.name/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
Posted by Benson Margulies <bi...@gmail.com>.
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 <br...@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 <st...@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>
>> <developerConnection>staticscm: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 <br...@infinity.nu> wrote:
>>
>>> From: Brian Fox <br...@infinity.nu>
>>> Subject: Re: [DISCUSS] SCM child-project URL composition
>>> To: "Maven Developers List" <de...@maven.apache.org>
>>> Date: Thursday, July 28, 2011, 7:23 PM
>>> On Thu, Jul 28, 2011 at 2:59 PM, John
>>> Casey <jd...@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-unsubscribe@maven.apache.org
>>> >> For additional commands, e-mail: dev-help@maven.apache.org
>>> >>
>>> >
>>> > --
>>> > John Casey
>>> > Developer, PMC Chair - Apache Maven (http://maven.apache.org)
>>> > Blog: http://www.johnofalltrades.name/
>>> >
>>> >
>>> ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> > For additional commands, e-mail: dev-help@maven.apache.org
>>> >
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
Posted by Mark Struberg <st...@yahoo.de>.
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 <br...@infinity.nu> wrote:
> From: Brian Fox <br...@infinity.nu>
> Subject: Re: [DISCUSS] SCM child-project URL composition
> To: "Maven Developers List" <de...@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 <st...@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>
> >
> <developerConnection>staticscm: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 <br...@infinity.nu>
> wrote:
> >
> >> From: Brian Fox <br...@infinity.nu>
> >> Subject: Re: [DISCUSS] SCM child-project URL
> composition
> >> To: "Maven Developers List" <de...@maven.apache.org>
> >> Date: Thursday, July 28, 2011, 7:23 PM
> >> On Thu, Jul 28, 2011 at 2:59 PM, John
> >> Casey <jd...@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-unsubscribe@maven.apache.org
> >> >> For additional commands, e-mail: dev-help@maven.apache.org
> >> >>
> >> >
> >> > --
> >> > John Casey
> >> > Developer, PMC Chair - Apache Maven (http://maven.apache.org)
> >> > Blog: http://www.johnofalltrades.name/
> >> >
> >> >
> >>
> ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> > For additional commands, e-mail: dev-help@maven.apache.org
> >> >
> >> >
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
Posted by Brian Fox <br...@infinity.nu>.
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 <st...@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>
> <developerConnection>staticscm: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 <br...@infinity.nu> wrote:
>
>> From: Brian Fox <br...@infinity.nu>
>> Subject: Re: [DISCUSS] SCM child-project URL composition
>> To: "Maven Developers List" <de...@maven.apache.org>
>> Date: Thursday, July 28, 2011, 7:23 PM
>> On Thu, Jul 28, 2011 at 2:59 PM, John
>> Casey <jd...@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-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >>
>> >
>> > --
>> > John Casey
>> > Developer, PMC Chair - Apache Maven (http://maven.apache.org)
>> > Blog: http://www.johnofalltrades.name/
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
Posted by John Casey <jd...@commonjava.org>.
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>
> <developerConnection>staticscm: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 Fox<br...@infinity.nu> wrote:
>
>> From: Brian Fox<br...@infinity.nu>
>> Subject: Re: [DISCUSS] SCM child-project URL composition
>> To: "Maven Developers List"<de...@maven.apache.org>
>> Date: Thursday, July 28, 2011, 7:23 PM
>> On Thu, Jul 28, 2011 at 2:59 PM, John
>> Casey<jd...@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-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> --
>>> John Casey
>>> Developer, PMC Chair - Apache Maven (http://maven.apache.org)
>>> Blog: http://www.johnofalltrades.name/
>>>
>>>
>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
John Casey
Developer, PMC Chair - Apache Maven (http://maven.apache.org)
Blog: http://www.johnofalltrades.name/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
Posted by Mark Struberg <st...@yahoo.de>.
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>
<developerConnection>staticscm: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 <br...@infinity.nu> wrote:
> From: Brian Fox <br...@infinity.nu>
> Subject: Re: [DISCUSS] SCM child-project URL composition
> To: "Maven Developers List" <de...@maven.apache.org>
> Date: Thursday, July 28, 2011, 7:23 PM
> On Thu, Jul 28, 2011 at 2:59 PM, John
> Casey <jd...@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-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >
> > --
> > John Casey
> > Developer, PMC Chair - Apache Maven (http://maven.apache.org)
> > Blog: http://www.johnofalltrades.name/
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
Posted by Brian Fox <br...@infinity.nu>.
On Thu, Jul 28, 2011 at 2:59 PM, John Casey <jd...@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> --
> John Casey
> Developer, PMC Chair - Apache Maven (http://maven.apache.org)
> Blog: http://www.johnofalltrades.name/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
Posted by John Casey <jd...@commonjava.org>.
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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
John Casey
Developer, PMC Chair - Apache Maven (http://maven.apache.org)
Blog: http://www.johnofalltrades.name/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] SCM child-project URL composition
Posted by Andreas Sewe <se...@st.informatik.tu-darmstadt.de>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org