Is it possible to (in any way) process the annotations with RetentionPolicy.SOURCE (or at least RetentionPolicy.COMPILE) in a maven Mojo?
I'd like to generate an additional documentation based on my custom annotations with aforementioned retention policy – since the documentation is in no way needed during runtime, I wouldn't like these annotations to clutter the ClassLoader.
(something like swagger, but I need not to serve this documentation during runtime and swagger annotations are retained at runtime...)
The reason I don't want to use a simple javax.annotation.processing.AbstractProcessor is that I want to have the convenient configurability of a full-fledged maven plugin, with a lot of optional properties etc.
This looks like what you're after.
https://maven-annotation-plugin.googlecode.com/svn/docs/usage.html
I'm looking for the same thing, but this plugin isn't available at my workplace, so I can't really comment further. Seems to meet your use case though.
<build>
<plugins>
<plugin>
<groupId>org.bsc.maven</groupId>
<artifactId>maven-processor-plugin</artifactId>
<executions>
<execution>
<id>process</id>
<goals>
<goal>process</goal>
</goals>
<phase>generate-sources</phase>
<configuration>
<processors>
<!-- list of processors to use -->
<processor>org.bsc.apt.BeanInfoAnnotationProcessor</processor>
</processors>
</configuration>
</execution>
</executions>
</plugin>
</plugin>
</build>
Related
we are a team of developers with very different experiences and coding styles. But as we are working on same projects it is necessary to have some common ground regarding code style.
Is there a maven plugin that can check for several coding rules? We already use checkstyle and spotbugs, but I'm interested if it's possible to include it in regular build.
I'd like to know if it's possible to make build fail (or at least give a severe warning) when certain coding rules are not fullfilled.
I thought about programming something by myself but would like to know if there is already a plugin that does what we want.
Thanks!
You can use maven-checkstyle-plugin
to verify coding styles and to set style do you want, and other configuration
example:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<version>3.1.1</version>
<configuration>
<configLocation>checkstyle.xml</configLocation>
<encoding>UTF-8</encoding>
<consoleOutput>true</consoleOutput>
<failsOnError>true</failsOnError>
<linkXRef>false</linkXRef>
</configuration>
<executions>
<execution>
<id>validate</id>
<phase>validate</phase>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>
Not related to maven but you can use sonar.
Hey I am writing this since I spent some time trying to configure Jackson's ObjectMapper to work without #JsonCreator and #JsonProperty annotations on my DTOs. The result I wanted to achieve is to be able to run Spock's tests (groovy) in both intellij and in console with maven.
Since this issue is resolved: https://youtrack.jetbrains.com/issue/IDEA-125737 intellij automatically picks up below maven configuration:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<compilerArgument>-parameters</compilerArgument>
<testCompilerArgument>-parameters</testCompilerArgument>
</configuration>
</plugin>
Also if you want to use Spock for testing in groovy you need following plugin configuration:
<plugin>
<groupId>org.codehaus.gmavenplus</groupId>
<artifactId>gmavenplus-plugin</artifactId>
<version>${gmavenplus-plugin.version}</version>
<configuration>
<parameters>true</parameters>
</configuration>
<executions>
<execution>
<goals>
<goal>compile</goal>
<goal>compileTests</goal>
</goals>
</execution>
</executions>
</plugin>
plus additional information:
At the moment I was writing this there was only one version of groovy compiler that worked for me: 2.5.0-alpha-1
maven-compiler-plugin version I used was 3.7.0. Version 3.1 did not work at all. I did not try others.
I hope this saves someone some time :)
I noticed an unexpected behavior. I have an aggregation POM for the purposes of aggregated goals execution.
When I execute the build task, the modules included in aggregation POM have their javadoc generated. The javadoc generation is defined in parent POM (not the same as aggregation POM) like this:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<version>2.9.1</version>
<executions>
<execution>
<id>attach-javadocs</id>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
The child module has its own POM, in which an aspectJ plugin is defined like this: (this is how the build tag actually looks like as a whole in the child POM:
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>aspectj-maven-plugin</artifactId>
<version>1.6</version>
<configuration>
<source>1.7</source>
<target>1.7</target>
<complianceLevel>1.7</complianceLevel>
<verbose>true</verbose>
</configuration>
<executions>
<execution>
<goals>
<goal>compile</goal>
</goals>
</execution>
</executions>
<dependencies>
</dependencies>
</plugin>
</plugins>
</build>
Now, when I run the aggregation build, it generates javadocs with Java 1.8 (there is no mention about which java to use in aggregation POM):
Constructing Javadoc information...
Standard Doclet version 1.8.0
Building tree for all the packages and classes...
...
12 errors
16 warnings
But when I run build just on the child module, it will use Java 1.7.0_45
Constructing Javadoc information...
Standard Doclet version 1.7.0_45
Building tree for all the packages and classes...
...
2 warnings
Why this inconsistency? I would expect that the build should work the same. Am I doing something wrong? How does one configure the aggregation build to use the configuration of the child module (with its POM), which to me seems the way which should be default.
My assumption is that aggregation build is the same thing as running "install" goal on each child module manually as if on a seperate project. Is this assumption wrong? (seems like it is, since this behaviour) If yes, what is actually happening?
If information are missing (parts of pom configurations) please comment.
I already have a working solution where I can specify with maven which classes to not compile when using a particular maven profile.
But I would like to use a general solution and use an annotation instead
The current solution that I have is like
<plugin>
<!-- Exclude some web services used only for internal testing -->
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<optimize>true</optimize>
<excludes>
<exclude>**/something/*ClassPattern.java</exclude>
</excludes>
<testExcludes>
<exclude>**/something/*ClassPatternTest.java</exclude>
</testExcludes>
</configuration>
</plugin>
But Some thing like
#NotCompiledForProduction
would be rather nice on top of a class.
It seems to me that this might be hard (or impossible to do) without changing maven's behaviour. That is not the scope here. And this kind of annotation
You cannot (I assume) use an annotation to determine what source code gets presented to the java compiler, because you need to compile the source code in the first place to process the annotation.
It seems like you need to create different modules in your maven project: one that generates a jar file with the production code, and one module that generates a jar file with testing implementation with a dependency on the production artifact.
If the code really does need to be in the same maven module, then the code should always be compiled. You can however use maven-jar-plugin to create multiple artifacts at the package phase: the default artifactId.jar, and an artifactId-test-lib.jar artifact. You can do this by specifying multiple executions for the plugin, and using <includes> and <excludes> to split the jar files as required.
you can try this...
<build> <plugins>
<!-- Run annotation processors on src/main/java sources -->
<plugin>
<groupId>org.bsc.maven</groupId>
<artifactId>maven-processor-plugin</artifactId>
<executions>
<execution>
<id>process</id>
<goals>
<goal>process</goal>
</goals>
<phase>generate-sources</phase>
</execution>
</executions>
</plugin>
<!-- Disable annotation processors during normal compilation -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<compilerArgument>-proc:none</compilerArgument>
</configuration>
</plugin>
</plugins> </build>
I'm using the following in my project's pom.xml file. Running a findbugs:check goal still fails on all errors, even when no High priority errors are present. What am I doing wrong?
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>findbugs-maven-plugin</artifactId>
<version>2.4.0</version>
<executions>
<execution>
<id>failing-on-high</id>
<phase>process-test-resources</phase>
<goals>
<goal>check</goal>
</goals>
<configuration>
<threshold>High</threshold>
<onlyAnalyze>com.example.-</onlyAnalyze>
</configuration>
</execution>
</executions>
Looking at the documentation and trying it out on a sample codebase, it looks like findbugs:check goal
Fail the build if there were any FindBugs violations in the source
code.
This does not seem to depend on the value of threshold.
Also look at this blog entry which seems to describe a related problem.