We Keep Coding

Set VM option from maven config

Is there any way to set an argument for the command line from the maven config? Maybe some plugin?
I need to run my service on spring boot with the following VM option:
-Dspring.config.additional-location=classpath:/config/business-config.yml
I have tried using maven-surefire-plugin:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<argLine>
-Dspring.config.additional-location=classpath:/config/business-config.yml
</argLine>
</configuration>
</plugin>
and spring-boot-maven-plugin:
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<jvmArguments>
-Dspring.config.additional-location=classpath:/config/business-config.yml
</jvmArguments>
</configuration>
</plugin>
But that doesn't work for me. I test by running my maven project locally from IDEA Intellij as a Spring Boot application. If I set this option in IDEA configuration then it works properly.
Any ideas why?

Maven is a build tool, not a runtime environment.
For the simplest see The java Command:
java ... -Dproperty=value ...
Sets a system property value. The property variable is a string with no spaces that represents the name of the property. The value variable is a string that represents the value of the property. If value is a string with spaces, then enclose it in quotation marks (for example -Dfoo="foo bar").
Otherwise the container your application is running in has to have a possibility to configure java command line parameters.

What does a Maven Artifact means in a context of runnable jar project? [duplicate]

I have a project that consist of 3 different libraries. When I run install script it takes all libraries from repo and run mvn clean install on them. But this version of library already installed in repo. Is there a way to skip install phase if version in pom.xml equal version in my local repo.
I know that I can use local repo and just set dependencies. But my boss want that our project can build only with public repos and without any our repos.

You can bypass like this
-Dmaven.install.skip=true
<profiles>
<profile>
<id>skipInstall</id>
<activation>
<property>
<name>maven.install.skip</name>
<value>true</value>
</property>
</activation>
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-install-plugin</artifactId>
<executions>
<execution>
<id>default-install</id>
<phase>none</phase>
</execution>
</executions>
</plugin>
</plugins>
</pluginManagement>
</build>
</profile>
Last week Olivier Lamy patched this jira.
MINSTALL-73

Most maven plugins can be skipped by specifying something like:
<plugin>
<artifactId>maven-install-plugin</artifactId>
<version>X.Y</version>
<configuration>
<skip>true</skip>
</configuration>
</plugin>
you can also set up build profiles to set properties and use that to determine the value. for example, running the command: mvn -Pexample would select the "example" profile. The POM would then contain:
...
<properties>
<skip.install>false</skip.install>
...
</properties>
...
<profile>
<id>example</id>
<properties>
<skip.install>false</skip.install>
</properties>
</profile>
...
<plugin>
<artifactId>maven-install-plugin</artifactId>
<version>X.Y</version>
<configuration>
<skip>${skip.install}</skip>
</configuration>
</plugin>
...
Using these POM additions, the default behavior for the install plugin will be to perform its default goal, but if the example profile is selected, then the install plugin will skip its goal.

Using what I learned from the other answers, this was the cleanest result for me.
In my super pom I added a pluginManagement/plugin to disable default-install and default-test phases when the property deployOnly is set.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-install-plugin</artifactId>
<version>2.5.2</version>
<executions>
<execution>
<id>default-install</id>
<configuration>
<skip>${deployOnly}</skip>
</configuration>
</execution>
<execution>
<id>default-test</id>
<configuration>
<skip>${deployOnly}</skip>
</configuration>
</execution>
</executions>
</plugin>
So on the command line, I can disable install and test phases by adding -DdeployOnly.
mvn clean install #build and test everything
mvn deploy -DdeployOnly #just deploy it

I know that I can use local repo and just set dependencies. But my boss want that our project can build only with public repos and without any our repos.
Are you sure you understood correctly what you boss meant? I interpret the above as "don't install third party libraries in your local repository, use only libraries available in public repositories". This is different from "don't use your local repository" which is basically impossible, that's just not how maven works. I'd try to clarify this point.
Apart from that, I don't get the question which is very confusing (what repo are you talking about? What is the install script doing? Why do you call clean install on libraries? etc).

