PITEST incremental analysis cannot find local hash file - mutation-testing

I'm currently trying PITest and so far it works properly. However, it is quite slow and the only solution so far is to use incremental analysis which potentially will solve the slowness. I've tried to set it as it's described in the documentation. Here is my configuration:
<build>
<plugins>
<plugin>
<executions>
<execution>
<id>pitest-mutation-coverage</id>
<goals>
<goal>mutationCoverage</goal>
</goals>
</execution>
</executions>
<groupId>org.pitest</groupId>
<artifactId>pitest-maven</artifactId>
<version>1.4.6</version>
<configuration>
<threads>8</threads>
<timestampedReports>false</timestampedReports>
<historyInputFile>${project.basedir}/pitest.history</historyInputFile>
<historyOutputFile>${project.basedir}/pitest.history</historyOutputFile>
<avoidCallsTo>
<avoidCallsTo>java.util.logging</avoidCallsTo>
<avoidCallsTo>org.slf4j</avoidCallsTo>
</avoidCallsTo>
<mutators>
<mutator>DEFAULTS</mutator>
</mutators>
</configuration>
</plugin>
</plugins>
However, in practise I don't see PITest taking historyInput and historyOutput into account and instead in the logs I'm seeing
[INFO] Will read and write history at /var/folders/x1/qp5hhks571q0drb7kd7vjn0c0000gn/T/my.module.groupId.artifactId.version_pitest_history.bin
I've tried plenty of different settings and none of them seem to work.
Is there anything I'm missing?
Update
In the end, it turns out that the plugin definition was coming from the parent-pom and overriding it is partially possible in the inheriting child-pom.

There config you have posted works correctly.
You would only see the message
[INFO] Will read and write history at /var/folders/x1/qp5hhks571q0drb7kd7vjn0c0000gn/T/my.module.groupId.artifactId.version_pitest_history.bin
If you had also set withHistoryto true.
There looks to be a bug which stops things working if both are set. This needs to be fixed, but setting both doesn't really make sense.
withHistory is a convenience flag that sets both the in and outfile to point at a location in the temp dir.
The in/out file parameters are for when more fine grained control is needed (e.g the input file is being shared across a team).
So either set witHistory or set the history files explicitly, don't do both.

Related

Intellij path rule to automatically recognize generated sources folder

I would like to know if it is possible to set up a rule that marks a generated sources folder as generated sources root in Intellij Idea automatically.
Usually, Intellij detects the target/generated-sources directory as generated sources. My problem is that I also need it to automatically recognize the directory target/generated as generated sources, which Intellij never did in my case.
This is because of a maven plugin that I use for generating code from XSD schema:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
</plugin>
<plugin>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-xjc-plugin</artifactId>
<version>${cxf.version}</version>
<configuration>
<extensions>
<extension>org.apache.cxf.xjcplugins:cxf-xjc-dv:${cxf.version}</extension>
</extensions>
</configuration>
<executions>
<execution>
<id>generate-sources</id>
<phase>generate-sources</phase>
<goals>
<goal>xsdtojava</goal>
</goals>
<configuration>
<xsdOptions>
<xsdOption>
<xsd>src/main/resources/schema.xsd</xsd>
<packagename>org.example.project.common.request</packagename>
</xsdOption>
</xsdOptions>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
For some reason, this plugin generates code into the target/generated directory, and not into the target/generates-sources, of which I read that it is the convention and the default from many points of view.
I've tried searching on the web with similar keywords like in the title, but this was the closest solution to what I wanted to achieve. And even this solution doesn't solve my problem because Intellij doesn't allow setting some path patterns; it only offers a few options that don't include target/generated directory.
Another solution suggests changing the target output, which I can't do in every single project I work on; that is not a solution either.
This is important to me because I work with many projects, and sometimes when my code builds with maven but doesn't compile with Intellij I forget to check whether I marked all the generated folders as sources, or I don't even know there are generated sources in the project.
Does someone know a way I can achieve that Intellij automatically detects source files in target/generated directory?

How to structure Maven3 project to produce inputs to generate-sources in another project?

