From: Stephen Connolly<stephen.alan.conno...@gmail.com>
Subject: Re: [DISCUSS] SCM child-project URL composition
To: "Maven Developers List"<dev@maven.apache.org>
Date: Thursday, July 28, 2011, 10:47 PM
i think modelleo allows any random
attributes (as other pays them no heed...
not sure of ivy, and the others... but they are likely only
looking at
dependencies... a garden problem alright)
- Stephen
---
Sent from my Android phone, so random spelling mistakes,
random nonsense
words and other nonsense are a direct result of using swype
to type on the
screen
On 28 Jul 2011 23:38, "Benson Margulies"<bimargul...@gmail.com>
wrote:
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
