I just tracked down a difficult maven issue that was caused by a bad property value.
The property is a path to an alternate JVM that is used a run-time by a test.
I would like to make maven fail early by detecting if the path is valid or not.
What might be a way to accomplish this?
I plan to dig into antrun to see if there is a way to make it run first so that it can check, but that seems like overkill.
Question: How can I do this cleanly and simply?
You can use the Enforcer Maven Plugin and its Require Property rule, where you can enforce the existence of a certain property, optionally with a certain value (a matching regex), and fail the build otherwise.
This rule can enforce that a declared property is set and optionally evaluate it against a regular expression.
A simple snippet would be:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<version>1.4.1</version>
<executions>
<execution>
<id>enforce-property</id>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<requireProperty>
<property>basedir</property>
<message>You must set a basedir property!</message>
<regex>.*\d.*</regex>
<regexMessage>The basedir property must contain at least one digit.</regexMessage>
</requireProperty>
</rules>
<fail>true</fail>
</configuration>
</execution>
</executions>
</plugin>
Yes, you can use the maven-enforcer-plugin for this task. This plugin is used to enforce rules during the build and it has a built-in requireFilesExist rule:
This rule checks that the specified list of files exist.
The following configuration will enforce that the file ${project.build.outputDirectory}/foo.txt exists and will fail the build if it does not.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<version>1.4.1</version>
<executions>
<execution>
<id>enforce-files-exist</id>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<requireFilesExist>
<files>
<file>${project.build.outputDirectory}/foo.txt</file>
</files>
</requireFilesExist>
</rules>
<fail>true</fail>
</configuration>
</execution>
</executions>
</plugin>
Use the Require Files Exist rule of the Maven Enforcer plugin.
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<version>1.4.1</version>
<executions>
<execution>
<id>enforce-files-exist</id>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<requireFilesExist>
<files>
<file>${property.to.check}</file>
</files>
</requireFilesExist>
</rules>
<fail>true</fail>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
Related
I would like to build from a maven pom running two sequential executions of the same plugin, in the same phase differing only by a single property, which will result in two different archives being created. Since the configuration is rather complicated, I'd rather NOT copy it just to change one value, which would create a maintenance nightmare. If it was somehow possible to define such a property in the <executions> section of the plugin config, I could avoid this headache.
Question: Is this possible and if so how?
Update: Two answers have mentioned using multiple executions and one of them mentions that you can have separate configurations in each execution. But given that the majority of my configuration is constant between the two executions, can I have one configuration on the plugin level and also have configuration sections in each execution for the parts that are different?
Given the simple Maven Source Plugin configuration (as an example) you have a shared configuration across all of its executions (outside the executions element) and then a custom configuration per each execution, for the same phase, as requested by your question:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<version>2.4</version>
<configuration>
<includePom>true</includePom>
</configuration>
<executions>
<execution>
<id>test-id1</id>
<phase>verify</phase>
<goals>
<goal>jar</goal>
</goals>
<configuration>
<finalName>aaa</finalName>
</configuration>
</execution>
<execution>
<id>test-id2</id>
<phase>verify</phase>
<goals>
<goal>jar</goal>
</goals>
<configuration>
<finalName>bbb</finalName>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
The configuration entry <includePom>true</includePom> will in this case be merged with the custom configurations of each execution and as such centralize the common configuration as plugin generic configuration.
For more details on the different level of configurations, you can check official Maven documentation, here, in particular the example "Configuring compile to run twice". Further details are also available on the official POM documentation, here, Plugins section.
You need to create a different execution (still bound to the same phase)
To avoid duplication of the config, you can put the <configuration> outside the <execution> element and then in the 2 executions, you only define the property that is different.
Taken from the maven docs:
<project>
...
<build>
<plugins>
<plugin>
<artifactId>maven-myquery-plugin</artifactId>
<version>1.0</version>
<executions>
<execution>
<id>execution1</id>
<phase>test</phase>
<configuration>
<url>http://www.foo.com/query</url>
<timeout>10</timeout>
<options>
<option>one</option>
<option>two</option>
<option>three</option>
</options>
</configuration>
<goals>
<goal>query</goal>
</goals>
</execution>
<execution>
<id>execution2</id>
<configuration>
<url>http://www.bar.com/query</url>
<timeout>15</timeout>
<options>
<option>four</option>
<option>five</option>
<option>six</option>
</options>
</configuration>
<goals>
<goal>query</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
...
</project>
You create two <execution> elements within the <plugin> declaration. Each <execution> element can have it's own <configuration> section.
I wanted to create a jar and a put in in a zip file with other config files
This worked for me
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.4.1</version>
<executions>
<execution>
<id>build-jar-with_dep1</id>
<phase>package</phase>
<configuration>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
<finalName>${buildversion}</finalName>
<finalName>finalname</finalName>
<appendAssemblyId>false</appendAssemblyId>
</configuration>
<goals>
<goal>assembly</goal>
</goals>
</execution>
<execution>
<id>build_zip1</id>
<phase>package</phase>
<configuration>
<descriptor>src/assembly/bin.xml</descriptor>
<finalName>${buildversion}</finalName>
<finalName>finalname</finalName>
<appendAssemblyId>false</appendAssemblyId>
</configuration>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
I'm wondering if there is a way to enforce the existence of a dependency to unpack when using the dependency-unpack goal of the maven dependency plugin. I'm using the configuration below and the problem is that if there is no dependency specified for "${properties.artifactId}" in the dependencies section of the pom the build goes ahead even though nothing has been unpacked. It invariably fails later at the test stage but it would be so much easier if the build could fail when no dependency is present. So does anyone know of a way that this can be enforced?
Thanks
Piers
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>unpack-properties</id>
<phase>generate-resources</phase>
<goals>
<goal>unpack-dependencies</goal>
</goals>
<configuration>
<includeArtifactIds>${properties.artifactId}</includeArtifactIds>
<outputDirectory>${project.build.directory}</outputDirectory>
<includes>${properties.file.name}</includes>
</configuration>
</execution>
</executions>
</plugin>
A couple of executions of the maven-enforcer-plugin should do it. You need one to run before the dependency plugin, to make sure ${properties.artifactId} has a value, then another that runs after the dependency plugin to make sure there are files in the target location. Here's the idea, modify for your requirements.
You may write your own rules too if those available don't quite fit.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<version>fillInTheVersion</version>
<executions>
<execution>
<id>enforce-config-properties</id>
<phase>validate</phase>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<requireProperty>
<property>properties.artifactId</property>
<message><![CDATA[### Missing property 'properties.artifactId': the artifact that ....]]></message>
</requireProperty>
</rules>
</configuration>
</execution>
<execution>
<id>enforce-files-exist</id>
<phase>process-resources</phase>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<requireFilesExist>
<files>
<file>${project.build.directory}/${properties.artifactId}</file>
</files>
<message><![CDATA[### Did not find unpacked artifact ...]]></message>
</requireFilesExist>
</rules>
</configuration>
</execution>
</executions>
</plugin>
I would like to ensure the file size of resulting zip file is not larger than 400 MB so I've created this rule:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<executions>
<execution>
<id>enforce-file-size</id>
<goals>
<goal>enforce-once</goal>
</goals>
<configuration>
<rules>
<requireFilesSize>
<maxsize>419430400</maxsize> <!-- the final zip should not exceed 400 MB -->
<files>
<file>${project.build.outputDirectory}.zip</file>
</files>
</requireFilesSize>
</rules>
<fail>true</fail>
</configuration>
</execution>
</executions>
</plugin>
However, the mvn enforcer is by default bound to the validate phase and unfortunately the file does not exist by this time. The zip file is generated by ant task that is bound to generate-resources mvn phase.
Question
Is there any way to make the mvn enforcer to run after generate-resources? Or to put it another way, how can I verify a build post-condition instead pre-condition?
omg, adding <phase>verify</phase> worked for me:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<executions>
<execution>
<id>enforce-file-size</id>
<phase>verify</phase>
<goals>
<goal>enforce-once</goal>
</goals>
<configuration>
<rules>
<requireFilesSize>
<maxsize>419430400</maxsize> <!-- the final zip should not exceed 400 MB -->
<files>
<file>${project.build.outputDirectory}.zip</file>
</files>
</requireFilesSize>
</rules>
<fail>true</fail>
</configuration>
</execution>
</executions>
</plugin>
Is there a way to have maven pad a numeric value (ex: build number) within a POM? I've been googling the topic and haven't come up with anything yet.
My use case is as follows. The maven build process is provided a build number via Jenkins which needs to be included as part of the name of the WAR that is generated. So if I provide it 12 as the build number, then I want the WAR file name to be myWar##000012.war. The ##000012 part of the name is the version identifier used by Tomcat.
The simplest solution may be to embed a scripting language in your build. For example, with Groovy, if you have a buildNumber property:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>groovy-maven-plugin</artifactId>
<version>1.5</version>
<executions>
<execution>
<phase>validate</phase>
<goals><goal>execute</goal></goals>
<configuration>
<source>
project.properties['nameSuffix'] = "##" + String.format("%06d", project.properties['buildNumber'].toLong());
</source>
</configuration>
</execution>
</executions>
</plugin>
Afterwards the nameSuffix property is available to define the final name.
Alternatively, as suggested in In Maven, how can I dynamically build a property value at runtime?, use build-helper:regex-property to transform the string.
Have you tried using the maven release plugin?
Based upon #Joe suggestion I looked into the build-helper-maven-plugin and was able to come up with the following which does what I need. I wasn't able to identify how to do it all in one step, so I'm doing it in 2. The first step pads the value on the left with zeros. The second step trims the numeric value so that it is only 7 digits long. Please note that ${build.env.version} is passed in as a parameter to the maven build process and that I have defaulted it to 0 in the POM file for when it isn't passed. If you don't provide a default value then the build fails even though failOnError on set to false.
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.8</version>
<executions>
<execution>
<id>stage1--padNumber</id>
<goals>
<goal>regex-property</goal>
</goals>
<configuration>
<name>build.env.version.padded</name>
<value>${build.env.version}</value>
<regex>^([\d]{0,})$</regex>
<replacement>000000$1</replacement>
<failIfNoMatch>false</failIfNoMatch>
<failOnError>false</failOnError>
</configuration>
</execution>
<execution>
<id>stage2--leftTrimToXcharacters</id>
<goals>
<goal>regex-property</goal>
</goals>
<configuration>
<name>build.env.version.padded</name>
<value>${build.env.version.padded}</value>
<regex>^([\d]*)([\d]{7})$</regex>
<replacement>$2</replacement>
<failIfNoMatch>false</failIfNoMatch>
<failOnError>false</failOnError>
</configuration>
</execution>
</executions>
</plugin>
Based upon #jwmajors81 suggestion, I needed to pad the major version for a specific reason...
As we were already using the build-helper-maven-plugin, it is easy enough to get the major version by using the parse-version goal of the build helper. (we only needed 3 chars):
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.8</version>
<executions>
<execution>
<id>parse-version</id>
<goals>
<goal>parse-version</goal>
</goals>
</execution>
<execution>
<id>stage1--padNumber</id>
<goals>
<goal>regex-property</goal>
</goals>
<configuration>
<name>build.env.version.padded</name>
<value>${parsedVersion.majorVersion}</value>
<regex>^([\d]{0,})$</regex>
<replacement>00$1</replacement>
<failIfNoMatch>false</failIfNoMatch>
<failOnError>false</failOnError>
</configuration>
</execution>
<execution>
<id>stage2--leftTrimToXcharacters</id>
<goals>
<goal>regex-property</goal>
</goals>
<configuration>
<name>build.env.version.padded</name>
<value>${build.env.version.padded}</value>
<regex>^([\d]*)([\d]{3})$</regex>
<replacement>$2</replacement>
<failIfNoMatch>false</failIfNoMatch>
<failOnError>false</failOnError>
</configuration>
</execution>
</executions>
</plugin>
Yet, in that particular case, if you also need to generate a buildNumber, buildnumber-maven-plugin may be the most straight solution:
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>buildnumber-maven-plugin</artifactId>
<version>1.4</version>
<configuration>
<format>{0, number,000000}</format>
<items>
<item>buildNumber</item>
</items>
</configuration>
<executions>
<execution>
<phase>validate</phase>
<goals>
<goal>create</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
<finalName>myWar##${buildNumber}</finalName>
My question is simple: I want maven to give me some error messages when any property is not found during resource filtering.
I didn't find any clue in the official maven docs.
So how could I do this?
I would suggest to take a deep look at the maven-enforcer-plugin which can be used for such things:
<project>
[...]
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<version>1.2</version>
<executions>
<execution>
<id>enforce-property</id>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<requireProperty>
<property>basedir</property>
<message>You must set a basedir property!</message>
<regex>.*\d.*</regex>
<regexMessage>The basedir property must contain at least one digit.</regexMessage>
</requireProperty>
<requireProperty>
<property>project.version</property>
<message>"Project version must be specified."</message>
<regex>.*(\d|-SNAPSHOT)$</regex>
<regexMessage>"Project version must end in a number or -SNAPSHOT."</regexMessage>
</requireProperty>
</rules>
<fail>true</fail>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
[...]
</project>