I have following properties in pom.xml file :-
<properties>
<cm_java_home>C:/Java/jdk1.8.0-102/bin</cm_java_home>
</properties>
But, I need to change this during building job from Jenkins, and it should look like as given below:-
<properties>
<cm_java_home>/home/abc/Java/jdk-1.8.0-102/jre</cm_java_home>
</properties>
How to modify my properties tag in pom.xml file using Jenkins job configuration ?
Simply, to modify any property of pom.xml file, use -D=value.
For instance, in my case,
I used the following:-
mvn clean install -Dcm_java_home="/home/abc/Java/jdk1.8.0_102/jre"
Related
I have created my own archetype which defines in archetype-metadata.xml a required property:
<requiredProperty key="version.wildfly">
<defaultValue>16.0.0.Final</defaultValue>
</requiredProperty>
This property needs to be used in src/main/resources/archetype-resources/pom.xml as a property:
<properties>
<version.server.bom>${version.wildfly}</version.server.bom>
</properties>
Indeed, when I create a project using this archetype, I'm being asked to confirm the default value for the property:
version.wildfly: 16.0.0.Final
Y: : Y
However, in the generated project's pom.xml, it is not specified anywhere to use this property. The pom.xml merely contains:
<properties>
<version.server.bom>${version.wildfly}</version.server.bom>
</properties>
And thus the build fails. Did I use any wrong pattern to inject the property in the pom.xml ?
Thanks
Don't use dot, try version-wildfly.
looks like archetype consider dot-split property as internal use. see Custom Properties
There is some profiles defined in pom.xml.
<profile>
<id>test</id>
<properties>
<env>test</env>
</properties>
</profile>
spring.profiles.active: #env# defined in application.yml and bootstrap.yml.
When I run mvn install -P test, text #env# in application.yml would be replaced by test.
How does it work?
Why it does't work for bootstrap.xml?
It works for application.yml because you are obviously using the Spring Boot Starter Parent. See the POM here: https://github.com/spring-projects/spring-boot/blob/master/spring-boot-project/spring-boot-starters/spring-boot-starter-parent/pom.xml
The magic part is the <resources> configuration within that parent POM. You see that the application config files are explicitly copied with filtering. That is why the maven-resources-plugin resolves placeholders in these files.
If you want to add more files to be handled like this you can add your own <resources> section to your POM and extend it by more file patterns.
How can use two Maven profiles with for example <id = env>that will contain id, password, account# that will pass those values into .java class and in Maven command line I just run something like:
mvn test ${env=stage}
and it will take id, password, account# from profile that I choose. Or may be there are other way to do that not using profiles?
In general, you can declare properties in Maven. You can set them in different ways:
Command line:
mvn ... -DmyProperty=myValue
In a <properties> section in a POM or in settings.xml (in the latter in a <profile> section only) like:
<profile>
<id>stage</id>
<properties>
<user>you</user>
<password>your</password>
<accountNo>42</accountNo>
</properties>
<profile>
Activate profiles on the command line with:
mvn ... -Pstage ...
or use one of the other activation mechanisms described in the doc Maven, Introduction to Build Profiles.
Use properties in your POM with ${user}, ${password}, ${accountNo}.
This is the snippet of pom.xml from my project.
<properties>
<Port>2020</Port>
<threads>20</threads>
<test.suite />
<test.suite.path />
<useTag />
<useTestCase />
<args>-Dthreads=${threads} -Dtest.suite.path=${test.suite.path} -Dappenv=${test.app.env} -Dtest.suite=${test.suite} -DuseTag=${useTag} -DuseTestCase=${useTestCase}</args>
</properties>
when maven build is made, I am wondering how the variables test.suite, test.suite.path, useTestCase are set? I do not see it anywhere in the pom. but the Jenkins build is working fine and it has substituted values for these placeholders.
what is the use of using this kind of property setting. <variable/> rather than <variable>...</variable> ?
To say exactly how those properties are set in your case we need to see the entire pom structure including the parent pom(s) as well as your Jenkins job configuration.
However, I know of two ways that these properties can be set:
Through a profile in one of your parent poms
Through system properties when maven is invoked
My guess is that you have a profile in one of your parents that sets these properties. Something like this:
<profile>
<id>jenkins</id>
<properties>
<test.suite>...</test.suite>
...
</properties>
</profile>
And that this profile is activated on your Jenkins server. Look here for information how the profile can be activated.
The other option is that these properties are specified as system properties when maven is invoked from Jenkins.
As for why <variable/> is used over <variable></variable> it is a matter of taste. <variable/> means the same thing as <variable></variable> in XML.
I want to read a maven variable for configure a build plugin from a properties file. It's not needed in and further project files e.g. context files.
1) made a profile (it works, can use mvn ... -P private)
<profile>
<id>private</id>
<properties>
<env>private</env>
</properties>
</profile>
2) created the filter file with this content (it works)
foo.path=/home/foo/path
3) try to configure the plugin (does not work)
<build>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>foo-plugin</artifactId>
<version>${foo-plugin.version}</version>
<configuration>
<!--<fooPath>home/foo/path></fooPath> that works -->
<fooPath>${foo.path}</fooPath> <!--works not -->
</configuration>
...
</build>
Thx a lot
The name of your property is 'env' but you don't use env anywhere in your configuration.
When Maven docs mention "filter files" they usually mean a file used when processing resources (i.e. copying resources from /src/main/resources to target/classes). As far as I know the properties in those files aren't used for plugin configuration out-of-the-box. I have used the Codehaus properties-maven-plugin:read-project-properties goal do do what you are attempting. Make sure you bind the goal to the lifecycle before any plugins that need the properties for config.
Also, see this answer; you may load properties used to configure other plugins, but not to configure core Maven project elements.