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 <bimargul...@gmail.com> wrote:
> From: Benson Margulies <bimargul...@gmail.com>
> Subject: Re: [DISCUSS] SCM child-project URL composition
> To: "Maven Developers List" <dev@maven.apache.org>
> Date: Thursday, July 28, 2011, 9:45 PM
> Is static: really superior to scm2:
> and then more colons allowing
> arbitrary keyword-value pairs?
>
> On Thu, Jul 28, 2011 at 5:44 PM, Mark Struberg <strub...@yahoo.de>
> wrote:
> > Hi!
> >
> > A small update:
> >
> > Benjamin mentioned that this might also be useful for
> site URLs if a user like to define the effective URLs of the
> sub-module site via ${project.version}/${project.artifactId}
> or similar.
> >
> > So we just came up with "static:" as prefix.
> >
> > More soon via Jira.
> >
> > LieGrue,
> > strub
> >
> > --- On Thu, 7/28/11, Brian Fox <bri...@infinity.nu>
> wrote:
> >
> >> From: Brian Fox <bri...@infinity.nu>
> >> Subject: Re: [DISCUSS] SCM child-project URL
> composition
> >> To: "Maven Developers List" <dev@maven.apache.org>
> >> Date: Thursday, July 28, 2011, 9:32 PM
> >> not crazy about the syntax, but
> >> generally yes i think that makes sense.
> >>
> >> I've long maintained that we need something
> similar for
> >> properties to
> >> balance between "resolve at build time" and
> "resolve at
> >> fetch from
> >> repo" type of issues.
> >>
> >> On Thu, Jul 28, 2011 at 3:37 PM, Mark Struberg
> <strub...@yahoo.de>
> >> wrote:
> >> > Hi John, Brian
> >> >
> >> > Just to make sure I did understand that
> correctly:
> >> > you propose to use a special URL prefix to
> tell the
> >> maven DefaultProjectBuilder to treat those urls as
> static.
> >> An example:
> >> >
> >> >
> >> > <scm>
> >> >
> >>
> <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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
