I am integrating the Nullness Checker from the checker Framework to our Java project built with Maven. I configured the annotation processor for maven-compiler-plugin plugin. Everything works fine except that I don't want it run through the generated code.
Something along the lines of excluding the use of these annotation processors for code in target directory or for a specific java package could help, but I couldn't figure out how to do that.
I also tried to find a configuration for the Nullness Checker itself to exclude directories or java packages. Again I couldn't find anything.
Here's my plugin config:
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<annotationProcessorPaths>
<path>
<groupId>org.checkerframework</groupId>
<artifactId>checker</artifactId>
<version>3.4.0</version>
</path>
</annotationProcessorPaths>
<annotationProcessors>
<annotationProcessor>org.checkerframework.checker.nullness.NullnessChecker</annotationProcessor>
</annotationProcessors>
</configuration>
</plugin>
If you want to exclude certain files from the javac invocation that runs an annotation processor, that is a question about Maven that already has an answer here.
If you want to run javac on all files when running the annotation processor, but you want to suppress all warnings regarding certain files, use the -skipDefs command-line argument. Using -skipDefs makes the Nullness Checker issue the same warnings as if it had not been run on certain files.
Related
I've just started working on a large project that has many JSPs, many of which were created long ago, and some of which were generated. I would like to use the jetty-jspc-maven-plugin from org.eclipse.jetty to compile our JSPs for use in Tomcat 8.5. Unfortunately, some of the JSPs do not compile cleanly, and when there is a compilation problem, the maven build fails and stops.
The JspcMojo class does most of the work. It has an embedded class, JspcMojo.JettyJspC that extends org.apache.jasper.JspC and has a failOnError property. The documentation for JettyJspC says, "JettyJspC Add some extra setters to standard JspC class to help configure it for running in maven." So, it seems like I ought to be able to set the failOnError property to false and be done. I have tried all of the following, without success. How can I pass the failOnError property from maven to the JSP compiler?
<jspc.failOnError>false</jspc.failOnError>
<org.apache.jasper.compiler.failOnError>false</org.apache.jasper.compiler.failOnError>
<org.apache.jasper.JspC.failOnError>false</org.apache.jasper.JspC.failOnError>
<maven.compiler.failOnError>false</maven.compiler.failOnError>
<JettyJspC.failOnError>false</JettyJspC.failOnError>
<JspcMojo.JettyJspC.failOnError>false</JspcMojo.JettyJspC.failOnError>
<org.eclipse.jetty.jspc.plugin.JspcMojo.JettyJspC.failOnError>false</org.eclipse.jetty.jspc.plugin.JspcMojo.JettyJspC.failOnError>
BTW, compiling JSPs using ant is fairly well documented. I want to do the equivalent using maven.
Under the configuration section, you can use a subelement of the jspc element, like so:
<plugin>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-jspc-maven-plugin</artifactId>
<version>9.4.7.v20170914</version>
<executions>
<execution>
<id>jspc</id>
<goals>
<goal>jspc</goal>
</goals>
<configuration>
<webAppSourceDirectory>${basedir}/target/overlaidjsps</webAppSourceDirectory>
<webXml>${basedir}/src/main/webapp/WEB-INF/web.xml</webXml>
<webXmlFragment>${basedir}/target/webfrag.xml</webXmlFragment>
<!-- The comma separated list of patterns for file extensions to be processed. -->
<includes>**/*.jsp</includes>
<jspc><failOnError>false</failOnError></jspc>
</configuration>
</execution>
</executions>
</plugin>
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
Spring documentation tells that, if we compile our project using Java 8 --parameters flag, we can skip giving parameter names in annotations like #PathVariable. That means, we can just use #PathVariable id instead of #PathVariable("id") id.
In a Spring Boot Maven application, I was curious to know how to tell the compiler to use the parameters flag. Is it on by default? Do we need to provide something in the pom.xml?
In Spring Boot 2.0, the --parameters flag should be enabled by default. See yuranos87's answer.
For older versions, in the pom.xml file, you can specify Java compiler options as arguments of the Maven compiler plugin:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<compilerArgs>
<arg>-parameters</arg>
</compilerArgs>
</configuration>
</plugin>
I don't remember needing to do it explicitly in any of my projects. Maybe you just need to add spring-boot-starter-parent(I know, sometimes might not be an option). Otherwise, Spring has already taken care of everything for you.
It is mentioned multiple times in Spring Boot documentation. For example, here:
To allow the input to be mapped to the operation method’s parameters, code implementing an endpoint should be compiled with -parameters. This will happen automatically if you are using Spring Boot’s Gradle plugin or if you are using Maven and spring-boot-starter-parent.
UPDATE
The way Spring Boot does it is quite straight forward(in spring-boot-parent and spring-boot-starter-parent poms):
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>${java.version}</source>
<target>${java.version}</target>
<parameters>true</parameters>
</configuration>
</plugin>
Question
How to make a maven build fail if source code contains a keyword / regex?
Bonus
Be able to specify which path to check
Be able to specify which "kind" of path to check :
"I want to be sure that KEYWORD is not contained in 'main' resources. I don't care about 'test'"
"I want to be sure that KEYWORD is not contained in 'test' resources. I don't care about 'main'"
...
Be able to specify on which phase to execute the test (Eg. before compilation)
Solution
(Based on current answers 2013-09-26)
Best solution yet seems to be #BaptisteMathus answer that fully integrates with maven and is platform independant.
In my use case, #GregWhitaker answer is the good one because it's cheaper to implement as I don't care about platform independency (<= the required command is availiable on all my hosts).
The code sample below is a solution based on this answer, it forbids usage of "FIXME" or "Auto-generated method stub" but is assuming that egrep is availiable.
Please see also #MarkOConnor answer that is cleaner in "SONAR enabled" project
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.2.1</version>
<executions>
<execution>
<phase>process-sources</phase>
<configuration>
<executable>egrep</executable>
<successCodes>
<successCode>1</successCode>
</successCodes>
<arguments>
<argument>-rqm</argument>
<argument>1</argument>
<!-- Forbidden Keywords -->
<argument>FIXME|Auto-generated method stub</argument>
<!-- search path -->
<argument>src/main</argument>
</arguments>
</configuration>
<goals>
<goal>exec</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
Going to SonarQube to do that is not a bad idea.
Anyway, if someone wants to use a maven-only solution, then the right way would then be by using a plugin dedicated to "enforce" things with maven builds. Using exec-maven-plugin is not that standard and certainly too much platform-dependent.
This plugin is logically named maven-enforcer-plugin and writing a custom enforcer rule is actually very simple.
I would create a small program to run these checks and then execute it via the exec-maven-plugin. If you find the keyword in the main resources then just return a non-zero return code which will cause the plugin to fail the build.
Sonar has a taglist plugin, which allows you to search for strings in your comment blocks and specify the severity handling. I'm assuming that is what you're looking for... Parsing the source code itself might require a custom rule for a tool like checkstyle, I haven't tried this approach but it's documented on the Sonar site.
This can be coupled with the build breaker plugin, which fails your build when an alert criteria is breached in your project's quality profile.
I think the taglist-maven-plugin is exactly what you want.
I use Apache Thrift to generate code in target/generated-sources.
The Thrift compiler produces a directory named gen-java which contains all the Java code. When I execute mvn compile, the code is generated correctly in target/generated-source/gen-java, but in compilation phase, it complains can't find the classes which defined in gen-java.
In my understanding, Maven 2 automatically adds generated sources, is that right?
And what if my testing code also depends on the generated-sources, do I have to manually specified the compiler includes?
In my understanding, maven 2 automatically add generated sources, is that right?
Nothing automatic, plugins generating source code typically handle that by adding their output directory (something like target/generated-sources/<tool> by convention) as source directory to the POM so that it will be included later during the compile phase.
Some less well implemented plugins don't do that for you and you have to add the directory yourself, for example using the Build Helper Maven Plugin.
And since you didn't provide any POM snippet, any link, I can't say anything more.
And what if my testing code also depends on the generated-sources, do I have to manually specified the compiler includes?
As I said, generated sources are usually added as source directory and compiled and are thus available on the test classpath without you having to do anything.
Generated sources are not compiled or packaged automatically. Some IDEs (i.e. IntelliJ) will however show them as source folders.
To make generated sources visible to maven add a add-source-step to the build/plugins node of your pom.xml:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>3.0.0</version>
<executions>
<execution>
<phase>generate-sources</phase>
<goals>
<goal>add-source</goal>
</goals>
<configuration>
<sources>
<source>${project.build.directory}/generated-sources/gen-java</source><!-- adjust folder name to your needs -->
</sources>
</configuration>
</execution>
</executions>
</plugin>