I need to generate a few small text files that will be used as inputs during generate-sources phase of another project (data files input to FMPP/FreeMarker). The generator is Java source code - that is, the code that generates the text files is compiled in the first project. In this kind of scenario, how are the data files normally conveyed from one project to the other?
I could cobble together a dozen lame ways to do this - I'm looking for best practice.
At the moment, I'm avoiding the problem by having the first project just produce an executable jar, which is run by the second project to produce the data files. But there's really no reason for the code to be "public" - to be installed - the output of the first project really should just be the TDD files.
I'm not sure I have the full picture of what you're trying to do here but it sounds to me like you should be using the maven dependency plugin.
I'm assuming that the first project would create an artifact with the data files you need for the second and other projects. The second project could use the dependency plugin to unpack that artifact into target/generated-sources or wherever it is needed as part of its build.
For example:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.1</version>
<executions>
<execution>
<id>unpack-interfaces</id>
<phase>initialize</phase>
<goals>
<goal>unpack-dependencies</goal>
</goals>
<configuration>
<includeArtifactIds>first-project-artifact</includeArtifactIds>
<includes>*.TDD</includes>
</configuration>
</execution>
</executions>
</plugin>
I hope I don't misunderstand you. You can run a maven2 project with exec-maven-plugin. This will run the first project and produces input for the next. If you should copy the *.tdd files, maybe you can use maven-resources-plugin for this. Hope it helps.

How to display dependency conflicts in 'mvn site'

I can easily see if there are conflicts between (transitive) dependency versions using:
mvn dependency:tree -Dverbose=true
... this will show the full resolution tree, including which elements were omitted (for duplicate or conflict or whatever). What I would like to do is to add the full tree to the 'mvn site' report.
Currently, the site report includes the dependency tree but only as resolved, i.e., without any conflicts. I see in the project-info-reports plugin that there is not currently any way to do what I want using the standard report.
I tried adding a section to the pom to include the maven-dependency-plugin 'tree' goal with the outputFile specified, but it wasn't included when I ran 'mvn site'. It was something like this:
<reporting>
....
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<reportSets>
<reportSet>
<id>deptree</id>
<reports>
<report>tree</report>
</reports>
<configuration>
<verbose>true</verbose>
<outputFile>${project.reporting.outputDirectory}/deptree.txt</outputFile>
</configuration>
Of course, the 'tree' goal is explicitly identified as not a report, but I was hoping to at least be able to produce a file that I could link to from the generated site. No dice.
Is there any way to force an arbitrary plugin's goal to execute during site generation? Am I totally out of luck here? Obviously I could write my own reporting plugin to do this, and/or submit a patch for the project-info-reports plugin, but I want to make sure I've exhausted all the built-in maven options.
(I'm using maven 2.1.0, but I didn't see anything about a change to this functionality in the release notes for later versions.)
Is there any way to force an arbitrary plugin's goal to execute during site generation? Am I totally out of luck here?
Just to answer your question, you can bind a mojo to the pre-site phase of the Site Lifecycle:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>tree</id>
<phase>pre-site</phase>
<goals>
<goal>tree</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
<reporting>
...
</reporting>
If you then run mvn site, dependency:tree will run.

Combined site/deploy goal for Maven

