Using build-helper-maven-plugin - maven

I have the pom.xml below.
I'd like to pass a tag property to my build, using this command:
mvn clean package -Dtag=test
It should split this property into two others, my.group an my.version, and then use it in a URI to build an XLDeploy package, using the xldeploy-maven-plugin (https://docs.xebialabs.com/xldeploy-maven-plugin/6.0.x/).
My problem is that the regex-properties goal is actually doing the job, as I can see thanks to the maven-antrun-plugin:
[INFO] --- maven-antrun-plugin:1.1:run (default) # myArtifactId ---
[INFO] Executing tasks
[echo] Displaying value of 'my.group' property
[echo] [my.group] group/test
[echo] Displaying value of 'my.version' property
[echo] [my.version] test
But the command grep fileUri target\deployit-working-dir\deployit-manifest.xml show that the vars in Uri does not get replaced:
grep fileUri target\deployit-working-dir\deployit-manifest.xml
<fileUri>http://mynexus.ur/service/local/repositories/my-repo/content/${my.group}/anArtefact/${my.version}/anArtefact-1.0.zip</fileUri>
The POM is the following file:
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>myGroupId</groupId>
<artifactId>myArtifactId</artifactId>
<version>1.0</version>
<packaging>dar</packaging>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>3.0.0</version>
<executions>
<execution>
<id>regex-properties</id>
<goals>
<goal>regex-properties</goal>
</goals>
<configuration>
<regexPropertySettings>
<regexPropertySetting>
<name>my.group</name>
<value>group/${tag}</value>
<regex>(asm-[0-9]+)-([0-9]+.[0-9]+)-([0-9]+)$</regex>
<replacement>$1</replacement>
<failIfNoMatch>false</failIfNoMatch>
</regexPropertySetting>
<regexPropertySetting>
<name>my.version</name>
<value>${tag}</value>
<regex>(asm-[0-9]+)-([0-9]+.[0-9]+)-([0-9]+)$</regex>
<replacement>$1-SNAPSHOT</replacement>
<failIfNoMatch>false</failIfNoMatch>
</regexPropertySetting>
</regexPropertySettings>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.1</version>
<executions>
<execution>
<phase>validate</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<tasks>
<echo>Displaying value of 'my.group' property</echo>
<echo>[my.group] ${my.group}</echo>
<echo>Displaying value of 'my.version' property</echo>
<echo>[my.version] ${my.version}</echo>
</tasks>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>com.xebialabs.xldeploy</groupId>
<artifactId>xldeploy-maven-plugin</artifactId>
<version>6.0.0</version>
<extensions>true</extensions>
<configuration>
<deployables>
<file.Folder name="file">
<scanPlaceholders>false</scanPlaceholders>
<fileUri>http://mynexus.ur/service/local/repositories/my-repo/content/${my.group}/anArtefact/${my.version}/anArtefact-${project.version}.zip</fileUri>
</file.Folder>
</deployables>
</configuration>
</plugin>
</plugins>
</build>
</project>
I'm not quite sure if the build-helper-maven-plugin wrong, or anywhere else in my POM, or if it's simply lack of replacing properties in the xldeploy-maven-plugin...
Thanks for the help ;)

I checked the source of xldeploy-maven-plugin-6.0.1, and it seems it is the limitation of the current implementation.
The problem is that GenerateDeploymentPackageMojo does not rely on maven to do the substitution of the properties. Instead, it uses a custom AbstractConfigurationConverter named DeployitCIConverter (which delegates to MavenDeployableConverter) to convert the <deployables> node to a list of MavenDeployable)
This boils down to:
you have the access to effective POM
you don't have access to properties defined dynamically via build helper plugin
Of course the properties defined dynamically can be acessed in any mojo:
if you use a parameter
if you evaluate them manually via expression evaluator (check: get mojo parameters in maven plugin)
For the antrun plugin, it uses ExpressionEvaluator explicitely in the echo task.
Informative article:
Properties resolution in Maven and its implications on Antrun plugin
Ideas to fix the problem:
do your group and version parsing in external script and pass the values to mvn command.
create a cutom mojo extending GenerateDeploymentPackageMojo and preprocess deployables in the execute method (not that hard as it sounds).

