attributes are special in XML schema. I plan to check and see if pom
4.0 really precludes unqualified attributes.

On Jul 28, 2011, at 6:26 PM, John Casey <jdca...@commonjava.org> wrote:

>
>
> On 7/28/11 6:12 PM, Mark Struberg wrote:
>> Hi and txs 4 looking through the proposal!
>>
>> <url static="true">  is a neat idea but sadly requires us to change the 
>> pom-4.0 schema. So I fear this is a no-go atm.
>>
>> I'm not sure if there is lots of code which parses the content of the urls 
>> manually. It's not guaranteed what it contains, and we already apply _lots_ 
>> of magic to those URLs (property expansion, etc). So anyone which does not 
>> use our stuff is on his own anyway. Actually the content is still a valid 
>> URL in the sense of RFC-1738. But it's our own protocol now ;)
>>
>> Just my $0.02
>>
>> LieGrue,
>> strub
>>
>> PS: I really like the 'absolute:' protocol name Robert proposed (instead of 
>> 'static:'.
>
> +1
>
>>
>> --- On Thu, 7/28/11, Benson Margulies<bimargul...@gmail.com> wrote:
>>
>>> From: Benson Margulies<bimargul...@gmail.com>
>>> Subject: Re: [DISCUSS] SCM child-project URL composition
>>> To: "Maven Developers List"<dev@maven.apache.org>
>>> Date: Thursday, July 28, 2011, 10:01 PM
>>> As well I know from MSITE-600.
>>> However, now I'm confused: you
>>> couldn't use the static business with
>>> /project/distributionManagement/site/url, since those are
>>> naked urls.
>>> The proposal above is not scm:static:, it's static:scm:.
>>> are you
>>> suggesting putting static:http: in
>>> /project/distributionManagement/site/url? That looks
>>> like  a problem
>>> for anything that parses the pom and doesn't use the model
>>> code, and I
>>> thought we felt precluded from busting things like this.
>>>
>>> Yet Another Alternative:
>>>
>>>  <url static='true'>what-we-have-today</url>
>>>
>>> would work for scm and also for websites. In my opinion,
>>> the
>>> 'disconnected parent' issue has to be fully taken on board,
>>> and that
>>> really calls for
>>>
>>>   <url
>>> inherit='false'>what-we-have-today</url>
>>>
>>> which would be a good thing for the overall ASF pom.
>>>
>>>
>>> On Thu, Jul 28, 2011 at 5:50 PM, John Casey<jdca...@commonjava.org>
>>> wrote:
>>>> using scm2: you're not able to apply the solution to
>>> website urls, etc.
>>>> which have a similar inheritance/calculation
>>> problem...
>>>>
>>>> On 7/28/11 5:45 PM, Benson Margulies wrote:
>>>>>
>>>>> Is static: really superior to scm2: and then more
>>> colons allowing
>>>>> arbitrary keyword-value pairs?
>>>>>
>>>>> On Thu, Jul 28, 2011 at 5:44 PM, Mark
>>> Struberg<strub...@yahoo.de>
>>>  wrote:
>>>>>>
>>>>>> Hi!
>>>>>>
>>>>>> A small update:
>>>>>>
>>>>>> Benjamin mentioned that this might also be
>>> useful for site URLs if a user
>>>>>> like to define the effective URLs of the
>>> sub-module site via
>>>>>> ${project.version}/${project.artifactId} or
>>> similar.
>>>>>>
>>>>>> So we just came up with "static:" as prefix.
>>>>>>
>>>>>> More soon via Jira.
>>>>>>
>>>>>> LieGrue,
>>>>>> strub
>>>>>>
>>>>>> --- On Thu, 7/28/11, Brian Fox<bri...@infinity.nu>
>>>  wrote:
>>>>>>
>>>>>>> From: Brian Fox<bri...@infinity.nu>
>>>>>>> Subject: Re: [DISCUSS] SCM child-project
>>> URL composition
>>>>>>> To: "Maven Developers List"<dev@maven.apache.org>
>>>>>>> Date: Thursday, July 28, 2011, 9:32 PM
>>>>>>> not crazy about the syntax, but
>>>>>>> generally yes i think that makes sense.
>>>>>>>
>>>>>>> I've long maintained that we need
>>> something similar for
>>>>>>> properties to
>>>>>>> balance between "resolve at build time"
>>> and "resolve at
>>>>>>> fetch from
>>>>>>> repo" type of issues.
>>>>>>>
>>>>>>> On Thu, Jul 28, 2011 at 3:37 PM, Mark
>>> Struberg<strub...@yahoo.de>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi John, Brian
>>>>>>>>
>>>>>>>> Just to make sure I did understand
>>> that correctly:
>>>>>>>> you propose to use a special URL
>>> prefix to tell the
>>>>>>>
>>>>>>> maven DefaultProjectBuilder to treat those
>>> urls as static.
>>>>>>> An example:
>>>>>>>>
>>>>>>>>
>>>>>>>> <scm>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>  <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<bri...@infinity.nu>
>>>>>>>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> From: Brian Fox<bri...@infinity.nu>
>>>>>>>>> Subject: Re: [DISCUSS] SCM
>>> child-project URL
>>>>>>>
>>>>>>> composition
>>>>>>>>>
>>>>>>>>> To: "Maven Developers List"<dev@maven.apache.org>
>>>>>>>>> Date: Thursday, July 28, 2011,
>>> 7:23 PM
>>>>>>>>> On Thu, Jul 28, 2011 at 2:59 PM,
>>> John
>>>>>>>>> Casey<jdca...@commonjava.org>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Would it be better to have a
>>> syntax to mark a
>>>>>>>
>>>>>>> URL as
>>>>>>>>>
>>>>>>>>> literal, not to be
>>>>>>>>>>
>>>>>>>>>> calculated or used as the
>>> basis of
>>>>>>>
>>>>>>> calculation?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Yes. I tried to fix this behavior
>>> for urls back in
>>>>>>>
>>>>>>> ~2.0.6/7
>>>>>>>>>
>>>>>>>>> ish and it
>>>>>>>>> broke lots of stuff that depended
>>> upon that
>>>>>>>
>>>>>>> behavior.
>>>>>>>>>
>>>>>>>>>> That way, we don't have to
>>> worry about
>>>>>>>
>>>>>>> adjusting to
>>>>>>>>>
>>>>>>>>> new SCMs or other places
>>>>>>>>>>
>>>>>>>>>> where we want to use it...new
>>> SCMs could be
>>>>>>>
>>>>>>> added via
>>>>>>>>>
>>>>>>>>> build extension, IIRC,
>>>>>>>>>>
>>>>>>>>>> so this is particularly
>>> important there.
>>>>>>>>>>
>>>>>>>>>> WDYT?
>>>>>>>>>>
>>>>>>>>>> On 7/28/11 12:46 PM, Mark
>>> Struberg wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi!
>>>>>>>>>>>
>>>>>>>>>>> problem description
>>>>>>>>>>> -----------
>>>>>>>>>>>
>>>>>>>>>>> SCM URLs currently
>>> automatically get
>>>>>>>
>>>>>>> extended for
>>>>>>>>>
>>>>>>>>> child modules.
>>>>>>>>>>>
>>>>>>>>>>> E.g. from
>>>>>>>>>>>
>>> svn://mycompany.com/myproject
>>>>>>>>>>> in the parent pom, a child
>>> module
>>>>>>>
>>>>>>> 'frontend' will
>>>>>>>>>
>>>>>>>>> result in getting a SCM
>>>>>>>>>>>
>>>>>>>>>>> URL
>>>>>>>>>>>
>>> svn://mycompany.com/myproject/frontend
>>>>>>>>>>>
>>>>>>>>>>> This is fine for SVN and
>>> CVS, but broken
>>>>>>>
>>>>>>> for GIT,
>>>>>>>>>
>>>>>>>>> HG, etc because the SCM
>>>>>>>>>>>
>>>>>>>>>>> URL is 'static' for them.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> proposal
>>>>>>>>>>> -----------
>>>>>>>>>>>
>>>>>>>>>>> Since we cannot put this
>>> information into
>>>>>>>
>>>>>>> the
>>>>>>>>>
>>>>>>>>> various scm plugins (because
>>>>>>>>>>>
>>>>>>>>>>> of a 'definition cycle' as
>>> explained here
>>>>>>>
>>>>>>> [1]) we
>>>>>>>>>
>>>>>>>>> could split the URL
>>>>>>>>>>>
>>>>>>>>>>> construction into
>>>>>>>
>>>>>>> scmUrlAppendChild=true/false and
>>>>>>>>>
>>>>>>>>> make it configurable. The
>>>>>>>>>>>
>>>>>>>>>>> configuration could be
>>> controlled via a
>>>>>>>
>>>>>>> Modello
>>>>>>>>>
>>>>>>>>> config, my suggestion would
>>>>>>>>>>>
>>>>>>>>>>> be to just add them to
>>> toolchains.mdo.
>>>>>>>>>>> I'd just add a String
>>> property which
>>>>>>>
>>>>>>> holds a
>>>>>>>>>
>>>>>>>>> regular expression which
>>>>>>>>>>>
>>>>>>>>>>> parses the SCM URL and
>>> decides upon this
>>>>>>>
>>>>>>> whether
>>>>>>>>>
>>>>>>>>> the appending should get
>>>>>>>>>>>
>>>>>>>>>>> activated, e.g. for all
>>> SCMs which
>>>>>>>
>>>>>>> contain
>>>>>>>>>
>>>>>>>>> 'scm:svn:' or 'scm:cvs:' or the
>>>>>>>>>>>
>>>>>>>>>>> java-svn (olamy, you know
>>> the plexus key
>>>>>>>
>>>>>>> for
>>>>>>>>>
>>>>>>>>> that?)
>>>>>>>>>>>
>>>>>>>>>>> If there is a better place
>>> to put that
>>>>>>>
>>>>>>> config or a
>>>>>>>>>
>>>>>>>>> better way to get the
>>>>>>>>>>>
>>>>>>>>>>> info, then please speak up
>>> now :)
>>>>>>>>>>>
>>>>>>>>>>> I think this change would
>>> be backward
>>>>>>>
>>>>>>> compatible
>>>>>>>>>
>>>>>>>>> and doesn't need any pom
>>>>>>>>>>>
>>>>>>>>>>> changes. It also could
>>> easily get
>>>>>>>
>>>>>>> back-ported to
>>>>>>>>>
>>>>>>>>> mvn2 if needed.
>>>>>>>>>>>
>>>>>>>>>>> Are there other URLS which
>>> also need a
>>>>>>>
>>>>>>> similar
>>>>>>>>>
>>>>>>>>> distinction while building
>>>>>>>>>>>
>>>>>>>>>>> the model?
>>>>>>>>>>>
>>>>>>>>>>> WDYT?
>>>>>>>>>>>
>>>>>>>>>>> txs and LieGrue,
>>>>>>>>>>> strub
>>>>>>>>>>>
>>>>>>>>>>> [1] http://markmail.org/message/npw3hp6aloa55ctf
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>>>>>>>>>> For additional commands,
>>> e-mail: dev-h...@maven.apache.org
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> John Casey
>>>>>>>>>> Developer, PMC Chair - Apache
>>> Maven (http://maven.apache.org)
>>>>>>>>>> Blog: http://www.johnofalltrades.name/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>>>>>>>>> For additional commands,
>>> e-mail: dev-h...@maven.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>>>>>>>> For additional commands, e-mail:
>>> dev-h...@maven.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>>>
>>>>
>>>> --
>>>> John Casey
>>>> Developer, PMC Chair - Apache Maven (http://maven.apache.org)
>>>> Blog: http://www.johnofalltrades.name/
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>
> --
> John Casey
> Developer, PMC Chair - Apache Maven (http://maven.apache.org)
> Blog: http://www.johnofalltrades.name/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Reply via email to