> From: Benson Margulies
> Subject: Re: SCM info and modules
> To: "Maven Developers List"
> Date: Saturday, July 16, 2011, 11:31 PM
> Mark,
>
> Oh, drat, I see, to pick a provider, we have to have
> finished
> processing extensions and all that other go
then, so not sure if things have changed in
> mvn-3...
>
> LieGrue,
> strub
>
> --- On Sat, 7/16/11, Benson Margulies wrote:
>
>> From: Benson Margulies
>> Subject: Re: SCM info and modules
>> To: "Maven Developers List"
>> Date: Satur
ember from grabbing into this very problem 2 years
ago. That was maven-2 back then, so not sure if things have changed in mvn-3...
LieGrue,
strub
--- On Sat, 7/16/11, Benson Margulies wrote:
> From: Benson Margulies
> Subject: Re: SCM info and modules
> To: "Maven Developers List&quo
ot;->static,...
>
> This could be maintained in settings.xml and we deliver a default one in the
> global settings.xml. That way it would be predefined but maintainable by the
> user.
>
> LieGrue,
> strub
>
>
> --- On Fri, 7/15/11, Benson Margulies wrote:
>
>>
quot;->static, "scm:jgit"->static,...
This could be maintained in settings.xml and we deliver a default one in the
global settings.xml. That way it would be predefined but maintainable by the
user.
LieGrue,
strub
--- On Fri, 7/15/11, Benson Margulies wrote:
> From: Benson Marg
Let me suggest a generalization of Hervé's thought process.
I submit that there are four issues here we might be trying to
address. (1) users want to put an scm spec in an aggregating project
and not have to repeat it (with slight mods) in all the modules. (2)
users want to be able to toss a set o
Le vendredi 15 juillet 2011, John Casey a écrit :
> On 7/14/11 6:41 PM, Hervé BOUTEMY wrote:
> > we call it a URL, but it's a String in the POM [2]
> > Nothing prevents another way of interpreting this String: say properties
> > format?
> > If we want to transform this String to a DOM object in the
On 7/14/11 6:41 PM, Hervé BOUTEMY wrote:
we call it a URL, but it's a String in the POM [2]
Nothing prevents another way of interpreting this String: say properties
format?
If we want to transform this String to a DOM object in the POM, with specific
XML definition for each SCM, I only see the
we call it a URL, but it's a String in the POM [2]
Nothing prevents another way of interpreting this String: say properties
format?
If we want to transform this String to a DOM object in the POM, with specific
XML definition for each SCM, I only see the backward compatibility as a strong
problem
The thing that's problematic here is that we're getting fairly deep down
the rabbit hole on these sub-languages...it'd be so much better if we
had a way to support a proper format for Git SCM information, rather
than embedding all that information in a really complex pseudo-URL.
On 7/14/11 4:1
SCM url have mutiple parts when multiple parts mean something.
As you speak about git, [1] shows how tech and push urls can be different for
example
The algorithm to automatically derivate SCM url of a sub-module from parent
SCM should be provider dependendant, available from maven-scm-api.
And M
good point
On 7/14/11 11:49 AM, Andreas Sewe wrote:
Hi,
I'm not 100% sure it should be inherited at all. Inheriting unchanged is
only valid for something like Git, but probably never for SVN. However,
as you point out, Maven's current guess is usually not good enough
either.
the problem is r
My point is that if I pull down one of the AS module POMs from the
repository, and it has a SCM element, those locations should give me
enough information to checkout that module from SCM and build it.
On 7/14/11 11:20 AM, Paul Gier wrote:
Just to clarify, I see your point that inheriting fro
Hi,
I'm not 100% sure it should be inherited at all. Inheriting unchanged is
only valid for something like Git, but probably never for SVN. However,
as you point out, Maven's current guess is usually not good enough either.
the problem is really that Maven currently has only a single element f
Just to clarify, I see your point that inheriting from a generic parent
pom doesn't really make sense. However, in these cases I sort of have
the expectation that I will have to set it for each new project. The
part that bothers me is having to reset it to the same value for each
module of a larg
I think inheriting it unchanged is fine for most multi-module projects,
even using SVN. Thinking in terms of the JBoss AS build, releases
always happen from the root path of the project, and the URL I would
want to put into module jar manifests for example would also be the root
URL of the project
I'm not 100% sure it should be inherited at all. Inheriting unchanged is
only valid for something like Git, but probably never for SVN. However,
as you point out, Maven's current guess is usually not good enough either.
I'm not sure Maven can reliably fill in an intelligent value for SCM
infor
Hi Everyone,
The current behaviour of Maven for a multi-module project is that the
module path will automatically be appended to the end of the scm fields
(connection, url, etc). This has always seemed like a bug to me since
it not what you would want for a real multi-module project. The only
ca
18 matches
Mail list logo
