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>
Related
I'm using jmeter's maven plugin and I would like to generate two different HTML reports from the same execution log. Is it even possible to do this using this plugin?
This is my pom.xml and I'm not sure how to create a second report with a different output folder and title for example.
<build>
<plugins>
<plugin>
<groupId>com.lazerycode.jmeter</groupId>
<artifactId>jmeter-maven-plugin</artifactId>
<version>${jmeter.plugin.version}</version>
<executions>
<execution>
<id>configuration</id>
<goals>
<goal>configure</goal>
</goals>
</execution>
<execution>
<id>tests</id>
<goals>
<goal>jmeter</goal>
</goals>
</execution>
<execution>
<id>check-results</id>
<goals>
<goal>results</goal>
</goals>
</execution>
</executions>
<configuration>
<propertiesUser>
<thread.number>${thread.number}</thread.number>
<rampup>${rampup}</rampup>
<jmeter.reportgenerator.report_title>CA Dashboard</jmeter.reportgenerator.report_title>
</propertiesUser>
<ignoreResultFailures>true</ignoreResultFailures>
<generateReports>true</generateReports>
</configuration>
</plugin>
</plugins>
</build>
Currently no, the report generation happens at the same time the test is run.
When the following issues have been fixed it may be an option:
https://github.com/jmeter-maven-plugin/jmeter-maven-plugin/issues/328
https://github.com/jmeter-maven-plugin/jmeter-maven-plugin/issues/391
https://github.com/jmeter-maven-plugin/jmeter-maven-plugin/issues/316
Is it possible to get the major version (<Major>.<Minor>.<Patch>) of the project.version?
For example if my version is 1.3.4, I'd like to get 1 to later use it in a configuration of the same pom.xml
Something like:
<configuration>
<name>project_name.${project.version:major}</name>
</configuration>
If not, what are the alternatives?
Found it. The build-helper-maven-plugin has the ability to parse-out the components of the version.
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.5</version>
<executions>
<execution>
<phase>initialize</phase>
<id>parse-version</id>
<goals>
<goal>parse-version</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.1</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<echo>[version] ${project.version}</echo>
<echo>[majorVersion] ${parsedVersion.majorVersion}</echo>
</tasks>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
This works on Maven 3.3.9:
${project.artifact.selectedVersion.majorVersion}
Versions don't necessarily come in the structure you describe.
Maven has conventions for trailing numbers, but you don't have to use them.
If you have a convention that you like that you want to disassemble, you can write your own maven plugin that sets several properties to the several pieces as you define them.
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>
W want my maven project to produce three artifacts with different classifiers at once. I know that I can produce it with modules etc. This is actually a resources project that I want to produce configuration for DEV, STAGE and PROD environment.
What I want to have is to run mvn:install once and have my.group:resources:1.0:dev, my.group:resources:1.0:stage and my.group:resources:1.0:prod in my repo.
This can be done without profiles if you specify multiple plugin executions and resource filtering.
Create a properties file for each version in ${basedir}/src/main/filters (e.g. prod.properties, dev.properties) holding appropriate values for each environment.
Turn on filtering for your resources:
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
</resource>
</resources>
Now add the resource plugin executions. Note the different filter file and output directory.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<executions>
<execution>
<id>default-resources</id>
<phase>process-resources</phase>
<goals>
<goal>resources</goal>
</goals>
<configuration>
<outputDirectory>${project.build.outputDirectory}/dev</outputDirectory>
<filters>
<filter>${basedir}/src/main/filters/dev.properties</filter>
</filters>
</configuration>
</execution>
<execution>
<id>prod</id>
<phase>process-resources</phase>
<goals>
<goal>resources</goal>
</goals>
<configuration>
<outputDirectory>${project.build.outputDirectory}/prod</outputDirectory>
<filters>
<filter>${basedir}/src/main/filters/prod.properties</filter>
</filters>
</configuration>
</execution>
</executions>
</plugin>
Finally, the jar plugin; note classifier and input directory:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<executions>
<execution>
<id>default-jar</id>
<phase>package</phase>
<goals>
<goal>jar</goal>
</goals>
<configuration>
<classifier>dev</classifier>
<classesDirectory>${project.build.outputDirectory}/dev</classesDirectory>
</configuration>
</execution>
<execution>
<id>jar-prod</id>
<phase>package</phase>
<goals>
<goal>jar</goal>
</goals>
<configuration>
<classifier>prod</classifier>
<classesDirectory>${project.build.outputDirectory}/prod</classesDirectory>
</configuration>
</execution>
</executions>
</plugin>
Running mvn clean install should produce the properly filtered resources in artifacts with dev and prod classifiers like you want.
In the example, I used execution IDs of default-resources and default-jar for the dev versions. Without this you would also get an unclassified jar artifact when you build.
Just an FYI - put the version number in there to make sure you have the version supporting custom filters. In maven 3 I set mine up like this for example. Without version it didn't work.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<version>2.6</version>
...
</plugin>
Is it possible to get the major version (<Major>.<Minor>.<Patch>) of the project.version?
For example if my version is 1.3.4, I'd like to get 1 to later use it in a configuration of the same pom.xml
Something like:
<configuration>
<name>project_name.${project.version:major}</name>
</configuration>
If not, what are the alternatives?
Found it. The build-helper-maven-plugin has the ability to parse-out the components of the version.
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.5</version>
<executions>
<execution>
<phase>initialize</phase>
<id>parse-version</id>
<goals>
<goal>parse-version</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.1</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<echo>[version] ${project.version}</echo>
<echo>[majorVersion] ${parsedVersion.majorVersion}</echo>
</tasks>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
This works on Maven 3.3.9:
${project.artifact.selectedVersion.majorVersion}
Versions don't necessarily come in the structure you describe.
Maven has conventions for trailing numbers, but you don't have to use them.
If you have a convention that you like that you want to disassemble, you can write your own maven plugin that sets several properties to the several pieces as you define them.