You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by nodje <no...@gmail.com> on 2009/12/03 07:27:09 UTC
[Release] getting rewritten. how does it work?
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
Re: [Release] getting rewritten. how does it work?
Posted by nodje <no...@gmail.com>.
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 <no...@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
>
>
>
--
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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [Release] getting rewritten. how does it work?
Posted by Stephen Connolly <st...@gmail.com>.
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 <no...@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
Re: [Release] getting rewritten. how does it work?
Posted by Anders Hammar <an...@hammar.net>.
I'm guessing that when you do the release of the child module, a
snapshot-version of the parent is actually being used as that's what your
child pom specifies. The snapshot-version is in your local repo (or a remote
repo) and still has all the properties in the scm url (it's just the
released version in your corp repo that has the properties substituted).
Thus, the effective-pom will have a scm url with the properties and when
substituting those with the child's values, the scm url is created correctly
(for the child project).
If this is the case, I would say that it is a kind of bug in the release
plugin as the resulting effective-pom (based on the release version parent
pom and the release version child pom) is not what was used when doing the
release. As you can tell from you're case there are some differences. In
your example it's for instance not possible to retrieve the code base based
on the scm url of the release child project (the scm url inherited from the
release version parent pom).
Regarding the proprties substitution in the parent pom people normally
complain that the properties are NOT substituted. And now you're complaining
they are...:-)
/Anders
On Thu, Dec 3, 2009 at 07:27, nodje <no...@gmail.com> wrote:
>
> 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
>
>