I am using ${surefire.forkNumber} in system property in my pom. According to maven documentation, it should be resolved to the number of fork that is currently running. But it is resolving as null.
Below is snippet of my pom file:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-failsafe-plugin</artifactId>
<version>2.16</version>
<configuration>
<forkCount>3</forkCount>
<reuseForks>true</reuseForks>
<redirectTestOutputToFile>true</redirectTestOutputToFile>
<systemPropertyVariables>
<database.name>My_Test_Schema_${surefire.forkNumber}</database.name>
</systemPropertyVariables>
</configuration>
</plugin>
Am I missing anything?
Please, anybody throw some light...
It might be that ${surefire.forkNumber} is substituted twice: first by maven-core, and then by surefire. Since maven-core doesn't know about this property, it substitutes null there.
Solution: protect from first substitution by quoting $:
<systemPropertyVariables>
<database.name>My_Test_Schema_$${surefire.forkNumber}</database.name>
</systemPropertyVariables>
Source: http://maven.40175.n5.nabble.com/SureFire-2-16-doesn-t-respect-forkCount-td5771850.html#a5771855
This one worked for me --- I had the same problem. It's a pity this isn't documented.
Pass setting via VM -D within argLine:
<argLine>-Ddatabase.name=My_Test_Schema_${surefire.forkNumber}</argLine>
I found systemPropertyVariables to be quite fragile. See SureFire 2.16 doesn't respect forkCount (which didn't work for me one way or the other using surefire 2.17).
You can use the place holder ${surefire.forkNumber} within argLine, or within the system properties
You should pass the value to place holder either these three ways..
1. command line argument like mvn test -Dsurefire.forkNumber=8
2. set by systemPropertyVariables System.setProperty("surefire.forkNumber",8);
3. set by pom properties tag like
<properties>
<surefire.forkNumber>8</surefire.forkNumber>
</properties>
Related
Since last few days a lot of doubts got cleared because of the you all experts. I have one more question, when i see my pom.xml in my project , I see a lot of plugins with quite a few configuration. for e.g
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>3.0.0-M4</version>
<dependencies>
<dependency>
<groupId>org.apache.maven.surefire</groupId>
<artifactId>surefire-junit-platform</artifactId>
<version>3.0.0-M4</version>
</dependency>
</dependencies>
<configuration>
<forkCount>1</forkCount>
<reuseForks>true</reuseForks>
<argLine>${argLine} -Xmx4g -XX:MaxPermSize=1g</argLine>
<includes>
<include>**/*Test.java</include>
<include>**/*Spec.java</include>
</includes>
</configuration>
</plugin>
My question is how they decided the these forkcount , argLine needed to be used here? plus the dependency also. When i checked the bealdung doc for same plugin the config was very simple. is it necessary to read docs for a perticular plugin before using it. like how people take decisions for the same that what are the tags to be used or what are the mandatory tags. any links will be helpful.
Thanks
I strongly recommend reading the docs of the appropriate plugin which would show like in your example defining the provider (the dependency) https://maven.apache.org/surefire/maven-surefire-plugin/examples/providers.html is usually not needed nor helpful/useful. For the other settings it depends on what kind of tests you are running but from my point of view I would strongly review my tests because needed to set 4 GiB for heapspace sounds weird .... especially for a tests? The others parts depends on the testing framework you are using.. and your use case. I usually start without any configuration for my builds ...only If i really need to change something I do so which is rarely the case. (Convention over configuration)... and read the docs: https://maven.apache.org/surefire/maven-surefire-plugin/plugin-info.html
Is it possible in Maven to access a configuration value from another configuration value? For example, in the Release Plugin it is possible to access the project.version key during configuration of the tagNameFormat element. What I would like to do is to then use the tagNameFormat value in another element named completionGoals. See below:
<!-- Snippet from a POM -->
<build>
<plugins>
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>2.5.3</version>
<configuration>
<tagNameFormat>${my.pom.property}#{project.version}-${my.pom.property.extra}</tagNameFormat>
<checkModificationExcludes>
<checkModificationExclude>pom.xml</checkModificationExclude>
</checkModificationExcludes>
<completionGoals>clean verify help:evaluate -Dexpression=${tagNameFormat}</completionGoals>
</configuration>
<executions>
<execution>
<id>default</id>
<goals>
<goal>prepare</goal>
<goal>perform</goal>
</goals>
<configuration>
<pomFileName>${release.pom.path}pom.xml</pomFileName>
</configuration>
</execution>
</executions>
</plugin>
...
</plugins>
</build>
Notably, in the above configuration, I can see that the tagNameFormat itself is populated with both the standard POM version property and my own custom property (that incidentally is runtime-defined at the command-line). However, when I try to access the value to define another configuration element, completionGoals, completionGoals appears as a variable placeholder, e.g. "${tagNameFormat}" literally appears in the resulting command. (Verified by running Maven with the -X and -e flags.)
Question(s):
Is it possible to get a populated plugin configuration value from the Maven plugin configuration in the POM?
Am I referring to the tagNameFormat configuration element correctly? How could I do this with the Release plugin?
What does the '#' versus the '$' mean? (Guess: Dynamically versus statically evaluated?)
The only way I'm aware of is to define another POM property:
<property>
<my.pom.property>...</my.pom.property>
<my.pom.property.extra>...</my.pom.property.extra>
...
<myTagNameFormat>${my.pom.property}#{project.version}-${my.pom.property.extra}</myTagNameFormat>
</property>
and to use it accordingly:
<tagNameFormat>${myTagNameFormat}</tagNameFormat>
...
<completionGoals>clean verify help:evaluate -Dexpression=${myTagNameFormat}</completionGoals>
Re 3.: AFAIK, the variable delimiters ${...} and #...# are equivalent and I've never read or heard the contrary. But, to be honest, I've never ever used #...# since I'm used to ${...} from Bash and that's also the only one mentioned on the Filter doc page. (#...# is only mentioned at Escape filtering and such I didn't know that it even exists for a long time.)
I am using maven 3.0.4 and would like to make the build timestamp accessible to my application. For this, I'm putting a placeholder in a .properties file and let maven filter on build. While this is working fine for ${project.version}, ${maven.build.timestamp} is not substituted on filtering.
The property seems to be available on build - I can use it to modify the artifact name:
<finalName>${project.artifactId}-${maven.build.timestamp}</finalName>
So why is it not available for resource filtering? And, more importantly, how do I make it accessible?
I have discovered this article, explaining that due to a bug in maven, the build timestamp does not get propagated to the filtering. The workaround is to wrap the timestamp in another property:
<properties>
<timestamp>${maven.build.timestamp}</timestamp>
<maven.build.timestamp.format>yyyy-MM-dd HH:mm</maven.build.timestamp.format>
</properties>
Filtering then works as expected for
buildTimestamp=${timestamp}
I can confirm as of Maven 3.x {maven.build.timestamp} is "working" now. They work arounded the problem, apparently. No additional properties workaround needed anymore.
However, be careful your "filtering" plugin (maven-resources-plugin) is up to date. It needs to be relatively new, so if mvn help:effective-pom shows an old version (ex: 2.6), bump it to something newer, fixed it for me, 3.x ex:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<version>3.1.0</version>
</plugin>
<properties><timestamp>... workaround is no longer required...
This also cleared up, kind of, why it was working in IntelliJ but not the command line. IntelliJ probably uses their own "modified/internal" maven constants, so it was working there, but not from maven command line.
Also note if you add a filtering resource directory to you pom, you may need to also "re-add" the default directory, it gets lost, ex:
<resource>
<directory>src/main/resources-filtered</directory> <!-- to get "maven.build.timestamp" into resource properties file -->
<filtering>true</filtering>
</resource>
<resource>
<directory>src/main/resources</directory> <!-- apparently have to add this is you have the other... -->
</resource>
NB if you're using spring boot as your parent, you have to use #maven.build.timestamp# instead. Also note if you're using spring boot there's a file META-INF/build-info.properties that is optionally created by the spring-boot-maven-plugin that you can read (spring provides a BuildProperties bean for convenience reading it).
In order to enrich the Stackoverflow content for others, that like me, found this post as a way to solve the "problem" of ${maven.build.timestamp}. This is not a maven bug, but an expected behavior of m2e, as can be seen in this post.
Therefore, I believe that we can not expect the solution to be "corrected", since, from what I understand, the correction involves conceptual issues.
In my case, what I did was use the plugin (buildnumber-maven-plugin) as described in this other post.
Adding Maven properties at the pom project level doesn't take into account correct local Timezone, so timestamp may appear wrong :
<properties><timestamp>${maven.build.timestamp}</timestamp></properties>
Using the build-helper-maven-plugin applies the correct timezone and current daylight saving to the timestamp :
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.9.1</version>
<executions>
<execution>
<id>timestamp-property</id>
<goals>
<goal>timestamp-property</goal>
</goals>
<configuration>
<name>timestamp</name>
<pattern>yyyy-MM-dd HH:mm:ss</pattern>
<timeZone>Europe/Zurich</timeZone>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
</resource>
</resources>
</build>
When packaging, Maven will replace any token timestamp in /resources folder, e.g. resources/version.properties :
build.timestamp=${timestamp}
You can then load this properties file in your Application.
When this plugin is attached to the test or package phase, it causes a multi module build to break since it forces dependency resolution before the module dependencies are in the local repository (first build upon updating to a new snapshot version). I'm trying to get the plugin to ignore the offending com.cons3rt group dependencies which are not required for license output. Tried several variations of:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>license-maven-plugin</artifactId>
<version>1.3</version>
<executions>
<execution>
<id>aggregate-add-third-party</id>
<configuration>
<excludedGroups>com.cons3rt</excludedGroups>
</configuration>
<phase>package</phase>
<goals>
<goal>aggregate-add-third-party</goal>
</goals>
</execution>
</executions>
Nothing seems to work - looking at the output of mvn -X, it seems like the plugin is not honoring the configuration setting for excludedGroups. Anyone have any luck using this configuration approach?
In your configuration use a pipe to separate multiple groupIds and set the .* to refer to all sub packages:
<excludedGroups>com.group1.*|com.group2.*</excludedGroups>
A workaround for this problem is to pass the parameter through the command line using the
-Dlicense.excludedGroups
parameter.
e.g. mvn package -Dlicense.excludedGroups=com.jhla.*
Simply Change
<excludedGroups>com.cons3rt</excludedGroups>
to
<excludedGroups>^com\.cons3rt</excludedGroups>
as the given string needs to be a regular expression.
For further information, see documentation at:
http://www.mojohaus.org/license-maven-plugin/aggregate-add-third-party-mojo.html
I would like to setup my maven release to run in batch mode, but I'm not a fan of the default scm tag ${artifactId}-${releaseVersion}. Instead, I'd like to simply tag it with ${releaseVersion}; however, I'm unclear if such a property exists (ie. without the -SNAPSHOT suffix).
I'd like the configuration to resemble the code below. Is such a default tagging possible with the maven-release-plugin?
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>2.0</version>
<configuration>
<tag>${releaseVersion}</tag>
</configuration>
</plugin>
I just got this to work when using Hudson to do my release. I noted that Hudson (with the Maven Release Plugin) is initiating the command with a property like -Dproject.rel.com.example:my-artifact-id=1.0.1. Using the following plugin configuration:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<configuration>
<tag>REL-${project.rel.com.example:my-artifact-id}</tag>
</configuration>
</plugin>
Resulted in the tag being REL-1.0.1
I'm new to the release plugin but I would assume something similar would work from the command line.
You can pass in the properties for:
releaseVersion -- What version you want it to be released as (1.0)
developmentVersion -- The next version (2.0-SNAPSHOT)
tag -- The name of the tag
a 1.0-SNAPSHOT implies a 1.0 release version, but doesn't set it. You can set that property in your POM file as a regular property.
try this:
<configuration>
<tag>${project.version}</tag>
</configuration>