Can maven exec:java be used with an arbitrary java class from the command iine - maven

We have a few java/scala classes with main methods that would be useful to run via mvn exec:java.
Is it possible to do so without specifying the classes in the pom.xml? The examples that I have seen look like this:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.1</version>
<executions><execution>
<goals><goal>java</goal></goals>
</execution></executions>
<configuration>
<mainClass>some.main.MyClass</mainClass>
</configuration>
</plugin>
And then get executed as:
mvn exec:java -Dexec.mainClass="some.main.MyClass"
The intent is to be able to run
mvn exec:java -Dexec.mainClass="some.other.main.OtherClass"
even though it were not specified in the pom.xml.
When attempting to run that the error is
[ERROR] Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.6.0:java (default-cli) on project sentiment: An exception occured while executing the Java class. myapp.MyMain
In other words the class specified on the command line is ignored in favor of the one listed in the pom.xml.

The Documentation at https://www.mojohaus.org/exec-maven-plugin/usage.html
says:
If you want to execute Java programs in the same VM, you can either
use the command line version
mvn exec:java -Dexec.mainClass="com.example.Main" [-Dexec.args="argument1"]
This works without adding anything to your pom.
As written in the comment, this only works, if you don't have a configuration in your pom. If you do have a configuration in your pom, you can use a property in it, which can be overridden from the command line
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.1</version>
<executions><execution>
<goals><goal>java</goal></goals>
</execution></executions>
<configuration>
<mainClass>${my.mainClass}</mainClass>
</configuration>
</plugin>
and predefine the property (nested directly in <project>)
<properties>
<my.mainClass>some.main.MyClass</my.mainClass>
</properties>
then you can run with
mvn exec:java -Dmy.mainClass="aaa.Test"

Looking from your usage if you are using the -Dexec.mainClass everytime, i would suggest you can get rid of the mainClass in the plugin configuration. The benefit of defining the mainClass would be to run like : mvn exec:java & it picks the main class from your defined class in pom.xml.
Once you remove the mainClass from pom.xml, you should be able to use any mainClass in the maven exec plugin usage from command line.

Related

Maven : Child pom's argline is not applied?

I have a multi-module maven project. In the child module, failsafe plugin is used for the integration tests run. Some argLines are defined accordingly :
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-failsafe-plugin</artifactId>
<configuration>
<skipAfterFailureCount>1</skipAfterFailureCount>
<argLine>-Xmx2048M -Xss512M -XX:+CMSClassUnloadingEnabled -XX:+UseConcMarkSweepGC</argLine>
</configuration>
</plugin>
The problem is when I run the tests as mvn test or mvn integration-test, the arglines are not applied for the tests from neither the parent pom directory nor the child pom directory, but if I run the tests as mvn failsafe:integration-test from both of the directories, the arglines param are applied.
What is the reason behind this ? Is there any way to apply those params when I run the tests with mvn test command ? I tried to pass the parameters via command line as mvn test -Dchild.argline="-Xmx2048M -Xss512M -XX:+CMSClassUnloadingEnabled -XX:+UseConcMarkSweepGC"
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-failsafe-plugin</artifactId>
<configuration>
<skipAfterFailureCount>1</skipAfterFailureCount>
<argLine>${child.argline}</argLine>
</configuration>
</plugin>
But it didn't work.
Also I tried to bind test and integration-test phases to failsafe integration-test and defined configuration params there, but it didn't work as well..
I set the MAVEN_OPTS accordingly but it didn't help...
The failsafe plugin goals are not included in the lifecycle by default. The POM configuration must include it. See this SO answer for an example. Also ensure that the plugin definition is in the <plugins> section, not inside a <pluginManagement> element.
As for how to define options in the POM - use the names supplied in the documentation. So, to specify argLine, add
<argLine>...</argLine>
in the plugin config. To specify on the command line, note that "User property" for the value you want to set. For the failsafe plugin's argLine, the user property is also argLine, so on the command line specify
-DargLine=...
Maven knows nothing about child.argline so silently ignores it. Also note, attribute and user property names are case sensitive.

