8

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?

peterh
  • 11,875
  • 18
  • 85
  • 108
conteit86
  • 320
  • 3
  • 16

3 Answers3

14

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.

Adrian Shum
  • 38,812
  • 10
  • 83
  • 131
A_Di-Matteo
  • 26,902
  • 7
  • 94
  • 128
  • Based on this fantastic response: https://plus.google.com/112346331375070267873/posts/AntD8wE1F3b?hl=es – albfan Nov 03 '17 at 19:01
0

I would suggest you another solution.

Why don't you set version in profile instead of make decision about profile activation on version? Like here:

<version>${projectVersion}</version>

<profiles>
    <profile>
        <id>snapshot</id>
        <activation>
            <activeByDefault>true</activeByDefault>
        </activation>
        <properties>
            <projectVersion>1.0-SNAPSHOT</projectVersion>
        </properties>
    </profile>
    <profile>
        <id>release</id>
        <properties>
            <projectVersion>1.0-RELEASE</projectVersion>
        </properties>
    </profile>
</profiles>
Konstantin Konyshev
  • 1,026
  • 9
  • 18
  • 1
    The idea gitflow-helper-maven-plugin is to use a single job in CI server (that triggers mvn clean deploy) in order to build the project. According to the branch that is compiling the artifacts get deployed to snapshots, stage or releases repositories. Version is managed by using versions:set goal when creating a new branch. – conteit86 Aug 25 '16 at 07:21
  • In this scenario I'm not able to activate specific profiles so I cannot use your solution. – conteit86 Aug 25 '16 at 07:21
0

https://www.mojohaus.org/versions-maven-plugin/examples/use-releases.html

use goal mvn versions:use-releases

Ashish
  • 14,295
  • 21
  • 82
  • 127