How can i generate surefire reports in the maven's default lifecycle. We have jobs setup in teamcity with goals as
mvn clean install -Pprod
This job runs all the junits, i want to create HTML report of all the tests running in the project. I came across the sure-fire-reports plugin but it generates the report only in site phase it does not generates the report during the default clean install phase.
Can one please help how can i generate report default lifecycle
I tried including the surefire-reports plugin, in test phase as below but doesnot not works
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-report-plugin</artifactId>
<version>2.6</version>
<executions>
<execution>
<phase>test</phase>
<goals>
<goal>report-only</goal>
</goals>
</execution>
</executions>
</plugin>
If you need the very report generated by maven-surefire-report-plugin, I see no other way than execute mvn site, because a report is executed only within the site phase of the build lifecycle.
Instead, if you just need an HTML-readable report, I'd suggest you this walk-around:
Take advantage of the XML files generated by the maven-surefire-plugin in the target/surefire-reports directory.
Code your own transformation sheet (XSL) to transform them to the desired HTML format.
In the pom, set a transformation in the next phase (for example, prepare-package) through the xml-maven-plugin.
If you put the XSL in the parent project and set this transformation in the parent pom, all the submodule projects should inherit it and produce the HTML reports during the corresponding build.
And last: How to browse the child HTML reports from the parent project? Hum... I'd say to code an Ant script to browse all the submodules and list the HTML files and produce an HTML index with them. This script should be executed only from the parent project.
Related
I am setting up a multi-module maven project to create UI tests for a large browser based application using junit and the screenplay bdd pattern.
Each module works and reports as expected individually, however, if I try to run the tests at the top level of the project then - the tests run, but the report doesn't include ALL of the child modules.
I get a report with details from only 1 of the modules.
I have created a simple test example as follows;
The "simple" Maven project was created in Eclipse and the module test projects were created with
mvn archetype:generate -Dfilter=screenplay
and modified the tests to be different on each one.
The pom was updated to use serenity version 2.0.81
I have the following in the poms at all levels in the project
<plugin>
<groupId>net.serenity-bdd.maven.plugins</groupId>
<artifactId>serenity-maven-plugin</artifactId>
<version>${serenity.version}</version>
<executions>
<execution>
<id>serenity-reports</id>
<phase>post-integration-test</phase>
<goals>
<goal>aggregate</goal>
</goals>
</execution>
</executions>
</plugin>
Project folder structure is;
UITesting
pom.xml
serenity.properties
demo_one
src
test
java
resources
uk / co / test /
features
feature_folder_one
package-info.java
StoryClassOne.java
tasks
ui
pom.xml
serenity.properties
demo_two
src
test
java
resources
uk / co / test /
features
feature_folder_two
package-info.java
StoryClassTwo.java
tasks
ui
pom.xml
serenity.properties
and same for demo 3
and I set the output directory in the each level serenity.properties file
serenity.outputDirectory=c:/temp/uireport
I want the Requirements, Features and Stories tabs to consolidate all of the child module report data. The actual tests and tags are consolidated, but nothing else is.
some feedback on this from serenity core github issues states;
This won't happen automatically - multi-module tests aren't supported in this way.
I am writing a maven plugin which generates java source code based on input text file and some additional configuration.
e.g. User creates maven project and adds my plugin in his project's pom.xml as below -
<plugin>
<groupId>abc.plugin</groupId>
<artifactId>abc-maven-plugin</artifactId>
<version>1.0.0</version>
<executions>
<execution>
<goals>
<goal>abc</goal>
</goals>
</execution>
</executions>
<configuration>
<schemaPath>${basedir}\input</schemaPath>
<package>com.svc.xyz</package>
<fileNametxt>${basedir}\input.txt</fileNametxt>
</configuration>
</plugin>
As part of executing the goal of my plugin, i would like the plugin delete all the pre existing java source files/directories in user's project as well as rewrite pom.xml of user project.Plugin should regenerate user project's pom.xml taking existing contents and also keep some other existing user project resources like schema Directory.
Also,I don't want user of plugin to do any editing after generation of source code and would prefer to directly 'compile package' the generated source code in user project by the plugin.
Since plugin will regenerate users' pom.xml itself, may be need to create a new maven project altogether with generated source code, compile, package and have jar created?
I have a maven project for which I'm running two separate builds.
In one build I want to save the build time by disabling the jar creation of maven modules in it.(There are 45 maven modules). There is a Maven-Jar-Plugin that is being used to create the jars.
I want to conditionally disable the jar creation at the command line, that is, looking for something similar to -Dskiptests used to skip the unit tests though there is a surefire plugin by default.
The maven-jar-plugin does not provide any skip option.
However, several ways are possible to achieve your requirement.
You may just skip the phase which brings by default (via default mappings) the jar creation, that is, the package phase, and as such simply invoke
mvn clean test
The additional phases would not make sense if you do not create a jar file anyway: package, install, deploy would not have anything to process. Moreover, the additional integration phases may also be impacted depending on your strategy for integration tests, if any.
Alternatively, you can configure your pom as following:
<properties>
<jar.creation>package</jar.creation>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>3.0.0</version>
<executions>
<execution>
<id>default-jar</id>
<phase>${jar.creation}</phase>
</execution>
</executions>
</plugin>
</plugins>
</build>
As such, the default behavior would still provide a jar creation, while executing maven as following:
mvn clean install -Djar.creation=false
Would instead skip the creation of the jar.
What we are actually doing:
We are re-defining the default execution of the maven-jar-plugin
We are overriding its execution id, as such getting more control over it
We are placing its execution phase binding to a configurable (via property) phase
Default phase (property value) keeps on being package
At command line time you can still change it to any value different than a standard maven phase. That is, -Djar.creation=none would also work.
We're using maven to run a sonar analysis and it works well except for the code coverage results with jacoco. We have an eclipse project that uses tycho-surefire-plugin for testing. I've not overriden the argLines properties so solutions involving that line may not be appropiate.
Facts :
Maven structure structure:
parent
master
module 1
module ...
module n
Testing structure:
client.admin (eclipse-plugin packaging)
client.admin.test.fragment (eclipse-test-plugin packaging)
Properties that are correctly set and identified
sonar.junit.reportsPath
sonar.jacoco.reportPath,
sonar.jacoco.itReportPath
sonar.core.codeCoveragePlugin
sonar.language
The main problem is with the following properties
sonar.test
sonar.sources
sonar.java.binaries
As seen in the Testing structure in the client.admin.test.fragment tests are contained in the /src folder and the sources are located in the project client.admin in the /src folder too.
When we run the analysis we get the following error :
[WARN] Coverage information was not collected. Perhaps you forget to include
debug information into compiled classes?
I believe this has to do with the properties sonar.java.binaries that goes looking for the sources in target/classes of the fragment project (client.admin.project) that are in fact located in the host project (client.admin). In the fragment project we've configured sonar.tests and sonar.sources properties so that they call the /src folder of the corresponding projects.
In the sonar Analysis Parameters page there says that only sonar.sources is a maven valid property, sonar.tests and sonar.java.binaries cannot apparently be configured in maven. How then could I attach the binaries to the project. I've tried copying the folder target/classes from the host project but I got the same message. Is there any workaround in maven ?
Edit 1
There is one jacoco.exec file that is generated for the whole project that can be found at the parent folder. This was done configuring the jacoco.destFile and sonar.jacoco.reportPath properties
Jacoco plugin in main pom :
<!-- Jacoco Plugin -->
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<executions>
<execution>
<id>prepare-agent</id>
<goals>
<goal>prepare-agent</goal>
</goals>
<configuration>
<destFile>${sonar.jacoco.reportPath}</destFile>
<append>true</append>
</configuration>
</execution>
<execution>
<id>default-report</id>
<goals>
<goal>report</goal>
</goals>
<configuration>
<dataFile>${sonar.jacoco.reportPath}</dataFile>
<outputDirectory>${jacoco.reports.outputDirectory}</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
Maven Plugin Versions:
sonar: 2.4
jacoco: 0.7.1.201405082137
Properties
<sonar.language>java</sonar.language>
<sonar.core.codeCoveragePlugin>jacoco</sonar.core.codeCoveragePlugin>
<sonar.junit.reportsPath>${project.build.directory}/surefire-reports/</sonar.junit.reportsPath>
<sonar.jacoco.reportPath>${basedir}/../../../main/**.master/target/jacoco.exec</sonar.jacoco.reportPath>
<jacoco.reports.outputDirectory>${basedir}/../../../main/**.master/target/site/jacoco</jacoco.reports.outputDirectory>
<sonar.sources>src</sonar.sources>
In the test projects (eclipse-test-plugin) we changed added the property sonar.sources to go find the sources from the src folder of the project that we're testing for example in client.admin.test.fragment we go search the src from the client.admin
The following properties were commented in code because they're not supported in maven according to documentation and to the debug output.
<!--<sonar.dynamicAnalysis>reuseReports</sonar.dynamicAnalysis>-->
<!--<sonar.tests></sonar.tests>-->
<!--<sonar.java.binaries></sonar.java.binaries>-->
First, you must tell the JaCoCo agent to report all coverage data into one common file. Second, you tell the Sonar JaCoCo plugin to read the coverage data from the aggregated file.
To do so, set the properties "jacoco.destFile" and "sonar.jacoco.reportPath" in your parent pom.xml to the same absolute path, e.g.:
<properties>
<jacoco.destFile>/home/jenkins/jobs/my.project/workspace/parent/target/jacoco.exec</jacoco.destFile>
<sonar.jacoco.reportPath>/home/jenkins/jobs/my.project/workspace/parent/target/jacoco.exec</sonar.jacoco.reportPath>
</properties>
Note that these properties will be inherited to all child poms, so you can't use Maven expressions like ${project.build.directory} because this would evaluate to a different directory for each pom.
You could create a small helper Mojo which automatically resolves an absolute path on the current build machine and then injects the properties into the Maven model.
I created a GWT project with
mvn archetype:generate -DarchetypeGroupId=org.codehaus.mojo -DarchetypeArtifactId=gwt-maven-plugin -DarchetypeVersion=2.5.0
Imported the project in eclipse juno.
First error I get is this :
Plugin execution not covered by lifecycle configuration: org.codehaus.mojo:gwt-maven-
plugin:2.5.0:i18n (execution: default, phase: generate-sources)
In the pom file.
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>gwt-maven-plugin</artifactId>
<version>2.5.0</version>
<executions>
<execution>
<goals>
<goal>compile</goal>
<goal>test</goal>
<goal>i18n</goal>
<goal>generateAsync</goal>
</goals>
</execution>
</executions>
<!-- Plugin configuration. There are many available options, see
gwt-maven-plugin documentation at codehaus.org -->
<configuration>
<runTarget>dashboard.html</runTarget>
<hostedWebapp>${webappDirectory}</hostedWebapp>
<i18nMessagesBundle>com.farheap.jsi.dashboard.client.Messages</i18nMessagesBundle>
</configuration>
Also the code contains a GreetingServiceAsync that can not be found.
private final GreetingServiceAsync greetingService = GWT.create(GreetingService.class);
You have two options:
You can add special (non-trivial) org.eclipse.m2e:lifecycle-mapping plugin
configuration to your POM. See here: Why am I receiving a "Plugin execution not covered by lifecycle configuration with GWT" error?
Or mark this issue as to be ignored in Eclipse POM editor, and then call mvn gwt:i18n. You can create a handy short cut launcher for it. Eclipse remembers your decisions what to ignore, it stores it into .settings directory permanently for the project.
In course of typical development localization messages do not change often so the second option is usually more convenient and speeds up build.
This applies for most GWT plugin goals! Even GWT compilation is rarely necessary as DevMode works directly with Java code and not generated JavaScrips. So in practice, you have to call all the goals at least once on the beginning and then live weeks without them; basic Eclipse JDT compilation is sufficient.
If you later decide not to use GWT localization framework in your real app then you can remove goal i18n completely from POM. Calling goal i18n generates file {project}/target/generated-sources/gwt/my/code/client/Messages.java which is required by (vanilla) Sample.java.
Also the code contains a GreetingServiceAsync that can not be found.
Run the build mvn install from command line or Eclipse Run as -> Maven install menu.
In case of command line mvn gwt:generateAsync should be enough. This goal generates {project}\target\generated-sources\gwt\my\code\client\GreetingServiceAsync.java and that is what you missing. Eclipse did not do it for you automatically because it was blocked by previous issue of i18n not being covered by lifecycle configuration. So yes, issues you mention are correlated.