Extending the other answers, from the future.
Maven plugins have a surprisingly high freedom, how do they run. If they want, they can ignore/override the typical pom.xml settings. Furthermore, also the <configuration><skip>true</skip></configuration> is only a convention, nothing obligates a plugin to follow it, except that most of them is developed so.
My experiments with the recent problem show, that both #Cemo's and #MiloshBoroyevich solution should be utilized, also the plugin requires both to really let us in peace. More concretely, the only working configuration by me was this:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-install-plugin</artifactId>
<version>2.5.2</version>
<executions>
<execution>
<id>default-install</id>
<phase>none</phase>
</execution>
</executions>
<configuration>
<skip>true</skip>
</configuration>
</plugin>

One of your options is to put the deployment to another module. I.e. have one pom.xml build the artifact and install it to the local repo, and another pom.xml to deploy it. This separation is quite common in larger projects, where the testsuite is sometimes a separate module or even a project, the packaging happens in several stages, etc.
- pom.xml - myProject-root - type=pom
- pom.xml - myProject-artifact - type=jar
- pom.xml - myProject-deploy - type=pom, does the deployment, skips it's own `install` goal

How to get argLine to work in maven surefire plugin

I'm having difficulty trying to add an argument to the jvm. It looks like using surefire is the only way to do this. My current code in the pom.xml is
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.19</version>
<configuration>
<argLine>-Xmx512m</argLine>
<systemPropertyVariables>
<all.clusters>${all.clusters}</all.clusters>
<branding.token>${brandingToken}</branding.token>
</systemPropertyVariables>
</configuration>
</plugin>
Maven is new to me so perhaps I'm missing something simple.
Running in a Netbeans 8.1 environment.

Turns out that what I needed to do was not to get surefire to run with special arguments, because that only covers tests. The trick to getting it working was the fact that this project is a NetBeans application which uses the
nbm-maven-plugin.
The following blog post describes how to modify the arguments.
Blogpost

mvn checkstyle:checkstyle uses wrong configuration when using reporting

Im facing the following problem. I have set up my checkstyle with the following configuration:
<reporting>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<version>${checkstyle.plugin.version}</version>
<inherited/>
<configuration>
<configLocation>${basedir}/checkstyle.xml</configLocation>
<includeTestSourceDirectory>true</includeTestSourceDirectory>
</configuration>
</plugin>
</plugins>
</reporting>
This runs fine when I run mvn site. However, when I run checkstyle through mvn checkstyle:checkstyle in order to get the XML report much more efficiently, the checkstyle plugin fails back to use the default configuration. When I move the plugin to <build> the XML is generated properly, but now the checkstyle report is not included in the generated site anymore.
What is the (current) way of setting up report plugins as Checkstyle, while perserving the ability to run the plugin separately under the same configuration?
Is it really the preferred way to defined your plugins and configuration twice?

Okay, apparently you should add the plugin with configuration to both <build> and <reporting>.

Integrating Maven reporting plugins

I need to setup Maven plugins. I have downloaded the JARs. Can anyone please tell me what do I do next in order to integrate or setup the plugins with Maven?
Should I copy the JARs into the parent directory or do I need to edit any file?
The plugins are:
Java2HTML
JDepend
Checkstyle
Clover
Cobertura
EMMA
Findbugs
JavaNCSS
PMD
QALab
Xradar
Sonar

