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

Reply via email to