How to enable maven profile when built version is not -SNAPSHOT?

Question

I'm trying to use the gitflow-helper-maven-plugin extension for my maven builds.

Therefore I'd like to configure my project in order to run some extra steps when building a release version and skipping them while compiling a SNAPSHOT one, but I cannot find a way to enable a profile if ${project.version} contains -SNAPSHOT.

Any suggestion?

Answer 1

Below a possible approach which is how you could always simulate an if statement in a Maven build:

• Use the buid-helper-maven-plugin and its regex-property goal to parse the default ${project.version} property and create a new ${only.when.is.snapshot.used} property with value true or ${project.version} in case of SNAPSHOT suffix found.
• Configure the maven-source-plugin to execute its jar goal with a special configuration using its skipSource option and passing to it the new (dynamic) ${only.when.is.snapshot.used} property: in case of snapshot it will have value true hence skip the execution, otherwise will have value ${project.version} which will be used as false and hence not skip this execution
• Configure the same as above for the maven-javadoc-plugin using its skip option

A sample of the approach above would be:

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>build-helper-maven-plugin</artifactId>
    <version>1.10</version>
    <executions>
        <execution>
            <!-- sets the only.when.is.snapshot.used property to true if SNAPSHOT was used, 
                to the project version otherwise -->
            <id>build-helper-regex-is-snapshot-used</id>
            <phase>validate</phase>
            <goals>
                <goal>regex-property</goal>
            </goals>
            <configuration>
                <name>only.when.is.snapshot.used</name>
                <value>${project.version}</value>
                <regex>.*-SNAPSHOT</regex>
                <replacement>true</replacement>
                <failIfNoMatch>false</failIfNoMatch>
            </configuration>
        </execution>
    </executions>
</plugin>

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-source-plugin</artifactId>
    <version>3.0.1</version>
    <executions>
        <execution>
            <id>create-sources</id>
            <phase>package</phase>
            <goals>
                <goal>jar</goal>
            </goals>
            <configuration>
                <!-- skip when version is SNAPSHOT -->
                <skipSource>${only.when.is.snapshot.used}</skipSource>
            </configuration>
        </execution>
    </executions>
</plugin>
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-javadoc-plugin</artifactId>
    <version>2.10.4</version>
    <executions>
        <execution>
            <id>create-javadoc</id>
            <phase>package</phase>
            <goals>
                <goal>jar</goal>
            </goals>
            <configuration>
                <!-- skip when version is SNAPSHOT -->
                <skip>${only.when.is.snapshot.used}</skip>
            </configuration>
        </execution>
    </executions>
</plugin>

That is, no need for profiles, this configuration will only be enabled when a non SNAPSHOT version will be used, dynamically and without any further configuration (command line options or whatsoever).

---

As a side reminder, you could also look at the maven-release-plugin, which will effectively invoke the source and javadoc plugin only when performing a release without the added (minor) complexity of the approach above.

Otherwise, you could simple use the default profile coming from the Maven Super POM which would actually invoke the same, source and javadoc plugin, and can be activated via the property performRelease set to value true. That is, on any Maven project could you invoke the following:

mvn clean package -DperformRelease=true

or

mvn clean package -Prelease-profile

And you will automatically benefit from the default super profile and have sources and javadoc jars generated, although this approach should be used as last option since the profile could be dropped from the super pom in future releases.