Properties lost during Maven release:perform

Question

I'm running maven builds from TeamCity and making use of build.vcs.number to write the Subversion revision into my manifest. In any Maven build with Subversion as the VCS, TeamCity adds

-Dbuild.vcs.number=1234

to the maven command line, where 1234 is the latest revision in the branch being built.

Then in my pom.xml, I have

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-jar-plugin</artifactId>
    <configuration>
        <archive>
            <manifest>
                <addDefaultSpecificationEntries>true</addDefaultSpecificationEntries>
                <addDefaultImplementationEntries>true</addDefaultImplementationEntries>
            </manifest>
            <manifestEntries>
                <build>${build.vcs.number}</build>
            </manifestEntries>
        </archive>
    </configuration>
</plugin>

This all works fine until I run Maven release:perform (also from TeamCity), at which point ${build.vcs.number} becomes null, even though I can see in the TeamCity build log that this property was passed in at the command line.

The maven-release-plugin documentation implies that Maven runs a forked process at some point during the perform goal - is this why I have the problem?

Is there a way I can ensure this particular property gets passed through to that forked process?

East

Answer 1

-Darguments=-Dbuild.vcs.number=1234

There is a forked process for release to ensure it has a clean reproducible command line, therefore you need to specify what to pass through.

Ideally you configure the release plugin on your Pom to pass the property through, but failing that use the override (unless somebody has disabled the override in your Pom... Them you're stuck until you re-enable it.

Note: pay close attention to quoting if there are multiple properties or properties with spaces in them

Bookseller

Ah brilliant, exactly what I was looking for. – East