maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: [Release] <scm> getting rewritten. how does it work?
Date Thu, 03 Dec 2009 07:30:20 GMT
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.co@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Mime
View raw message