Related

Duplication in maven: are profiles additive to project, or do they replace declared items?

Provided you have the following defined in your POM.xml:
<project>
<!-- ... -->
<build>
<plugins>
<plugin>
<artifactId>plugin-X</artifactId>
<!-- plugin config -->
</plugin>
<plugins>
</build>
<profiles>
<profile>
<id>foo</id>
<build>
<plugins>
<plugin>
<artifactId>plugin-X</artifactId>
<!-- plugin config -->
</plugin>
<plugins>
</build>
<profile>
</profiles>
</project>
If the plugin config for plugin-X is exactly the same for profile foo as it is for a build without a selected profile, do you have to redeclare the plugin at all on the profile level? If so, do you also have to redeclare all config settings for it?
If you declared plugin-Y in project.profile.build.plugins instead of plugin-X (but left it declared on the project level), which plugins would be run when you run mvn -P foo? Only plugin-Y, or also plugin-X?
More generally speaking, are profiles additive to what is declared on the project level, or do they override it? (If they are additive, how do you "remove" entities that were declared on a project level when you run a build profile and don't want them for that specific profile?)
I know profile configuration gets inherited from parent pom files ("from either the build/plugins or pluginManagement sections of the parent") with options "merge", "append", and "override". I think what I really want to know is: how does maven behave when the same/similar information is defined on the project and profile levels in the same pom file...
This isn't a full answer, but another piece of the puzzle - in addition to my earlier comments, and maven's Guide to Configuring Plug-ins.
Given the following pom.xml file:
</profiles>
<properties>
<foo>main</foo>
<bar>main</bar>
</properties>
<build>
<plugins>
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.8</version>
<executions>
<execution>
<phase>validate</phase>
<configuration>
<target>
<echo>${foo}</echo>
<echo>${bar}</echo>
<echo>${baz}</echo>
</target>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
<profiles>
<profile>
<id>p</id>
<properties>
<bar>prof</bar>
<baz>prof</baz>
</properties>
</profile>
</profiles>
</project>
When I run mvn validate, I get the following output:
[echo] main
[echo] main
[echo] ${baz}
Running mvn validate -P p however yields:
[echo] main
[echo] prof
[echo] prof
That means that properties at least are merged, appending new items and replacing those that are redefined.
Also, if I add another plugin to the profile (such as surefire), it will execute when running the profile with mvn <phase> -P p, so the profile inherits antrun and adds surefire. Plugin re-definitions however replace the original; adding
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.8</version>
<executions>
<execution>
<phase>validate</phase>
<configuration>
<target>
<echo>Tada!</echo>
</target>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
only prints Tada!, but no longer the original antrun output (even when changing the new addition's phase to initialize. Adding <inherited>true</inherited> to any of the two plugin definitions doesn't make a difference. The behaviour might be plugin-specific, though.

Cannot use jacoco JVM args and surefire JVM args together in maven

I am using maven with the jacoco plugin to generate code coverage metrics. I am having some difficulty in configuring the surefire plugin with the java options required by the jacoco plugin. I've seen some answers about this already on Stack Overflow but something is not working for me.
I have a multi-module project, and one of my modules configures the surefire plugin as follows:
foo/pom.xml:
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<argLine>-XX:MaxPermSize=512m</argLine>
</configuration>
</plugin>
</plugins>
This works as expected.
Now I want to incorporate jacoco to get code coverage metrics, so I added a CodeCoverage profile that handles all the jacoco configuration:
parent/pom.xml:
<profile>
<id>CodeCoverage</id>
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<executions>
<execution>
<id>jacoco-initialize</id>
<goals><goal>prepare-agent</goal></goals>
<configuration>
<propertyName>surefire.argLine</propertyName>
</configuration>
...
</execution>
<executions>
</plugin>
</plugins>
</pluginManagement>
</build>
</profile>
It is seen here that if the CodeCoverage profile is specified, then the jacoco plugin is configured to use the surefire.argLine property, and that property is used to configure the argLine for the surefire plugin.
I then updated the pom.xml file for the foo module to use the surefire.argLine property generated by the jacoco plugin:
foo/pom.xml:
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<argLine>${surefire.argLine} -XX:MaxPermSize=512m</argLine>
</configuration>
</plugin>
</plugins>
This approach is specified in the jacoco plugin documentation (see [1]).
When I build the foo module with the CodeCoverage profile, I see the following:
[foo] $ mvn clean install -X -PCodeCoverage
...
[INFO] --- jacoco-maven-plugin:0.7.0.201403182114:prepare-agent (jacoco-initialize) # foo ---
[INFO] surefire.argLine set to -javaagent:...\\org.jacoco.agent\\0.7.0.201403182114\\org.jacoco.agent-0.7.0.201403182114-runtime.jar=destfile=...\foo\\\target\\coverage-reports\\jacoco-ut.exec
...
[DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-surefire-plugin:2.13:test' with basic configurator -->
[DEBUG] (s) argLine = -javaagent:...\\org.jacoco.agent\\0.7.0.201403182114\\org.jacoco.agent-0.7.0.201403182114-runtime.jar=destfile=...\\foo\\target\\coverage-reports\\jacoco-ut.exec -XX:MaxPermSize=512m
...
[INFO] --- jacoco-maven-plugin:0.7.0.201403182114:report (jacoco-site) # foo ---
[INFO] Analyzed bundle 'Foo' with 59 classes`
So the jacoco plugin is executed, a surefire.argLine property is created, the argLine for the surefire plugin uses the surefire.argLine property and the local MaxPermSize argument, and a target\code-coverage\jacoc-ut-exec file is generated, as expected.
However, if I do not use the CodeCoverage profile, then I get an error, because the ${surefire.argLine} property (used in foo/pom.xml) is not created by the jacoco plugin, and is not defined anywhere:
[foo] $ mvn clean install -X
...
[DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-surefire-plugin:2.13:test' with basic configurator -->
[DEBUG] (s) argLine = ${surefire.argLine} -XX:MaxPermSize=512m
...
Error: Could not find or load main class ${surefire.argLine}`
Sinec the jacoco plugin was not invoked, there's no surefire.argLine property created, hence the error.
So, I go back to the parent/pom.xml and create this property, with no initial value:
parent/pom.xml:
<properties>
<surefire.argLine></surefire.argLine>
</properties>
Now when I build the foo module without using the CodeCoverage profile, I get no errors:
[foo] $ mvn clean install -X
...
[DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-surefire-plugin:2.13:test' with basic configurator -->
[DEBUG] (s) argLine = -XX:MaxPermSize=512m
...
[INFO] BUILD SUCCESS`
The surefire argline is now correct (using the empty surefire.argLine property) and there is no target\code-coverage directory, as expected.
So now I go back to generating code metrics, using the CodeCoverage profile:
[foo] $ mvn clean install -X -PCodeCoverage
...
[INFO] --- jacoco-maven-plugin:0.7.0.201403182114:prepare-agent (jacoco-initialize) # foo ---
[INFO] surefire.argLine set to -javaagent:...\\org.jacoco.agent\\0.7.0.201403182114\\org.jacoco.agent-0.7.0.201403182114-runtime.jar=destfile=...\\foo\\target\\coverage-reports\\jacoco-ut.exec
...
[DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-surefire-plugin:2.13:test' with basic configurator -->
[DEBUG] (s) argLine = -XX:MaxPermSize=512m
...
[INFO] --- jacoco-maven-plugin:0.7.0.201403182114:report (jacoco-site) # foo ---
[INFO] Skipping JaCoCo execution due to missing execution data file:...\foo\target\coverage-reports\jacoco-ut.exec
It can be observed here that the jacoco plugin is invoked and sets the surefire.argLine property, but the surefire.argLine property with the empty value defined in the parent/pom.xml file is actually used to create the argline for the surefire plugin.
As a result, there is no jacoco-ut.exec file, and no target\code-coverage directory, when I use the CodeCoverage profile.
I'm not sure what I am doing wrong here. I'm declaring an argLine property as suggested by the jacoco documentation, and using it whenever a surefire plugin needs to specify additional argument. Other answers on Stack Overflow suggest creating a property with the same name as the jacoco argLine property to handle the case when jacoco is not invoked.
Any suggestions?
edit
Maybe one solution is to explicitly declare the surefire.argLine property in the CodeCoverage profile, and forget about using the argLine of the jacoco plugin:
<profile>
<id>CodeCoverage</id>
<properties>
<surefire.argLine>-javaagent:${jacoco.agent.jar}=destfile=${jacoco.report.path}</surefire.argLine>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<executions>
<execution>
<id>jacoco-initialize</id>
<goals>
<goal>prepare-agent</goal>
</goals>
<!-- no longer specifying 'argLine' for jacoco plugin ... -->
</execution>
<executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<!-- ... instead the arg line is configured explicitly for surefire plugin. -->
<argLine>${surefire.argLine}</argLine>
</configuration>
</plugin>
</plugins>
</plugin>
</build>
This will create the surefire.argLine property to use the java agent required by the jacoco plugin, and configure the surefire plugin to use that property for its JVM args. The jacoco plugin will now create a argLine property, but this will be ignored. It's not an elegant solution (since I'm making assumptions about how the jacoco plugin works, and this may change in a future version).
edit
The jacoco.agent.jar property must also be set, by pointing to its location in the local repository (not sure if this is robust) or by using the dependency plugin to copy the jacoco agent jar to the local build directory:
<profile>
<id>CodeCoverage</id>
<properties>
<jacoco.agent.jar>${project.build.directory}/jacoco-agent.jar</jacoco.agent.jar>
...
</project>
<build>
...
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>download-jacoco-agent</id>
<phase>process-test-resources</phase>
<goals>
<goal>copy</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>org.jacoco</groupId>
<artifactId>org.jacoco.agent</artifactId>
<version>${jacoco.version}</version>
<classifier>runtime</classifier>
<outputDirectory>${project.build.directory}</outputDirectory>
<destFileName>jacoco-agent.jar</destFileName>
</artifactItem>
</artifactItems>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
edit
Not sure if using the dependency plugin is the right approach, or pointing to the jacoco agent artifact in the local repository:
<profile>
<id>CodeCoverage</id>
<properties>
<jacoco.agent.jar>${settings.localRepository}/org/jacoco/org.jacoco.agent/${jacoco.version}/org.jacoco.agent-${jacoco.version}-runtime.jar</jacoco.agent.jar>
</properties>
...
</profile>
This is simpler, and does not require copying an artifact to the local build directory, but is fragile: changes in the repository layout will break this.
[1] http://www.eclemma.org/jacoco/trunk/doc/prepare-agent-mojo.html
Try using
#{argLine}
instead of
${argLine}
(or surefire.argLine in your case)
It allows surefire to read a property as modified by other plugins instead of reading the one substituted by Maven itself. Then you can set the argLine param to empty in Maven properties:
<properties>
<argLine></argLine>
</properties>
Which now will not cause any problems. More here: How do I use properties set by other plugins in argLine?
Since the jacoco-maven-plugin:prepare-agent goal executes before the maven-surefire-plugin, try adding the ${argLine} variable into the argLine value set by the maven-surefire-plugin.
Example:
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.12.1</version>
<configuration>
<argLine>-server -ea -XX:MaxPermSize=256m -Xmx4g -XX:-UseSplitVerifier ${argLine}</argLine>
</configuration>
</plugin>
I had the same problem and this solution worked for me, without any need to reconfigure other sections of the POM.
If your project already uses the argLine to configure the surefire-maven-plugin, be sure that argLine defined as a property, rather than as part of the plugin configuration. For example:
<properties>
<argLine>-your -extra -arguments</argLine>
</properties>
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<!-- Do not define argLine here! -->
</configuration>
</plugin>
Resulting coverage information is collected during execution and by default written to a file when the process terminates.
Worked for me. See: http://www.eclemma.org/jacoco/trunk/doc/prepare-agent-mojo.html
Try adding the argLine property in the properties section (as shown in the code below) instead of adding it in the configuration section of maven-sure-fire plugin. Jacoco maven plugin will just append to this and things will work as expected.
<properties>
<argLine>-XX:MaxPermSize=512m</argLine>
</properties>
See https://docs.sonarqube.org/display/PLUG/Usage+of+JaCoCo+with+Java+Plugin
My solution is to use multiple profiles.
The first profile sets a blank value for the surefire.argLine and the failsafe.argLine and is active by default.
<profile>
<id>not-sonar</id>
<properties>
<surefire.argLine/>
<failsafe.argLine/>
</properties>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
</profile>
The second profile has the jacoco plugin configuration and is inactive by default.
<profile>
<id>sonar</id>
<activation>
<activeByDefault>false</activeByDefault>
</activation>
<build>
<plugins>
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>${jacoco-maven-plugin-version}</version>
<executions>
<execution>
<id>default-prepare-agent</id>
<goals>
<goal>prepare-agent</goal>
</goals>
<configuration>
<propertyName>surefire.argLine</propertyName>
</configuration>
</execution>
<execution>
<id>default-prepare-agent-integration</id>
<goals>
<goal>prepare-agent-integration</goal>
</goals>
<configuration>
<propertyName>failsafe.argLine</propertyName>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
When you activate the sonar profile the not-sonar profile will automatically be turned off.
This should be a little more elegant than using other plugins to do the work for you. You can now use the ${surefire.argLine} variable in your argLine and it will always exists and be set when you run your build.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<argLine>${surefire.argLine} -XX:MaxPermSize=512m</argLine>
</configuration>
</plugin>
If you still have problems because the ${surefire.argLine} does not have a value you can also set a dummy property like so:
<profile>
<id>not-sonar</id>
<properties>
<surefire.argLine>-DdummyProperty=notUsed</surefire.argLine>
<failsafe.argLine>-DdummyProperty=notUsed</failsafe.argLine>
</properties>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
</profile>
I recently ran into the same issue and even took implicitly the same steps as you described with the same result. No clean solution I found worked for me.
So I ran several steps in debug mode and it seems that Maven replaces properties twice. That is not just in a lazy manner, as I thought, but in both eager and lazy manner:
eagerly (before any goal is run) are replaced static properties (defined in properties section of POM and probably also settings.xml),
lazily (before each execution) are replaced dynamic properties.
This is where our step with setting a blank property as a default failed. Maven just went:
eager replace of default value (blank)
JaCoCo sets dynamic value
lazy replace of dynamic values (nothing to replace now, already used the blank value)
Finally the solution is to set the default value dynamically. This can be done with GMaven plugin like this:
<plugin>
<groupId>org.codehaus.gmaven</groupId>
<artifactId>gmaven-plugin</artifactId>
<version>1.5</version>
<executions>
<execution>
<id>set-default-values</id>
<phase>initialize</phase>
<goals>
<goal>execute</goal>
</goals>
<configuration>
<source>
project.properties.'surefire.argLine' = ''
</source>
</configuration>
</execution>
</executions>
</plugin>
So now Maven goes:
eager replace of static properties
GMaven dynamically sets default value (if profile is active)
JaCoCo sets dynamic value
Surefire runs with correctly set argLine
With active profile the exec file is generated, with non-active profile the blank default value is used and build succeeds.
My solution to use argLine in the maven-surefire-plugin safely.
<plugin>
<groupId>org.codehaus.groovy.maven</groupId>
<artifactId>gmaven-plugin</artifactId>
<version>2.0</version>
<executions>
<execution>
<id>set-custom-arg-line</id>
<phase>validate</phase>
<goals>
<goal>execute</goal>
</goals>
<configuration>
<source>
def argLine = project.properties['argLine'];
if (argLine == null) {
argLine = "";
}
project.properties.argLine = argLine;
</source>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.19.1</version>
<configuration>
<argLine>-Xmx1024m ${argLine}</argLine>
</configuration>
</plugin>
For me upgrading the version from 0.7.7.201606060606 to 0.7.9 also fixed this.
I had to explicitly add the version to the commandline (not just to the pom) because the build server kept using the old verison. This can be done as follows:
org.jacoco:jacoco-maven-plugin:0.7.9:prepare-agent
instead of
org.jacoco:jacoco-maven-plugin:prepare-agent
The jacoco plugin site (for sonar) states that argline must be added as a property. For me it also worken when using the #{argLine} in the surefire plugin settings.
Update the POM.xml as
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>0.7.7.201606060606</version>
<executions>
<execution>
<goals>
<goal>prepare-agent</goal>
</goals>
</execution>
<execution>
<id>report</id>
<phase>prepare-package</phase>
<goals>
<goal>report</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.12.1</version>
<configuration>
<argLine>${argLine} -XX:PermSize=256m -XX:MaxPermSize=1048m</argLine>
</configuration>
</plugin>
and then the most important thing is to run the Maven project with goals:
mvn jacoco:prepare-agent clean test jacoco:report
I have added a Maven/Java project with 1 domain class with the following features:
Unit or Integration testing with the plugins Surefire and Failsafe.
Findbugs.
Test coverage via Jacoco.
I kept the project as simple as possible. The project puts many suggestions from these and other posts together in an example project. Thank you, contributors!
The readme file gives a brief explanation. It explains how you can run either a user or an integration test with Jacoco.
Enjoy!

Maven: set property in pom.xml from properties file

I have multi-module project with a lot of dependencies on different modules versions. At the moment versions are hardcoded and one needs to change them manually. So I decided to put all of them to a properties file and get properties values from it during project build.
Here is how I try to do it:
root pom.xml
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>properties-maven-plugin</artifactId>
<version>1.0-alpha-2</version>
<executions>
<execution>
<phase>initialize</phase>
<goals>
<goal>read-project-properties</goal>
</goals>
<configuration>
<files>
<file>./version.properties</file>
</files>
</configuration>
</execution>
</executions>
</plugin>
file version.properties
module1.version=1.1
module2.version=1.8
module3.version=5.4
example of module pom.xml
<properties>
<module1.project.version>${module1.version}</module1.project.version>
</properties>
<parent>
<groupId>com.mymodule</groupId>
<artifactId>test</artifactId>
<version>${module1.version}</version>
<relativePath>../pom.xml</relativePath>
</parent>
Build fails with:
Failed to execute goal
org.codehaus.mojo:build-helper-maven-plugin:1.7:parse-version
(parse-versions) on project ccm-agent: Execution parse-versions of
goal org.codehaus.mojo:build-helper-maven-plugin:1.7:parse-version
failed. NullPointerException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
execute goal
org.codehaus.mojo:build-helper-maven-plugin:1.7:parse-version
(parse-versions) on project ccm-agent: Execution parse-versions of
goal org.codehaus.mojo:build-helper-maven-plugin:1.7:parse-version
failed.
How can I read some properties from a file and configure pom.xml in correct way?
It appeared to be very simple at the end. I used initialize phase. Changing it to validate fixed the problem:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>properties-maven-plugin</artifactId>
<version>1.0-alpha-2</version>
<executions>
<execution>
<phase>validate</phase>
You must not use properties / variable replacement inside of <parent> elements.
The main reason here is that Maven must read the parent POM before it can start expanding properties since the parent POM might define properties as well.

How to generate classes from wsdl using Maven and wsimport?

When I attempt to run "mvn generate-sources" this is my output :
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building gensourcesfromwsdl 0.0.1-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 0.104s
[INFO] Finished at: Tue Aug 20 15:41:10 BST 2013
[INFO] Final Memory: 2M/15M
[INFO] ------------------------------------------------------------------------
I do not receive any errors but there are no java classes generated from the wsdl file.
Here is my pom.xml file that I'm running the plugin against :
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>gensourcesfromwsdl</groupId>
<artifactId>gensourcesfromwsdl</artifactId>
<version>0.0.1-SNAPSHOT</version>
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jaxws-maven-plugin</artifactId>
<version>1.12</version>
<executions>
<execution>
<goals>
<goal>wsimport</goal>
</goals>
<configuration>
<wsdlLocation>http://mysite/firstwsdl.asmx?wsdl</wsdlLocation>
<packageName>com</packageName>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</pluginManagement>
</build>
</project>
What am I doing wrong ? The package com exists in the project 'gensourcesfromwsdl' and the wsdl location is valid.
When I run wsimport via the command line : >wsimport -keep -verbose http://mysite/firstwsdl.asmx?wsdl the class is generated.
To generate classes from WSDL, all you need is build-helper-maven-plugin and jaxws-maven-plugin in your pom.xml
Make sure you have placed wsdl under folder src/main/resources/wsdl and corresponding schema in src/main/resources/schema, run command "mvn generate-sources" from Project root directory.
C:/Project root directory > mvn generate-sources
generated java classes can be located under folder
target/generated/src/main/java/com/raps/code/generate/ws.
pom.xml snippet
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.9</version>
<executions>
<execution>
<id>add-source</id>
<phase>generate-sources</phase>
<goals><goal>add-source</goal></goals>
<configuration>
<sources>
<source>${project.build.directory}/generated/src/main/java</source>
</sources>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jaxws-maven-plugin</artifactId>
<version>1.12</version>
<configuration>
<wsdlDirectory>${project.basedir}/src/main/resources/wsdl</wsdlDirectory>
<packageName>com.raps.code.generate.ws</packageName>
<keep>true</keep>
<sourceDestDir>${project.build.directory}/generated/src/main/java</sourceDestDir>
</configuration>
<executions>
<execution>
<id>myImport</id>
<goals><goal>wsimport</goal></goals>
</execution>
</executions>
</plugin>
Here is an example of how to generate classes from wsdl with jaxws maven plugin from a url or from a file location (from wsdl file location is commented).
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<build>
<plugins>
<!-- usage of jax-ws maven plugin-->
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jaxws-maven-plugin</artifactId>
<version>1.12</version>
<executions>
<execution>
<id>wsimport-from-jdk</id>
<goals>
<goal>wsimport</goal>
</goals>
</execution>
</executions>
<configuration>
<!-- using wsdl from an url -->
<wsdlUrls>
<wsdlUrl>
http://myWSDLurl?wsdl
</wsdlUrl>
</wsdlUrls>
<!-- or using wsdls file directory -->
<!-- <wsdlDirectory>src/wsdl</wsdlDirectory> -->
<!-- which wsdl file -->
<!-- <wsdlFiles> -->
<!-- <wsdlFile>myWSDL.wsdl</wsdlFile> -->
<!--</wsdlFiles> -->
<!-- Keep generated files -->
<keep>true</keep>
<!-- Package name -->
<packageName>com.organization.name</packageName>
<!-- generated source files destination-->
<sourceDestDir>target/generatedclasses</sourceDestDir>
</configuration>
</plugin>
</plugins>
</build>
Even though this is bit late response, may be helpful for someone. Look like you have used pluginManagement. If you use pluginManagement
, it will not pick the plug-in execution.
It should be under
<build>
<plugins>
<plugin>
Try to wrap wsdlLocation in wsdlUrls
<wsdlUrls>
<wsdlLocation>http://url</wsdlLocation>
</wsdlUrls>
I see some people prefer to generate sources into the target via jaxws-maven-plugin AND make this classes visible in source via build-helper-maven-plugin. As an argument for this structure
the version management system (svn/etc.) would always notice changed
sources
With git it is not true. So you can just configure jaxws-maven-plugin to put them into your sources, but not under the target folder. Next time you build your project, git will not mark these generated files as changed. Here is the simple solution with only one plugin:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jaxws-maven-plugin</artifactId>
<version>2.6</version>
<dependencies>
<dependency>
<groupId>org.jvnet.jaxb2_commons</groupId>
<artifactId>jaxb2-fluent-api</artifactId>
<version>3.0</version>
</dependency>
<dependency>
<groupId>com.sun.xml.ws</groupId>
<artifactId>jaxws-tools</artifactId>
<version>2.3.0</version>
</dependency>
</dependencies>
<executions>
<execution>
<goals>
<goal>wsimport</goal>
</goals>
<configuration>
<packageName>som.path.generated</packageName>
<xjcArgs>
<xjcArg>-Xfluent-api</xjcArg>
</xjcArgs>
<verbose>true</verbose>
<keep>true</keep> <!--used by default-->
<sourceDestDir>${project.build.sourceDirectory}</sourceDestDir>
<wsdlDirectory>src/main/resources/META-INF/wsdl</wsdlDirectory>
<wsdlLocation>META-INF/wsdl/soap.wsdl</wsdlLocation>
</configuration>
</execution>
</executions>
</plugin>
Additionally (just to note) in this example SOAP classes are generated with Fluent API, so you can create them like:
A a = new A()
.withField1(value1)
.withField2(value2);
The key here is keep option of wsimport. And it is configured using element in
About keep from the wsimport documentation :
-keep keep generated files
i was having the same issue while generating the classes from wsimport goal. Instead of using jaxws:wsimport goal in eclipse Maven Build i was using clean compile install that was not able to generate code from wsdl file. Thanks to above example.
Run jaxws:wsimport goal from Eclipse ide and it will work

Plugin.xml configuration of phase doesn't seem to work for my custom maven plugin

I'm playing around with writing a maven plugin for the first time. I've written a simple plugin with a goal that writes a hello world message to the output. I've also used the #phase annotation to create a default binding to the install lifecycle phase. This shows up in my plugin.xml as install element of my mojo element.
My understanding is that I can now simply add this to my build.plugins section, without specifying any execution, and my plugin goal will execute during the install phase. This doesn't happen though. Here's the configuration that doesn't create any exeuction of my goal:
<build>
<plugins>
<plugin>
<groupId>com.emc.chad</groupId>
<artifactId>hello-plugin</artifactId>
<version>0.0.1-SNAPSHOT</version>
</plugin>
</plugins>
</build>
However, if I change this to specify an execution explicitly, it works:
<plugin>
<groupId>com.emc.chad</groupId>
<artifactId>hello-plugin</artifactId>
<version>0.0.1-SNAPSHOT</version>
<executions>
<execution>
<id>test</id>
<phase>install</phase>
<goals>
<goal>hello</goal>
</goals>
<configuration>
</configuration>
</execution>
</executions>
</plugin>
I understand why this works of course, but shouldn't the first work as well, considering my plugin.xml phase specification?

Resources