Hi,
thanks a lot for the answers. And sorry for the delay, I was actually busy
with releases! that's how this post question got to mind.
In my case, it's a parent-pom only, no module included. We use aggregator
only to refactor dependencies, so that we can open the module and all it's
dependants.
We deploy everything with release:prepare release:perform.
If I get you correctly Stephen, the child module's artifactId is actually
replaced in the scm url, and not appended.
in this case, it's probably not useful to append ${artifactId} at the end of
my <scm> url, isn't it?
<scm>
<connection>scm:svn:${svn.root}/trunk/${artifactId}</connection>
<developerConnection>scm:svn:${svn.root}/trunk/${artifactId}</developerConnection>
<url>${svn.root}/trunk/${artifactId}</url>
</scm>
the last / part after trunk shouldn't be useful.
I'm actually using variables so that the scm url keeps flexible in case we
change anything with the versioning system, and so that it's valid for every
child project.
But if it's get solidified at deployment time, it means that all my release
of the parent-pom get a solidified <scm>.
How can this parent-pom with a solidified <scm> -
scm:svn:svn://company/trunk/company-parent - be valid for deployment of
child projects???
That's a lot of magic going here obviously!
In any case, even if I don't need the ${artifactId} in the scm url, I'd be
happy to keep the ${scm.root} flexibility.
How can I keep this if the url gets solidified and commited at each
deployment?? (I know this answer: by hand :) )
But it seems http://jira.codehaus.org/browse/MRELEASE-128 is still not
clsed, so I'm proabably not the only one asking for it!
cheers
-jean
Stephen Connolly-2 wrote:
>
> you have to be clear about what I will call as "release roots"
>
> A release root is a project that has an <scm> section.
>
> It will typically be an aggregator project (i.e. packaging=pom &&
> modules.size()>0) but it does not need to be.
>
> If it is a parent project (i.e. at least one of the modules it
> aggregates references it as a parent.... you do know that aggregation
> does not have to follow inheritance by the way) then the scm
> information is transformed when being inherited, so that the child
> module's artifactId is appended to the scm url.
>
> in general, you should run "mvn release:prepare release:perform" from
> a "release root", it will generate one tag of everything that is
> contained below the "release root".
>
> in this case, you should always ensure that your modules definitions
> do not jump back up (e.g. you don't have
> <modules>../someother</modules>) as that would break the tagging for
> you. If you have to 'jump back up' then you probably need to set the
> configuration parameter "commitByProject=true" on the release plugin
> and you should explicitly set the scm information on the 'jump back
> up' modules.
>
> the scm information has to be solidified at deployment time, so what
> happens is that the ${project.artifactId} gets replaced with the
> actual artifactId in the scm information... there are a number of bugs
> in earlier versions of maven where this information was not getting
> solidified.
>
> Additionally there might be some magic about when the scm url ends
> with a / or not which might control whether or not the inheriting
> module gets it's artifactId appended to the inherited scm url
>
> -Stephen
>
> 2009/12/3 nodje <nodje...@gmail.com>:
>>
>> Hi,
>>
>> I'm using maven-release-plugin 2.0-beta9 and I'm still getting <scm> urls
>> rewritten at each deployment.
>>
>> http://jira.codehaus.org/browse/MRELEASE-231 is been closed quite a while
>> ago, so many we're not speaking about the same rewriting.
>>
>> The way we use the <SCM> tag in our organization is trough a parent pom
>> that
>> is suppose to set the <SCM> for each every child project.
>>
>> It looks like this:
>> <scm>
>> <connection>scm:svn:${svn.root}/trunk/${artifactId}</connection>
>>
>> <developerConnection>scm:svn:${svn.root}/trunk/${artifactId}</developerConnection>
>> <url>${svn.root}/trunk/${artifactId}</url>
>> </scm>
>>
>> What I'm not getting is that while it's the only <SCM> tag in the whole
>> maven configuration, it gets rewritten at parent-pom deployment time WITH
>> parent-pom properties.
>>
>> Even though, when releasing a child project based on this parent release,
>> Release plugin seems to find it's way to our Subversion without any other
>> help.
>>
>> I really don't understand how this can possibly work.
>> Could somebody enlighten me on this?
>>
>> rgds
>> -jean
>> --
>> View this message in context:
>> http://old.nabble.com/-Release--%3Cscm%3E-getting-rewritten.-how-does-it-work--tp26621596p26621596.html
>> Sent from the Maven - Users mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
>
--
View this message in context:
http://old.nabble.com/-Release--%3Cscm%3E-getting-rewritten.-how-does-it-work--tp26621596p26773898.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
