Maven define goal dependencies, run initialize before versions:set - maven

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.

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.

Related

Maven : Child pom's argline is not applied?

I have a multi-module maven project. In the child module, failsafe plugin is used for the integration tests run. Some argLines are defined accordingly :
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-failsafe-plugin</artifactId>
<configuration>
<skipAfterFailureCount>1</skipAfterFailureCount>
<argLine>-Xmx2048M -Xss512M -XX:+CMSClassUnloadingEnabled -XX:+UseConcMarkSweepGC</argLine>
</configuration>
</plugin>
The problem is when I run the tests as mvn test or mvn integration-test, the arglines are not applied for the tests from neither the parent pom directory nor the child pom directory, but if I run the tests as mvn failsafe:integration-test from both of the directories, the arglines param are applied.
What is the reason behind this ? Is there any way to apply those params when I run the tests with mvn test command ? I tried to pass the parameters via command line as mvn test -Dchild.argline="-Xmx2048M -Xss512M -XX:+CMSClassUnloadingEnabled -XX:+UseConcMarkSweepGC"
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-failsafe-plugin</artifactId>
<configuration>
<skipAfterFailureCount>1</skipAfterFailureCount>
<argLine>${child.argline}</argLine>
</configuration>
</plugin>
But it didn't work.
Also I tried to bind test and integration-test phases to failsafe integration-test and defined configuration params there, but it didn't work as well..
I set the MAVEN_OPTS accordingly but it didn't help...
The failsafe plugin goals are not included in the lifecycle by default. The POM configuration must include it. See this SO answer for an example. Also ensure that the plugin definition is in the <plugins> section, not inside a <pluginManagement> element.
As for how to define options in the POM - use the names supplied in the documentation. So, to specify argLine, add
<argLine>...</argLine>
in the plugin config. To specify on the command line, note that "User property" for the value you want to set. For the failsafe plugin's argLine, the user property is also argLine, so on the command line specify
-DargLine=...
Maven knows nothing about child.argline so silently ignores it. Also note, attribute and user property names are case sensitive.

How to disable jar creation in commandline in a maven project?

I have a maven project for which I'm running two separate builds.
In one build I want to save the build time by disabling the jar creation of maven modules in it.(There are 45 maven modules). There is a Maven-Jar-Plugin that is being used to create the jars.
I want to conditionally disable the jar creation at the command line, that is, looking for something similar to -Dskiptests used to skip the unit tests though there is a surefire plugin by default.
The maven-jar-plugin does not provide any skip option.
However, several ways are possible to achieve your requirement.
You may just skip the phase which brings by default (via default mappings) the jar creation, that is, the package phase, and as such simply invoke
mvn clean test
The additional phases would not make sense if you do not create a jar file anyway: package, install, deploy would not have anything to process. Moreover, the additional integration phases may also be impacted depending on your strategy for integration tests, if any.
Alternatively, you can configure your pom as following:
<properties>
<jar.creation>package</jar.creation>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>3.0.0</version>
<executions>
<execution>
<id>default-jar</id>
<phase>${jar.creation}</phase>
</execution>
</executions>
</plugin>
</plugins>
</build>
As such, the default behavior would still provide a jar creation, while executing maven as following:
mvn clean install -Djar.creation=false
Would instead skip the creation of the jar.
What we are actually doing:
We are re-defining the default execution of the maven-jar-plugin
We are overriding its execution id, as such getting more control over it
We are placing its execution phase binding to a configurable (via property) phase
Default phase (property value) keeps on being package
At command line time you can still change it to any value different than a standard maven phase. That is, -Djar.creation=none would also work.

How to get the current build version in Maven/Tycho

