I have a project where most of profiles are activated automatically based on a combination of a file presence and a system property. For example:
<profile>
<id>when-releasing-java-generate-sources</id>
<activation>
<file>
<exists>${basedir}/src/main/java</exists>
</file>
<property>
<name>build.release</name>
</property>
Now I need to release and deploy this project's artifacts and I will use maven-release-plugin.
My problem is that my profiles are not being activated even if I'm passing -Dbuild.release in the command-line.
Also I've tried to use -Darguments=-Dbuild.release, but could not see the plugins that are set in the profiles being executed.
So, there are any way to activate my project's profiles with maven-release-plugin ?
After many hours digging into my issue I found the solution.
First thing that I discovered was that maven-release-plugin has an annoying limitation: it doesn't work when your project has an aggregator POM that is not the parent.
So the first thing that I had to solve was bring the parent POM up to the top of projects hierarchy and turn it the aggregator also.
Once that was done I needed to set the release-plugin up this way:
<plugin>
<artifactId>maven-release-plugin</artifactId>
<version>2.5.3</version>
<configuration>
<arguments>-Dc8tech.build.release -Dc8tech.build.test.coverage ${arguments}</arguments>
<tagNameFormat>v#{project.version}</tagNameFormat>
<autoVersionSubmodules>true</autoVersionSubmodules>
<releaseProfiles>when-releasing-ensure-requirements</releaseProfiles>
</configuration>
</plugin>
Then I was able to release my project properly.
Related
I need to know what is the difference between these two commands which do almost same thing if we execute this command.
Maven doesn't assign any special meaning to release-build. However, projects can use properties (-Dproperty-name=value or just -Dproperty-name) to activate profiles that change the way the project is built (Maven - activate profile based on project property). It's likely to enable some extra steps that are only necessary for final releases. For example, this project uses it to include a native library in the build:
<profile>
<id>native</id>
<activation>
<property>
<name>release-build</name>
</property>
</activation>
<modules>
<module>pi4j-native</module>
</modules>
</profile>
There's no general answer: you'll need to consult the documentation, or build, of the project you're working with.
You can do this much more simpler automatically to activate a profile in case of a release simply via the maven-release-plugin which already supports that out-of-the-box like this:
<plugin>
<artifactId>maven-release-plugin</artifactId>
<version>2.4.2</version>
<configuration>
<releaseProfiles>release</releaseProfiles>
</configuration>
</plugin>
Apart from that it's really bad to acitvate a module only in case of a profile is active. This will lead so several problem.
mvn help:active-profiles only list the profiles activate within the project + system settings you call it in.
It does not list the profiles that have been enabled/activated from i.e. the parent pom.
Any any way to actually see the full list of activated profiles by other means than trial-and-error to look at what properties are enabled or not ?
Another option is mvn help:all-profiles, which also list inherited profiles.
Displays a list of available profiles under the current project.
Note: it will list all profiles for a project. If a profile comes up with a status inactive then there might be a need to set profile activation switches/property.
More details in Maven's help plugin page
I double-checked this and indeed, inherited profiles aren't listed when mvn help:active-profiles is being called. This is with maven-help-plugin version 2.1.1.
There is even a bug-report about this: MPH-79.
As a workaround, you can use older version:
mvn org.apache.maven.plugins:maven-help-plugin:2.0.2:active-profiles ...
Do you always want to see the active profile in your build log? Then you could add the following plugin config to the <build> section.
In this example I added the plugin to the phase 'compile'. It could easily be added to a different phase.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-help-plugin</artifactId>
<version>3.0.1</version>
<executions>
<execution>
<id>show-profiles</id>
<phase>compile</phase>
<goals>
<goal>active-profiles</goal>
</goals>
</execution>
</executions>
</plugin>
this works in maven 3.x
mvn help:active-profiles
mvn help:effective-profiles
Works to list the active profiles
I searching a way to dynamise the version of my artifact depending on the profile.
Often I use the -SNAPSHOT suffix when I build for dev or preprod. But the database connection depends on the profile and I never know if the latest SNAPSHOT version was build using the dev or preprod profile.
The idea would be having a version like this
<version>1.0${suffix}</version>
with ${suffix} =
"" when building with prod profile
"-SNAPSHOT" when building with preprod profile
"-DEV-SNAPSHOT" when building with dev profile
Is there a way of achieving this ?
thanks
edit :
My goal is when I go on jenkins to build my jar, I build the same "tagged" version of my project with the 3 profiles and it deploys 3 differents artifacts.
Actually I tag my project and go build with the prod profile, then I modify the version to add -SNAPSHOT, commit, move the tag, re build with preprod profile, and then repeat for the dev profile.
Seeing your answer to #Michael-O comments, i'd recommend to configure the maven assembly plugin to create the final name of the artifact according to a system property set on each profile. For example:
<build>
<plugins>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<executions>
<execution>
<id>create jar according to profile</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
<configuration>
<finalName>${project.artifactId}-${project.version}_${profile}</finalName>
<appendAssemblyId>false</appendAssemblyId>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
where ${profile} should be a property set to a different value on each profile (for doing that you can see this question). I dunno if there's a variable to get the profile being currently used to build, that would be another question :)
It is not necessary to reassemble the JAR, I would rather use a standard mech: Simply specify a classifier for your artifact in the jar plugin.
Otherwise I would filter a properties in a given properties file and read that in your app. This what I do, e.g. system.env=prod|test|localdev.
I have a single module project that has some unit tests that require an external hardware device. I don't want these tests to execute unless I indicate that the device is available.
I feel like this is solvable using Maven properties and the SureFire exclusion/inclusion configuration, but I can't quite see how to do it. A similar question shows how to disable/enable all the tests in a project based on a Maven property, but doesn't quite answer my issue.
In summary, I wish to identify a pattern (e.g. **/*ResourceTest.java) that describes the tests I don't want to run, unless I pass a Maven property to enable them.
E.g.
mvn clean install (runs the standard tests, but skips device-related tests)
mvn -Drun.device.tests=true clean install (runs all the tests)
Thanks in advance.
(Edited to remove the misleading usage of the word "resource" > replaced with "hardware device").
You also can just use the JUnit Assume methods to decide (inside the test) if a test should be executed or skipped.
The best option IMHO would however be to 'declare' the device dependend tests to be "integration tests" and let them be executed by the Maven Failsafe Plugin. I think this would be the "build in" maven solution without any profile 'magic'.
The link you provided gave the good answer.
The right way
Use a mix of Profile Management and Surefire Configuration inclusion / exlcusion is the right way.
You should ask yourself WHY you want to activate some tests dependings on a resource. The resource should always been in your classpath.
If not, you probably just want to activate some test manually, for some tricky reasons. In that case consider this is a bad use of Maven (how would you automate that on a distant server for instance ?)
What you asked
If you really really want to do that, because you have some good reasons that we are not aware of, simply use this :
This example will trigger the profile when the generated file target/generated-sources/axistools/wsdl2java/org/apache/maven is missing.
Example from Maven official doc : http://maven.apache.org/guides/introduction/introduction-to-profiles.html
<profiles>
<profile>
<activation>
<file>
<missing>target/generated-sources/axistools/wsdl2java/org/apache/maven</missing>
</file>
</activation>
...
</profile>
</profiles>
As of Maven 2.0.9, the tags and could be interpolated. Supported variables are system properties like ${user.home} and environment variables like ${env.HOME}. Please note that properties and values defined in the POM itself are not available for interpolation here, e.g. the above example activator cannot use ${project.build.directory} but needs to hard-code the path target.
You could find more information here : http://www.sonatype.com/books/mvnref-book/reference/profiles-sect-activation.html
Hope that will help.
Don't hesitate to challenge my point of view with you own reasons (even legacy code ;) ) or experience
To expand on #Jean-Rémy answer, I have done the following in my project POM file:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.12</version>
<configuration>
<excludes>
<exclude>${tests.to.skip}</exclude>
</excludes>
</configuration>
</plugin>
</plugins>
</build>
<profiles>
<profile>
<!-- This profile will be used when running tests without a device -->
<id>default-profile</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<properties>
<tests.to.skip>**/*DeviceTest.java</tests.to.skip>
</properties>
</profile>
<profile>
<id>device-profile</id>
<activation>
<property>
<name>device</name>
<value>true</value>
</property>
</activation>
<properties>
<!-- Unsure how to match nothing -->
<tests.to.skip>NOTHING</tests.to.skip>
</properties>
</profile>
This creates two profiles, the default profile will exclude the device tests, whereas the "device-profile" will execute all tests.
To execute the device profile, one can execute mvn -Ddevice=true test.
I have a Jenkins build which builds a maven project with -PmyProfile clean package. This works fine. Now I want the project be deployable but in a separate task (JBoss deployment) so it can be triggered explicitly via the jenkins GUI. For that, I have the following in my pom:
<profiles>
<profile>
<id>myProfile</id>
<properties>...</properties>
<build>
<plugins>
<plugin>
<groupId>org.jboss.as.plugins</groupId>
<artifactId>jboss-as-maven-plugin</artifactId>
<version>7.0.0.Final</version>
<configuration>
<hostname>localhost</hostname>
<port>29999</port>
<username>admin</username>
<password>admin</password>
<filename>${project.build.finalName}.war</filename>
<name>my-webapp</name>
</configuration>
</plugin>
</plugins>
</build>
</profile>
</profiles>
Now I only want to call that single deployment via mvn jboss-as:deploy separately. But how would I do that? If I create a second Jenkins project, everything needs to be built again, so that's pretty stupid. Building as a separate module does not work, either (some error with "building single modules not supported for maven 3").
Any ideas?
Thanks
It sucks a little, but you can always get stuff from another Jenkins workspace by using filesystem relative path like ../../SecondJob/workspace (or use symlink). I used to do this for the same case (deploying as separate job) for all my projects and it works, it's just not elegant, but I believe there's no built-in solution in Jenkins for that.
Alternatively, it seems there's Jenkins plugin for that, but I haven't used it and can't tell anything about it.
Possible trick:
Have only one project, but parameterize it with DEPLOY parameter set to FALSE by default. The build will contain your main build as well as an Invoke top-level Maven targets post-build step for deployment. The deployment step will be invoked only if DEPLOY is TRUE. To do that you use Conditional Build Step plugin.
There is a new deploy-only goal added in version 7.5.Final. You can grab the war from the first job with Copy Artifact Plugin.
References:
https://docs.jboss.org/jbossas/7/plugins/maven/latest/deploy-only-mojo.html
https://github.com/jbossas/jboss-as-maven-plugin/pull/56/commits