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 large multi-module project.  For now, I'm getting around
this by just using my own properties instead of the main scm fields.

On 07/14/2011 10:13 AM, Paul Gier wrote:
> 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.
> 
> On 07/14/2011 10:03 AM, John Casey wrote:
>> 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
>> information, if it's missing from a POM. That leaves a pretty tedious
>> state of affairs, though.
>>
>> On 7/14/11 10:57 AM, Paul Gier wrote:
>>> 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
>>> case where it is correct is when you have a bunch of small loosely
>>> connected projects (like Maven plugins) and you are using svn.
>>>
>>> For a multi-module project using git, this is really annoying because
>>> now I have to set the scm URL for each module separately if I want them
>>> to contain a working URL.  Am I missing some simple configuration?  Or
>>> should we fix this maybe in Maven 3.1 to just inherit the scm
>>> information unmodified instead of trying to be smart about adding module
>>> paths?
>>>
>>> ---------------------------------------------------------------------
>>> 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

Reply via email to