I have read that the ${project.version} property should be used to obtain the full version of a project.
But if I use this property in a build to pass the currently built version to an external build process, its values is alway 1.0.0-SNAPSHOT where I would need something like 1.0.0-20160220-1234. The phase in which the external build step is called is `package´.
The tycho-packaging-plugin is configured to produce timestamps like this:
<configuration>
<format>yyyyMMdd-HHmm</format>
</configuration>
And the resulting artifacts do have timestamps in the versions/names
I use Maven 3.3.3 with Eclipse Tycho 0.24, however, with previous versions of Tycho the behavior is the same. Not sure if Tycho behaves differently than plain Maven in this regard.
The build is run with
mvn clean verify
in the directory of the master pom.
The actual project I am using this for is Extras for Eclipse. The external build step is invoked in line 129 of the 'repository' child pom.
I have also used the echo plug-in in the above-mentioned child pom to diagnose the problem like this:
<plugin>
<groupId>com.soebes.maven.plugins</groupId>
<artifactId>maven-echo-plugin</artifactId>
<version>0.1</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>echo</goal>
</goals>
</execution>
</executions>
<configuration>
<echos>
<echo>actual version: ${project.version}</echo>
</echos>
</configuration>
</plugin>
The output is the same as the external build receives: 1.0.0-SNAPSHOT.
What do I need to do or which property do I need to use to get the qualified version of the current build?
From my understanding the ${project.version} property should hold the qualified version, e.g. 1.0.0-20160218-1234. But either there is a bug in Maven/Tycho or my understanding is plain wrong. And I would be happy if someone could clarify this.
However, I found the ${qualifiedVersion} property that is set by the tycho-packaging:build-qualifier mojo. This property holds the expected value.
Note that even though the documentation states
is assigned to the project property qualifiedVersion
the property cannot be accessed through ${project.qualifiedVersion}. It needs to be referenced as ${qualifiedVersion}.

Maven: Let "mvn -Pjenkins" be the same as "mvn clean install pmd:pmd javadoc:aggregate"

We have a number of Maven jobs in our Jenkins instance, each with their own particular invocation string specified in the build configuration similar to
mvn clean install -DDISABLED="javadoc:aggregate" checkstyle:checkstyle pmd:pmd findbugs:findbugs
I would like to consolidate this so that the invocation string is stored somewhere in the POM along with suitable profile information so we can replace the invocation strings of all these slightly different jobs with a
mvn -Pjenkins
standard invocation. To my understanding the defaultGoal entry only supports a single goal which on first glance seems to be insufficient for representing our multiple goals, but might be enough if we can make it correspond to multiple entries instead. If at all possible I would like avoid setting up profile specific bindings to standard lifecycle phases if a simple invocation string will do.
You can configure additional mojos ina profile, and you can bind mojos to life cycle phases. These two things combined will allow you to run additional mojos when a certain profile is given.
This is a standard techniqued used throughout in Maven. For example, when you run "mvn release:perform", it runs a nested Maven session with "-Prelease" that does additional things, such as GPG-signing binaries.
<profile>
<id>jenkins</id>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>findbugs-maven-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>findbugs</goal>
</goals>
</execution>
</executions>
</plugin>
... other mojos ...
The findbugs mojo is bound by default to the compile phase, so this gets invoked automatically at the compilation phase. If you want to use a mojo that doesn't bind to any lifecycle phase by default, you add <phase>...</phase>.
See our POM in the Jenkins core for a complete example where we invoke FindBugs. The other mojos are the basically the same.
Note that for this to work, your default goal needs to invoke the life cycle phase to the certain point (say package or install.)
I don't think there's a direct way to give Maven an invocation string. As you say, you can add a custom 'jenkins' profile in which you configure the checkstyle, pmd, and findbugs plugins to be bound to a build phase (e.g. their default phase). You would still need to run mvn -Pjenkins clean install though. However this has the advantage that you can also add custom config to those plugins (e.g. to include test code in the PMD coverage).
I think you can add the settings for the checkstyle, pmd, findbugs and javadoc plugins in a profile's <build><plugins/></build> section along with a <properties> bit where you can define the javadoc property. Also, add an explicit invocation of the maven-clean-plugin attached to the clean phase. Then just invoke the build like:
mvn -Pjenkins site:site
You could even set the defaultGoal to site, if you like.

Skip tests on checkout during maven release:perform

During the maven release:perform goal, the prepared tag is being checked out from SCM and a build seems to be attempted in a forked maven instance.
I'd like the tests to be skipped at that point, because for whatever reason, they fail (the build involves running a test web-application via cargo, and I believe this just doesn't work well in this environment).
Is there any way to instruct maven to do this?
You can specify arguments to the forked maven instance on the command line:
mvn release:prepare -Darguments="-DskipTests"
mvn release:perform -Darguments="-DskipTests"
or specify a maven-release-plugin configuration in your pom, perhaps under pluginManagement:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<configuration>
<arguments>-DskipTests</arguments>
</configuration>
</plugin>

Resources