When running a Maven build on the CI server, I generate the site to publish the documentation and reports, and also deploy the artifact to the snapshot repository for use by other projects. To do this I run the following goals:
mvn clean site deploy
This means the unit tests are run twice, once for the site lifecycle and once for the deploy lifecycle. If I configure the site goal to be bound to the standard lifecycle the tests are still run twice, running the site goal always causes the tests to be run because of the #requiresDependencyResolution test annotation. This is fine if you're only creating the site, but in the context of a deploy it greatly increases the build time for no benefit.
I have a workaround that involves copying the SiteMojo (and the required parents) to a new plugin and removing the #requiresDependencyResolution test annotation from the copy.
This modified mojo will generate the reports without forcing the tests to be run again but I'd prefer a solution that doesn't involve any hacking of the site plugin. Is there a way to suppress the requiresDependencyResolution annotation?
I'm surprised this works - the #requiresDependencyResolution test tag doesn't actually trigger the tests being built - that should be one of the reports that you've included. Normally, I recommend running the site and the build in separate Maven executions in CI so you can get fast feedback on your build and publish the latest site only when that succeeds.
Another alternative is to run it as mvn clean deploy site, and choose the report-only mojo for surefire-report-maven-plugin (this is usually the report that is running the tests again). This will use the previous test results. Of course, another alternative is disabling that report altogether, since you likely get those results from another source such as your CI server anyway.
My current approach is to create a new plugin with copies of the relevant types from the maven-site-plugin. These types are identical to the standard versions except for changing the type name, the goal name and the removal of the #requiresDependencyResolution test annotation.
The copied types are:
org.apache.maven.plugins.site.AbstractSiteMojo
org.apache.maven.plugins.site.AbstractSiteRenderingMojo
The parent mojos are required so Maven can process the javadoc-based annotations (this shouldn't be required for Maven 2.2.0+).
org.apache.maven.plugins.site.SiteMojo
org.apache.maven.plugins.site.SiteJarMojo
These two are copied as SiteOnlyMojo and SiteJarOnlyMojo respectively, SiteJarOnlyMojo is changed to inherit from SiteOnlyMojo . Otherwise the only changes are to change the goal namess and remove the annotation.
So SiteOnlyMojo has:
* #goal site
* #requiresDependencyResolution test
changed to:
* #goal site-only
and SiteJarOnlyMojo has:
* #goal jar
* #phase package
changed to:
* #goal jar-only
* #phase package
These types are declared in a maven-plugin project with artifactId maven-site-only-plugin with a dependency declared on the proper site plugin.
To use this I define a profile (I don't want the reports running on every execution, only when -Psite is declared on the command line) and bind it to the prepare-package phase (prior to 2.1.0, you'd have to bind it to the package phase instead).
<profile>
<id>site</id>
<build>
<plugins>
<plugin>
<artifactId>maven-site-only-plugin</artifactId>
<version>1.0.0</version>
<executions>
<execution>
<phase>prepare-package</phase>
<goals>
<goal>jar-only</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
<build>
<pluginManagement>
<plugins>
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-site-plugin</artifactId>
<version>3.2</version>
<executions>
<execution>
<goals>
<goal>site</goal>
<goal>deploy</goal>
</goals>
<phase>deploy</phase>
</execution>
</executions>
</plugin>
...
</plugins>
</pluginManagement>
</build>
This will automatically execute the site action when issuing a 'mvn deploy' command, as well as ensuring the testing suite is only executed once.

Maven 2 checkstyle plugin version 2.5 - Problem with configLocation

I am using checkstyle plugin in maven 2. I now want to switch my config file, from the default one to a) an online file, or b) a local file. I tried the following two things, which both didnt work. Any suggestions?
A) Local file, which is directly in my project folder next to the pom.xml
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<configuration>
<configLocation>checkstyle.xml</configLocation>
</configuration>
</plugin>
B) Remote file, that is stored on a server
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<configuration>
<configLocation>http://stud.hs-heilbronn.de/~nischmid/development/checkstyle-config.xml</configLocation>
</configuration>
</plugin>
Both cases result in an error like this:
[INFO] An error has occurred in
Checkstyle report generation. Embedded
error: Failed during checkstyle
execution Could not find resource
'file:checkstyle.xml'.
Any help would be appreciated!
I've seen several issues related to configLocation in Jira with the version 2.5 of the plugin (like MCHECKSTYLE-129 or MCHECKSTYLE-131), both a) and b) just work fine with the version 2.4.
So, unless you're using Maven 3, I suggest to rollback to 2.4 for now:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<version>2.4</version>
<configuration>
<configLocation>checkstyle.xml</configLocation>
</configuration>
</plugins>
or
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<version>2.4</version>
<configuration>
<configLocation>http://stud.hs-heilbronn.de/~nischmid/development/checkstyle-config.xml</configLocation>
</configuration>
</plugin>
As a side note, for a multi-modules build, have a look at the Multimodule Configuration.
I've been trying to use version 3.0.1 of the Checkstyle plugin and found configLocation has no effect. Tried the approach above, but still no luck.
To summarise, the answer above probably does work, but you might need to set a property checkstyle.config.location.
Using -X to get debug output, I saw:
[DEBUG] (f) configLocation = config/sun_checks.xml
Scrolling further back in the log, it looks like configLocation isn't being set:
<configLocation default-value="config/sun_checks.xml">${checkstyle.config.location}</configLocation>
Based on that message, I set the property in the global <properties> as follows:
<checkstyle.config.location>${basedir}/config/checkstyle-configuration.xml</checkstyle.config.location>
This worked, but caused the plugin to throw an exception. After some Googling, I added the following to the checkstyle configuration file:
<module name="Checker">
...
<module name="TreeWalker">
...
<property name="cacheFile" value=""/>
For completeness, the last step came from the following Jira, marked as resolved in 2.8. The difference is it seems to work with an empty value, avoiding the need to set up a ${cachefile} property:
http://jira.codehaus.org/browse/MCHECKSTYLE-159
Maybe helpful for someone else who needs to still find a workaround.
By the way i had the same problem and the file is suppose to be searched in /classes/.xml or folders from here. But since it is looking directly after the project folder i included
<configuration>
<configLocation>src\main\resources\checkstyle-checker-dev.xml</configLocation>
</configuration>
Note: configLocation has L caps
Also you can define a global variable in environment and use here
Note: This is only a workaround, it needs to work as stated in the above lines.