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