If Maven has access to the central repository it will download most plugins (some are not hosted on central, to access those you need to define an additional repository in your pom or settings).
If the dependencies are configured in your POM, Maven will automatically attempt to download them when you run a relevant goal. For the dependencies you listed this is mvn site.
The majority of those jars you've listed are reports, so should be declared in the reporting section of the POM, for example (I would also declare the versions to be sure you're getting the expected plugin):
<reporting>
<plugins>
<plugin>
<artifactId>maven-checkstyle-plugin</artifactId>
</plugin>
<plugin>
<artifactId>maven-pmd-plugin</artifactId>
<configuration>
<linkXref>true</linkXref>
</configuration>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>cobertura-maven-plugin</artifactId>
<version>2.1</version>
<configuration>
<formats>
<format>html</format>
<format>xml</format>
</formats>
<outputDirectory>target/site/cobertura</outputDirectory>
</configuration>
</plugin>
<plugin>
<artifactId>maven-surefire-report-plugin</artifactId>
<configuration>
<outputDirectory>${basedir}/target/surefire-reports</outputDirectory>
</configuration>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jdepend-maven-plugin</artifactId>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>findbugs-maven-plugin</artifactId>
<configuration>
<xmlOutput>true</xmlOutput>
<effort>Max</effort>
</configuration>
</plugin>
</plugins>
</reporting>
Some background on Maven's plugin execution model:
When you run mvn site, this is short hand for "run the site goal from the latest version of the site plugin", i.e. it is equivalent to mvn site:site, which is in turn shorthand for mvn org.apache.maven.plugins:maven-site-plugin:LATEST:site
Maven will attempt to contact the central repository, determine the LATEST version from the maven-metadata.xml, then download it (and any of its dependencies that are also missing) before executing it.
If you are behind a proxy you may see an error message in your build log like this:
[INFO] The plugin 'org.apache.maven.plugins:maven-site-plugin' does not exist or no valid version could be found
To address this you can declare proxy settings in your Maven settings.xml (in [MVN_HOME]/conf/settings.xml). They are commented out by defualt, but look something like this:
<proxy>
<id>optional</id>
<active>true</active>
<protocol>http</protocol>
<username>proxyuser</username>
<password>proxypass</password>
<host>proxy.host.net</host>
<port>80</port>
<nonProxyHosts>local.net,some.host.com</nonProxyHosts>
</proxy>
Replace the username, password, host, and port values with the relevant for your environment and Maven will be able to download the required dependencies.
For more details on using Maven, check out the Maven: The Definitive Guide by Sonatype, it is online and free.

Sirakov is right; Maven will download and install the plugins automatically when they are used.
You can either run them directly (for one-off jobs), or configure them in your pom.xml - this also allows you to configure then, and set the to run automatically, for example, to generate source code or report on test coverage. A major advantage of this is that you can define a single set of plugin configs in a shared parent pom, and reuse the same configurations across across all your projects, while still being able to override the inherited configuration in each subproject where necessary - this is one of the biggest advantages of using Maven on larger projects.
Each plugin has its own configuration parameters, the standard ones are documented at http://maven.apache.org/plugins/. Another good resource is the O'Reilly Maven book, online at http://www.sonatype.com/books/maven-book/reference/
An example configuration for cobertura:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-pmd-plugin</artifactId>
<version>2.3</version>
<configuration>
<outputDirectory>${project.build.directory}/pmd</outputDirectory>
<targetDirectory>${project.build.directory}</targetDirectory>
<aggregate>true</aggregate>
<!-- CPD minimum tokens to report on (5 to 10 duplicate lines) -->
<minimumTokens>100</minimumTokens>
<minimumPriority>3</minimumPriority>
<!-- Exclude mock classes -->
<excludes>
<exclude>**/Mock.*</exclude>
<exclude>**/Dummy.*</exclude>
<exclude>**/*Mock.java</exclude>
<exclude>**/*Dummy.java</exclude>
</excludes>
<includeTests>true</includeTests>
<targetJdk>1.5</targetJdk>
<rulesets>
<ruleset>pmd_ruleset.xml</ruleset>
</rulesets>
</configuration>
</plugin>

You don't need to download the plugins manually. I'm not 100% sure, but if you want to use for example the checkstyle plugin, you need to start maven with checkstyle parameter form command line
something like:
mvn checkstyle:checkstyle
or
mvn checkstyle:check
edit1: But you can also put the jars into the local m2 repository with the specific folder structure to access them.
edit2: you can put all your plugins into your own repository and then you need to tell maven (using the pom), which repositories you want to use. Every plugin must be described in the pom.