2

I'm including a newVersion propery form an external file using:

<plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>properties-maven-plugin</artifactId>
  <version>1.0-alpha-2</version>
  <!-- Read in newVersion.properties instead of newVersion property -->
  <executions>
    <execution>
      <phase>validate</phase>
      <goals>
        <goal>read-project-properties</goal>
      </goals>
      <configuration>
        <files>
          <file>${session.executionRootDirectory}/newVersion.properties</file>
        </files>
      </configuration>
    </execution> 
</plugin>

I'm also using versions:set to set the new version of the code from a CI build.

This works if I run:

mvn -DBUILD_NUMBER=99 initialize versions:set

IOW, I need to specify the "initialize" goal explicitly or it stops and prompts me for the newVersion because it defaults to running the versions:set goal before initialize goal.

How can I define the initialize goal as a dependency of the versions:set goal?

IMO I should not need to define intermediate target ordering.

Note, I know I could use the versions plugin to do all of this but I need to manage gradle and maven versions from a parent gradle script, so I need the base newVersion to come from an external source so that I can use it from multiple build environments.

Bruce Edge
  • 1,975
  • 1
  • 23
  • 31

1 Answers1

1

Re mvn ... initialize ... – You bound the read-project-properties goal of the properties-maven-plugin to the validate phase, so mvn validate should be sufficient. (Introduction to the Build Lifecycle, Default Lifecycle).

Invoking mvn ... versions:set without any phase executes the set goal of the versions plugin directly without passing through (any phase of) the default lifecycle. That means it doesn't „default to running the versions:set goal before initialize“, it doesn't pass the initialize phase (initialize is a phase not a goal) at all.

And there's also the following at Versions Maven Plugin, Basic Usage:

Maven 2.0, 2.1, 2.2 and 3.0 do not currently support re-reading modifications of the pom.xml within one invocation of Maven.

The following goals:

  • versions:set
  • ...

modify the pom.xml file, you need to run these goals separately from any other goals or life-cycle phases.

I'm not aware of any way to define a phase as dependency of a goal but you can declare:

<build>
  <defaultGoal>...</defaultGoal>
  • defaultGoal: the default goal or phase to execute if none is given. If a goal is given, it should be defined as it is in the command line (such as jar:jar). The same goes for if a phase is defined (such as install).

See POM Reference, The BaseBuild Element Set.

Gerold Broser
  • 14,080
  • 5
  • 48
  • 107
  • Sigh. One more reason to migrate to gradle. Thanks for the detailed answer Gerold. – Bruce Edge Sep 08 '15 at 17:07
  • @Bruce Do you know that this is easier with Gradle? I don't. I've never had a task I couldn't fulfilll with Maven, so I've never had a reason to migrate to something else. What about declaring profiles in your[`settings.xml`](https://maven.apache.org/guides/introduction/introduction-to-profiles.html) or in your [POM](https://maven.apache.org/pom.html#Profiles): 1) _dev_ (set as active by default) for your normal project work and 2) _setVersion_ that binds `versions:set` to the `initialize` phase (which also assures that `read-project-properties` bound to `validate` is executed before). – Gerold Broser Sep 09 '15 at 09:14
  • 1
    @Bruce See also [my answer to _Maven: Lifecycle vs. Phase vs. Plugin vs. Goal_](http://stackoverflow.com/a/30953905/1744774) for what it's all about with the named Maven entities. – Gerold Broser Sep 09 '15 at 13:52
  • I've been working with gradle & maven side by side for a couple of years now. I'm not a maven expert (or a gradle one for that matter), but I favor gradle as it's groovy plus a DSL specific to processing inputs into outputs with plugins added for specifics. The fact that it is based on groovy makes the unusual cases easier to handle as extension is a natural part of the process. I've gotten mileage from the groovy-maven-plugin plugin, but it's less functional that extending via groovy as needed. For the above case with gradle, I would declare a dependsOn clause to force the ordering. – Bruce Edge Sep 10 '15 at 17:27
  • @Bruce You know you can extend Maven by [writing own plugins](https://maven.apache.org/plugin-developers/index.html) entirely in Groovy, do you? – Gerold Broser Sep 10 '15 at 17:50
  • I hadn't ever been that deep into maven. I guess that's the difference with gradle is that you're in a more customizeable environment by default whereas with maven you have to make it explicit. As I mentioned, not a maven expert. Thanks for the pointer though, I can see the benefits of that. In fact it may help with the gradle/maven integration I still need to do. – Bruce Edge Sep 11 '15 at 19:05