views:

36

answers:

2

I have following pom.xml

<project>
  <properties>
    <buildNumber>dev</buildNumber>
  </properties>
  <build>
    <finalName>${project.artifactId}-${project.version}-${buildNumber}</finalName>
  </build>
</project>

This works fine on development machine. If I run mvn package I've got project-1.1-dev.war artifact. If I run mvn package -DbuildNumber=121 I've got package-1.1-121.war.

But out CI server (TeamCity) always got project-1.1-dev.war despite the fact that buildNumber property passed to maven (if I remove default property definition from pom.xml, maven builds artifact with correct filename).

It seems that system property resolve priority is somehow depends on platform (maven version is equals on both developer machine and TC - 2.2.1)?

+1  A: 

That's a bit strange... Maybe you can't force the parameter given in the command line to have a highest priority than the one defined in the <properties> tag.

An idea is to use a profile that define the property buildNumber:

<profiles>
    <profile>
        <id>dev-property</id>
        <activation>
            <activeByDefault>true</activeByDefault>
        </activation>
        <properties>
            <buildNumber>dev</buildNumber>
        </properties>
    </profile>
</profiles>

So by default, buildNumber will be equals to dev value. Now, in your TeamCity command line, disable this profile with the command mvn ... -P !dev-property (the ! before a profile id indicates that the profile must be disabled).

romaintaz
A: 
Jon Freedman
Not exactly. I need a way to distinguish any two build artifacts (when the are deployed in production). Using SNAPSHOT I can't do that. All build artifacts will have name `project-1.1-SNAPSHOT.war`
dotsid
If you have two separate versions you are going to deploy to production they should have different version numbers, the act of creating a release should consume a version. *SNAPSHOT* builds (or dev builds) should never be deployed. Are you saying that your build is different depending on which machine it was built on?
Jon Freedman
We have incremental development cycle, and change version in the POM descriptor after each change to source code is overkill for us. So we are using following scheme: developer define version of the artifact (based on change semantic: backward compatibility etc) and CI server use incrementing counter for marking artifacts. "dev" artifacts are not deployed to production.
dotsid
When you say overkill, do you mean that you don't want TeamCity to commit to version control when it does an incremental build? How does it manage its `buildNumber`? I think you could have TeamCity consume incremental builds and your developers continue to set major/minor revisions as they currently do. I can't see anything in the cycle you've described which breaks the separation provided by *SNAPSHOT*
Jon Freedman