I have a Maven project where the order of the dependencies is important. Everything builds just fine. The tests run just fine.
Unfortunately, some of the unit tests break running 'mvn site' because we have emma-maven-plugin configured. The same unit tests also break when running 'mvn emma:emma'.
Is there any way to control the classpath which emma-maven-plugin uses, or to force it to use the dependency ordering specified in the project?
The emma-maven-plugin I'm using is org.codehaus.mojo:emma-maven-plugin:1.0-alpha-3.
Thanks,
PS. I am aware of JaCoCo (jacoco-maven-plugin), and will get round to this is due course, but for now, I'm stuck with Emma
Related
When generating a skeleton Maven plugin from archetype, the new project includes a Maven project under the src/it directory. It is an integration it (hinted at by the it dir name) and fresh out-of-the-box it passes when run during Maven's integration-test phase.
There are nearly 10 such IT Maven projects, a subset of which intentionally result in BUILD FAILURE, and attendant verify.groovy scripts that ensure those builds fail for the correct reason. Ideally each IT test sub-build that fails for the correct reason results in that IT test passing, but by including any of these failing IT tests as part of the whole integration test suite causes the overall Maven run to fail as well, which is incorrect in my case.
How do I coax Maven to run those failing Maven sub-builds, ignore their build results, but honor the results of their Groovy verification scripts?
Edit: One IT test (disabled) is committed here.
If you like to write an integration test which is intended to fail as a result
you have to express this via the invoker.properties file like this:
invoker.buildResult=failure
The full description of the file can be found in the documentation.
So I have Jenkins with the Cobertura plugin installed. I have Cobertura and findbugs in the POM and my tests are running twice...
I assume that this is because Cobertura instruments the bytecode and this causes the tests to re-run, which isn't a bad thing I guess, since the instrumented isn't the same as non-instrumented code...but I would really like the tests to be run only once.
I have tried running them locally on commandline using these commands:
mvn cobertura:cobertura -Dcobertura.report.format=xml
mvn findbugs:findbugs -Dfindbugs.onlyAnalyze=true
mvn cobertura:cobertura -Dcobertura.report.format=xml findbugs:findbugs -Dfindbugs.onlyAnalyze=true
but I can't get the tests to run twice locally, where as on Jenkins the are running twice. I am not sure why this is happening and whether I could make it stop.
I am using Cobertura to generate reports for me...I assume that to generate them it needs to re-run the tests? But it doesn't make sense since they are already being run once.
We have faced the same behavior. It seems to be default behavior of Cobertura to rerun test cases for calculating coverage.
We switched to JaCoCo tool, which proved to be better . It does not re-run the test cases for coverage report.
Indeed you have to run tests twice with cobertura-maven-plugin (or use different profiles). This behavior is due to the fact that it runs Cobertura instrumentation in its own lifecycle and uses Cobertura executable instead of Cobertura API.
If you want to generate a Cobertura report while only running your tests once, you can give a try to the qualinsight-mojo-cobertura-core plugin. This plugin uses a different approach to run Cobertura instrumentation.
You'll find a documentation on the project's page: https://github.com/QualInsight/qualinsight-mojo-cobertura .
Note that this plugin has still some limitations, but it may be a viable alternative in your context.
Hope it helps !
Regards.
I have a project with the following subprojects:
foo-codegen
...which, as the name implies, performs code generation...
foo-maven-plugin
...which invokes foo-codegen during the build process.
Generally speaking, this works fine. The problem, though, is when I want to test foo-codegen: foo-maven-plugin isn't yet available during foo-codegen's build cycle if we're putting things together in dependency order, but the build process for the tests invokes that plugin to actually perform the necessary code generation.
What's the right way to break this chain? Should I move foo-codegen's tests into a third subproject? Use the Maven Invoker plugin rather than foo-maven-plugin for doing code generation during the test phase? Something else?
If you do a mvn install or mvn deploy to a repository on the plugin first, then you can run them any order and do a mvn compile separately.
In a multi module mvn 3.0 build, I set forkedProcessTimeoutInSeconds to one hour. If tests in module A hang, I hit surefire threshold which will fails the build and skips remaining modules. We use a junit timeouts which should kill hung tests prior to this but some scenarios encounter this problem. I'd like to keep my builds running while I investigate enhancements to our junit runner.
Current Command Line: mvn clean install -Dmaven.test.failure.ignore
How I can change the surefire timeout behavior to move to next module and continue the build?
Does anyone have tips for testing one's junit framework?
I was going to review the surefire project's integration tests for ideas for both items. I plan to have a junitsystest module which activated by a specific profile so I can test various problematic situations outside of my builds.
According to Mastering The Maven Command Line – Managing failures --fail-at-end or --fail-never will provide the desired results. Surefire timeout continues to be reported but doesn't halt the build.
Not recommending in the long run as it lengthens bad build times
mvn clean install -Dmaven.test.failure.ignore --fail-never
I have a strange issue and I don't know if my conclusion is correct. I have a multi module project with two children:
Rector build order:
mvn-project-test
mvn-project-core
core depends on test (so the build order is correct). Of course, running 'mvn test' doesn't install any artifacts locally. When running it, maven complaints (correctly) that ~/.m2/respositories/...../mvn-project-test-1.0-SNAPSHOT.jar is missing and the core build fails.
Shouldn't maven use the dependencies from the target folder of other multimodule children? Or must I always use 'mvn test install' on multi module projects? (Or third, I'm completely wrong and my whole project configurationis somehow broken)
Finally, the test project hasn't any content, yet, just dependencies so the jar is empty. But that shouldn't be a problem, right?
Cheers,
Jan
There were ideas for Maven 3 to allow the various mojos to see the whole build and do magic like "if none of my upstream projects changed, skip my tests" and things like that.
But as it is, each module is independent. Dependencies will only be resolved from the local repository. So if you don't mvn install, your tests won't work.