Running multiple SpringBootApplication classes from a single maven project

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

Maven + AspectJ/SpringAOP + Lombok + Surefire = test broken in a specific scenario

I have an interesting problem in a project where all of the technologies mentioned in the title are used. I've been able to track it down up to the diagnosis (the test classpath prepared by Surefire), but I don't understand whether it can be fixed and how. It's not a showstopper, indeed it's a minor issue for me, but I'd like to solve it anyway.
First a rough description.
The problem is related to executing tests in a specific module of the project, and only in a specific way.
Everything works (tests pass) when I run from the master pom level:
cd ${projHome}
mvn install
Everything works (tests pass) when I run:
cd ${projHome}/modules/CoreImplementation/
mvn test
That means that I can build and test with no problems, the same for my Jenkins, and NetBeans can run tests from the IDE when I need them.
But that module fails testing when I run from the master pom level:
cd ${projHome}
mvn test
with this error:
java.lang.NoSuchMethodError: it.tidalwave.northernwind.profiling.RequestProfilerAspect.aspectOf()Lit/tidalwave/northernwind/profiling/RequestProfilerAspect;
at it.tidalwave.northernwind.frontend.ui.spi.DefaultSiteViewController.processRequest(DefaultSiteViewController.java:82) ~[classes/:na]
at it.tidalwave.northernwind.frontend.ui.spi.DefaultSiteViewControllerTest.must_call_some_RequestProcessors_when_one_breaks(DefaultSiteViewControllerTest.java:161) ~[test-classes/:na]
Running mvn test as a second pass (after a mvn install -DskipTests) happens to be the way Drone.io and Travis do their job. While I could change their configuration, I'd like to stay with the standard configuration and fix the problem if possible.
The diagnosis in short and my question.
Now, the question in short (details are further below). I was able to track down the problem to different ways in which Surefire prepares the classpath to execute the tests.
When I run mvn install the classpath is:
${repo}/org/apache/maven/surefire/surefire-booter/2.16/surefire-booter-2.16.jar
${repo}/org/apache/maven/surefire/surefire-api/2.16/surefire-api-2.16.jar
${projHome}/modules/CoreImplementation/target/test-classes
${projHome}/modules/CoreImplementation/target/classes
${projHome}/modules/Core/target/it-tidalwave-northernwind-core-1.1-ALPHA-37-SNAPSHOT.952b0c8bdc77.jar
${repo}/it/tidalwave/thesefoolishthings/it-tidalwave-role/3.0-ALPHA-1/it-tidalwave-role-3.0-ALPHA-1.jar
${projHome}/modules/Profiling/target/it-tidalwave-northernwind-core-profiling-1.1-ALPHA-37-SNAPSHOT.952b0c8bdc77.jar
${repo}/org/apache/commons/commons-math3/3.0/commons-math3-3.0.jar
…
When I run mvn test (from the project home) the classpath is:
${repo}/org/apache/maven/surefire/surefire-booter/2.16/surefire-booter-2.16.jar
${repo}/org/apache/maven/surefire/surefire-api/2.16/surefire-api-2.16.jar
${projHome}/modules/CoreImplementation/target/test-classes
${projHome}/modules/CoreImplementation/target/classes
${projHome}/modules/Core/target/unwoven-classes
${repo}/it/tidalwave/thesefoolishthings/it-tidalwave-role/3.0-ALPHA-1/it-tidalwave-role-3.0-ALPHA-1.jar
${projHome}/modules/Profiling/target/unwoven-classes
${repo}/org/apache/commons/commons-math3/3.0/commons-math3-3.0.jar
…
The different portions are the indented ones. In the former case, SureFire uses the classes directory (forget for a moment that in my case they are named unwoven-classes) only for the module under test, and the installed jar files for every dependency. In the latter case, it seems to be using classes for all dependencies in the reactor.
The reason for which this difference in the classpaths gives me troubles is explained below in the "Gory details" section. In short, that unwoven means that they contain bytecode not augmented by AspectJ, hence the methods that can't be found at runtime.
I'm running with SureFire 2.16, but I've also tried the latest 2.19 with no changes. Being able to force SureFire to always use jar files for dependencies would fix my problems. If you have the answer, you can stop reading my post here.
Gory details (just for curiosity).
The faulty module artifactId is it-tidalwave-northernwind-core-default and it depends on aspects available in it-tidalwave-northernwind-core-profiling - that's where the offending RequestProfilerAspect is. The aspect library dependency is both in the regular dependencies of the faulty module and in the configuration of the aspectj plugin:
<dependency>
<groupId>it.tidalwave.northernwind</groupId>
<artifactId>it-tidalwave-northernwind-core-profiling</artifactId>
</dependency>
...
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>aspectj-maven-plugin</artifactId>
<configuration>
<aspectLibraries combine.children="append">
<dependency>
<groupId>it.tidalwave.northernwind</groupId>
<artifactId>it-tidalwave-northernwind-core-profiling</artifactId>
</dependency>
</aspectLibraries>
</configuration>
</plugin>
</plugins>
</build>
AspectJ integration is by means of the following profile in a Super POM, which is activated in the build, whose relevant part is:
<profile>
<id>it.tidalwave-aspectj-springaop-v1</id>
...
<build>
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<executions>
<execution>
<id>default-compile</id>
<phase>compile</phase>
<configuration>
<outputDirectory>target/unwoven-classes</outputDirectory>
</configuration>
</execution>
<execution>
<id>default-testCompile</id>
<phase>test-compile</phase>
<configuration>
<outputDirectory>target/unwoven-test-classes</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
...
The aspectj plugin is configured in the profile to statically weave binaries in the unwoven-test-classes directories. The reason for this approach is that it's the only feasible solution AFAIK to have both Lombok and AspectJ work together.
Now, back to the two classpaths described above: the fact that SureFire is using unwoven-classes means that it's pointing to bytecode that has not been augmented with AspectJ methods, hence the error.
References
The project is a FLOSS one and can be found at
https://bitbucket.org/tidalwave/northernwind-src
or
https://github.com/tidalwave-it/northernwind-src
A changeset where the problem can be reproduced is f98e9a89ac70138c1b6bd0d4570a22d59ed71be6. JDK 1.8.0 is required to build the project (even though it doesn't use Java 8 code yet).
The SuperPOM can be found here:
https://bitbucket.org/tidalwave/thesefoolishthings-superpom-src

Maven define goal dependencies, run initialize before versions:set

I'm including a newVersion propery form an external file using:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>properties-maven-plugin</artifactId>
<version>1.0-alpha-2</version>
<!-- Read in newVersion.properties instead of newVersion property -->
<executions>
<execution>
<phase>validate</phase>
<goals>
<goal>read-project-properties</goal>
</goals>
<configuration>
<files>
<file>${session.executionRootDirectory}/newVersion.properties</file>
</files>
</configuration>
</execution>
</plugin>
I'm also using versions:set to set the new version of the code from a CI build.
This works if I run:
mvn -DBUILD_NUMBER=99 initialize versions:set
IOW, I need to specify the "initialize" goal explicitly or it stops and prompts me for the newVersion because it defaults to running the versions:set goal before initialize goal.
How can I define the initialize goal as a dependency of the versions:set goal?
IMO I should not need to define intermediate target ordering.
Note, I know I could use the versions plugin to do all of this but I need to manage gradle and maven versions from a parent gradle script, so I need the base newVersion to come from an external source so that I can use it from multiple build environments.
Re mvn ... initialize ... – You bound the read-project-properties goal of the properties-maven-plugin to the validate phase, so mvn validate should be sufficient. (Introduction to the Build Lifecycle, Default Lifecycle).
Invoking mvn ... versions:set without any phase executes the set goal of the versions plugin directly without passing through (any phase of) the default lifecycle. That means it doesn't „default to running the versions:set goal before initialize“, it doesn't pass the initialize phase (initialize is a phase not a goal) at all.
And there's also the following at Versions Maven Plugin, Basic Usage:
Maven 2.0, 2.1, 2.2 and 3.0 do not currently support re-reading modifications of the pom.xml within one invocation of Maven.
The following goals:
versions:set
...
modify the pom.xml file, you need to run these goals separately from any other goals or life-cycle phases.
I'm not aware of any way to define a phase as dependency of a goal but you can declare:
<build>
<defaultGoal>...</defaultGoal>
defaultGoal: the default goal or phase to execute if none is given. If a goal is given, it should be defined as it is in the command line (such as jar:jar). The same goes for if a phase is defined (such as install).
See POM Reference, The BaseBuild Element Set.

How can I get maven-release-plugin to skip my tests?

How can I get the maven-release-plugin to run without triggering the tests?
I have tried
-Dmaven.test.skip=true
and
-DskipTests
and
-DpreparationGoals=clean
...yet none work.
Yes, I know I shouldn't release if the tests don't pass, but I don't have control over making my coworkers write reliable tests.
-Darguments="-DskipTests" is what you want, or explicitly configuring the forked executions in the pom.
-Darguments="..." passes arguments to the forked maven process, but it is important to realise that there are two different switches being used here. The -DskipTests forces maven to not run any tests, but the tests are still compiled (this is important if you have any dependencies on a test-jar type). The -Dmaven.test.skip=true forces maven to not even compile the tests, which means that any test-jars will not be generated.
So, you must use -Darguments, but to skip tests running use only skipTests, to stop them compiling use maven.test.skip.
If you just want to skip integration tests, this will do it:
-Darguments="-DskipITs"
you have too differents choices to avoid and skip tests with the release plugin
The first is to pass as argument on cli to the release goal or phases by providing a -Darguments:
exemple: mvn -X -Darguments="-Dmaven.javadoc.skip=true -Dmaven.test.skipTests=true -Dmaven.test.skip=true" -P release-mode release:prepare
-The second is to perform thoses arguments on your pom.xml in the build like this:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<dependencies>
<dependency>
<groupId>org.apache.maven.scm</groupId>
<artifactId>maven-scm-provider-gitexe</artifactId>
<version>1.9.4</version>
</dependency>
</dependencies>
<configuration>
<skip>true</skip>
<skipTests>true</skipTests>
<preparationGoals>clean validate</preparationGoals>
<arguments>-Dmaven.javadoc.skip=true -Dmaven.test.skipTests=true -Dmaven.test.skip=true</arguments>
<useReleaseProfile>false</useReleaseProfile>
<releaseProfiles>release-mode</releaseProfiles>
<tagNameFormat>TEST-#{project.version}</tagNameFormat>
</configuration>
</plugin>
Note that the second method override the first.
I recommanded you to prepare release first on a single action and then you can edit the release.properties file on the working directorie and look the exec.additionalArguments properties if your arguments are there. It will look like: exec.additionalArguments=-Dmaven.javadoc.skip\=true -Dmaven.test.skipTests\=true -Dmaven.test.skip\=true -P release-mode.
After you can perform the release.
I have managed to avoid running the verify goal by simply adding the configuration preparationGoals to clean:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>2.5.3</version>
<configuration>
<preparationGoals>clean</preparationGoals> <!-- See here -->
</configuration>
</plugin>
Use the following argument to skip test
-Darguments="-DskipTests"
or
alternatively skipping by default
[...]
<properties>
<skipTests>true</skipTests>
</properties>
[...]

Resources