I am using the 2.7.4 version of the Spring Boot Maven plugin, and am puzzled about the behavior of arguments set in the pom.xml. Once there, it seems they cannot be overriden by specifying some on the command line.
According to the documentation
Arguments from the command line that should be passed to the application. Use spaces to separate multiple arguments and make sure to wrap multiple values between quotes. When specified, takes precedence over #arguments.
If I have this in my pom.xml:
<configuration>
<arguments>
<argument>--oh_hello=there</argument>
</arguments>
</configuration>
Then I cannot override this by for example using mvn spring-boot:run -Dspring-boot.run.arguments="--hello=world".
The arguments seen when the Spring applications starts are stuck at what is specified in pom.xml. I expect to be able to override this. Am I misunderstanding, or is this a bug?
Full example on GitHub.
As counter-intuitive as it may seem, it's conventional for a Maven plugin to behave in this way, with configuration in the pom.xml taking precedence over command-line configuration.
The reference documentation for Spring Boot's Maven plugin recommends using a project property to allow a setting to be configured on the command line. In your case, that would look something like this:
<properties>
<run.arguments>--hello=there</run.arguments>
</properties>
<configuration>
<arguments>
<argument>${run.arguments}</argument>
</arguments>
</configuration>
mvn spring-boot:run -Drun.arguments="--hello=world"
Related
While executing a phase everything works as expected, when I try to call a plugin (mojo) directly like
mvn net.masterthought:maven-cucumber-reporting:5.5.0:generate
maven seems to ignore <configuration></configuration> block of the plugin specified in pom.xml. And if a parameter of the plugin is required, maven obviously fails as it thinks it is not set (did you try to look at your pom.xml, dear maven?). Is this by designed or I misunderstand something?
I guess you have put the <configuration> into an <execution> block.
If this is the case, move it out of <executions>.
I'm getting ArrayStoreException: TypeNotPresentExceptionProxy when running integration-test with maven-failsafe-plugin and spring-boot 1.4.
You can see this error if you run joinfaces-example with
mvn -Pattach-integration-test clean install
I realized that the error does not occur if I change spring-boot-maven-plugin to run at pre-integration-test phase instead of package one.
More, this error started when I upgraded spring boot to 1.4. No error occurs if I change jsf-spring-boot-parent version to 2.0.0 which uses spring boot 1.3 version.
I actually found the answer in Spring Boot 1.4 release notes, short answer is that maven-failsafe-plugin is not compatible with Spring Boot 1.4's new executable layout. Full explanation below :
As of Failsafe 2.19, target/classes is no longer on the classpath and
the project’s built jar is used instead. The plugin won’t be able to
find your classes due to the change in the executable jar layout.
There are two ways to work around this issue:
Downgrade to 2.18.1 so that you use target/classes instead
Configure the spring-boot-maven-plugin to use a classifier for the
repackage goal. That way, the original jar will be available and used
by the plugin. For example :
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<classifier>exec</classifier>
</configuration>
</plugin>
An alternative is documented here: https://github.com/spring-projects/spring-boot/issues/6254
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-failsafe-plugin</artifactId>
<!--
Make failsafe and spring-boot repackage play nice together,
see https://github.com/spring-projects/spring-boot/issues/6254
-->
<configuration>
<classesDirectory>${project.build.outputDirectory}</classesDirectory>
</configuration>
</plugin>
This worked better for me, because when I used the "exec" solution, Spring failed to find my configuration files when starting the container. Which could probably be fixed by adding some further configuration parameters, I suppose, but this solution works "out of the box" for me.
Is there a way to specify which SpringBootApplication's main class to run when running mvn spring-boot:run? The docs say I can use mainClass parameter to specify which main class to run. But I am not sure how to specify it in command line. I have tried mvn -DmainClass=mypackage.myclass spring-boot:run but it didn't work.
I got it working by having a placeholder in the plugin configuration of spring-boot
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<mainClass>${mainclass}</mainClass>
</configuration>
</plugin>
and then running different classes
mvn -Dmainclass=mypackage.myclass spring-boot:run
Two answers to your question
You have to create a MANIFEST.MF file in src/main/resources/META-INF/MANIFEST.MF and give an attribute like this as given below
Main-Class= com.yourfilename
You can use maven jar plugin to define main-class configuration in your manifest file, please use this links below which will help you.
link 1
link 2
For example, I want to use the Wildfly deploy plugin, as outlined here:
http://docs.jboss.org/wildfly/plugins/maven/latest/deploy-artifact-mojo.html
To deploy, I would use a command like mvn wildfly:deploy -Dfilename=my.ear. But let's say I want to deploy to a particular server group. Using a POM, I would add:
<plugin>
<groupId>org.wildfly.plugins</groupId>
<artifactId>wildfly-maven-plugin</artifactId>
<version>1.1.0.Alpha1</version>
<configuration>
<domain>
<server-groups>
<server-group>main-server-group</server-group>
</server-groups>
</domain>
</configuration>
</plugin>
But if I can't change the POM, how would I pass this configuration in on the CLI or in $HOME\.m2\settings.xml?
The usage page indicates a configuration "type" of org.wildfly.plugin.deployment.domain.Domain for a "domain" option but I don't know how to type those options out on the CLI. Obvious answers like -Ddomain.server-groups.server-group=my-server-group don't seem to work.
If you could change the pom using a property like <server-group>${server.group}</server-group> should work. I don't think maven has support for complex attribute properties like that.
If that's not possible you could file a feature request.
Not exactly the answer to the overall question, but to your specific problem.
Changing the version in the pom to 1.2.2.Final, you can now do:
-Dwildfly.serverGroups=main-server-group
which I guess wasn’t available in 1.1.0.
I'm looking for a way to update pom property to given value, i.e. my pom.xml contains:
<properties>
<abc.def>aaaaa</abc.def>
<properties>
now i want to call :
mvn some_plugin:some_goal -Dabc.def=XYZ
and finally my pom.xml should looks like
<properties>
<abc.def>XYZ</abc.def>
<properties>
I was reading about maven-release-plugin & versions-maven-plugin but i do not see there any matching goal.
Thank you in advance for any reply.
mvn versions:update-properties -Dproperties=[XYZ] -DincludeProperties={abc.def}
Read more here.
and here.
In short:
In versions-maven-plugin, the update-properties goal sets properties to the latest versions of specific artifacts.
includeProperties is a comma separated list of properties to update.
properties are any restrictions that apply to specific properties.
The accepted answer does not work for arbitrary values since it performs sanity checks (links to the documentation for set-property goal since for some reason the documentation for update-properties does not mention this).
To set some arbitrary value on a property use set-property since - as documented - it skips sanity checks:
mvn versions:set-property -Dproperty=your.property -DnewVersion=some_value
Ok, i found some case of solution. I'm using maven-replacer-plugin where:
my properties definition in pom.xml :
<properties>
<abc.def>aaaaa</abc.def>
<properties>
my plugin configuration :
<plugin>
<groupId>com.google.code.maven-replacer-plugin</groupId>
<artifactId>replacer</artifactId>
<version>1.5.2</version>
<configuration>
<file>pom.xml</file>
<replacements>
<replacement>
<token>${abc.def}</token>
<value>${replacer.abc.def}</value>
</replacement>
</replacements>
</configuration>
</plugin>
and finally my maven invocation :
mvn replacer:replace -Dreplacer.abc.def=XYZ
It works for me but I don know is there any better way to achieve it with maven-relase-plugin and/or versions-maven-plugin as #khmarbaise and #Conan said.
I agree with #khmarbaise above, the versions-maven-plugin will do just this, or you could move to the Maven Release Plugin if you want a much heftier approach to managing your versions, but you could also just run a script to sed the pom.xml file using Jenkins' BUILD_NUMBER environment variable, which is a quicker and dirtier approach.