I was trying to build hive-0.13.
When using -Dmaven.test.skip=true, it will not build the test jars but it will check test dependency.
When using -DskipTests, it will not build the test jars and also not check test dependency.
What's the difference between -DskipTests and -Dmaven.test.skip=true?
Maven docs:
-DskipTests compiles the tests, but skips running them
-Dmaven.test.skip=true skips compiling the tests and does not run them
Also this one might be important
maven.test.skip is honored by Surefire, Failsafe and the Compiler
Plugin
There is a third, related option described here: https://stackoverflow.com/a/21933970/3169948
"maven.test.skip.exec=true" the tests get compiled, but not executed.
So the complete set of test options for Maven would be:
-DskipTests ==> the tests get compiled, but not executed.
-Dmaven.test.skip.exec=true ==> the tests get compiled, but not executed (exactly the same as -DskipTests).
-Dmaven.test.skip=true ==> doesn't compile or execute the tests.
Related
I have a big java project. Using maven to automate the build and manage dependencies and JUnit for the unit testing.
When i'm running mvn clean install from Intellij the build fails because of one unit test that fails.
The test succeeds when ran manually.
Also, executing mvn clean install from the terminal succeeds. (all tests pass)
I'm not sure where to look for the problem here.
Thanks!
I am using command like mvn -q -Dtest=MyJUnitTestClassName#runSingleTest testas per maven & junit documentation it should run ONLY the runSingleTest test method. but problem is all tests are running.
I am using maven3 and junit4.
mvn -q -Dtest=MyJUnitTestClassName#runSingleTest test
Try quotes around your class and test (i.e. -Dtest="MyJUnitTestClassName#runSingleTest"). I use Maven 3.3 and JUnit 4 and the syntax you listed works for me, but that behavior sounds similar to issues with some versions of the SureFire plugins.
Run a single test method with maven
I am running maven like this:
mvn clean cobertura:cobertura package
I am noticing that my unit tests get run twice (thus doubling my build time). Is there a way to run cobertura AND generate the package in the same command without running tests twice?
An easy way would be to run two separate commands. In Bash it's then easy to chain them together into one line:
mvn clean cobertura:cobertura && mvn package -Dmaven.test.skip=true
The first bit:
mvn clean cobertura:cobertura
Does clean, runs the tests and generates the coverage report.
The second bit:
mvn package -Dmaven.test.skip=true
Does the packaging, but tells it not to run the tests.
The && is there so that if the first command fails, then it won't try to run the second.
I currently try to run an integration test with maven failsafe, like described in here: reference link .
For this, I got 3 Modules: datamodule, datamodule2 and testmodule (all covered by a parent pom). testmodule depends on the two other modules. It got an test in src/test/java/ named MyTestIT.java. If I try to run the test with mvn clean test failsafe:integration-test, everything runs fine, but if I only run mvn failsafe:integration-test, it does not work. Does somebody know how it's this way?
If I try to run the test with surefire, for example with mvn test -Dtest=MyTestIT, it says it can't find MyTestIT in datamodule, and I need to set -DfailIfNoTests=false. If I try to run it with mvn test --pl testmodule, it says it can't find the dependencies (this only happens when they are not installed, but I don't want to call install everytime I run a test).
Is there any way of setting this in a pom, either in the parent pom or in the project pom? Or any other way of saying to maven "only run the integration tests, use the right dependencies and do not install everything"?
official documentation http://docs.sonarqube.org/display/SONAR/Analyzing+with+Maven says that the proper way of invoking sonar is:
mvn clean install -DskipTests=true
mvn sonar:sonar
but doesn't say why. how does sonar work? does it need compiled classes? so why not just mvn clean compile? or does it need a jar file? so why not just mvn clean package? what exactly does sonar plugin?
Explanation from a SonarSource team member:
In a multi-module build an aggregator plugin can't resolve dependencies from target folder. So you have two options:
mvn clean install && mvn sonar:sonar as two separate processes
mvn clean package sonar:sonar as a single reactor
I was surprised too, so I made a tweet an received the following answer from the official Maven account:
If the plugin is not designed to use the target/classes folder as a substitute, then yes you would need to have installed to get the jar when running *in a different session*. Complain to the plugin author if they force you to use install without foo reason [ed - #connolly_s]
The SonarQube analyzer indeed needs compiled classes (e.g for Findbugs rules, coverage). And since by default it executes tests itself, the compile phase can skip tests.
You can run SonarQube as part of a single Maven command if you meet some requirements:
As Mithfindel mentions, some SonarQube plugins need to analyze .class files. And if you run unit tests outside of SonarQube, then of course the testing plugins must read output from the test phase.
Got integration tests? Then you need to run after the integration-test phase.
If you want to run SonarQube as a true quality gate then you absolutely must run it before the deploy phase.
One solution is to just attach SonarQube to run after the package phase. Then you can get a full build with a simple clean install or clean deploy. Most people do not do this because SonarQube is time-consuming, but the incremental mode added in 4.0 and greatly improved in the upcoming 4.2 solves this.
As far as the official documentation goes, it's a lot easier to say "build and then run sonar:sonar" then it is to say, "open your POM, add a build element for the sonar-maven-plugin, attach it to verify, etc".
One caveat. SonarQube requires Java 6, so if you're building against JDK 1.5 (still common in large organizations), the analysis will have to happen in a separate Maven invocation with a newer JDK selected. We solved this issue with custom Maven build wrapper.