tags:

views:

56

answers:

1

I suppose this is kinda obvious, but I still judge it as a shortcoming...

I have 23 Mavenized projects. I'm now adding the <scm> bit because I've started using the release plugin. Here was my thought process:

  • I'll add the <scm> section only in my company base POM, and parameterise the URLs with properties, e.g.
<scm>
    <connection>${scmBaseConnection}/${scm.module}/${scm.edition}</connection>
    <developerConnection>${scmBaseConnection}/${scm.module}/${scm.edition}</developerConnection>
    <url>${fisheyeBaseUrl}/${scm.module}</url>
</scm>
  • Then each project root (aggregator) POM need only declare its scm. <properties> accordingly (and not have to re-declare the whole <scm> section), e.g.:
   <scm.module>sharktopus</scm.module>
   <scm.edition>trunk</scm.edition>

But I soon realised that I can't do that: the release plugin rewrites each POM with the tag and next versions of the SCM info, so each such POM needs its own <scm> section.

Fine, so I decided I'll store the common SCM details in base POM properties, and have each project root POM declare its <scm> section using those props, plus its own specifics e.g.:

<scm>
    <connection>${scmBaseConnection}/sharktopus/trunk</connection>
    <developerConnection>${scmBaseConnection}/sharktopus/trunk</developerConnection>
    <url>${fisheyeBaseUrl}/sharktopus</url>
</scm>

But that doesn't work either, because the release plugin rewrites using the resolved values (which is kinda obvious, in hindsight). So, e.g. for the release tag POM, the info above would be rewritten as:

<scm>
    <connection>scm:svn:https://mysvnhost.net/sharktopus/tags/R1_NewStuff&lt;/connection&gt;
    <developerConnection>scm:svn:https://mysvnhost.net/sharktopus/tags/R1_NewStuff&lt;/developerConnection&gt;
    <url>https://mysvnhost.net/sharktopus&lt;/url&gt;
</scm>

This means that each POM must have its own <scm> section with hardcoded URLs.

  • Is this what everyone does?
  • What happens if your SCM URL(s) change - do you just search/replace across all your projects?
  • Could it be a feature request to the release plugin to rewrite partial URLs, e.g. to keep the property references, but overwrite the 'final' specifics?
+1  A: 

The only place to define scm part is in the project root not company root. In a multimodule build it's needed to have only a single scm part. The reason that the release plugin will replace the properties is very simple. After a release these pom's must represent that state for that software. If they would have properties in it would be imposible to gurantee the corret values etc. So the result would not reproducible... If the SCM URL changes it will be valid only for new projects and not for the old ones, cause they are already been deployed etc.

khmarbaise
Hm, yes, I suppose you're right...
Cornel Masson