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

Reply via email to