I have SonarqubeServer(Version 5.6.3), in which I have added two custom rules for java successfully, both are also visible in rule list.
Problem: I am also using Sonarlint for local eclipse issue. As usual their is sync issue for external plugins used by SonarqubeServer(PMD,FindBug,CHeckStyle). It is fine I have managed this.
So Now my question is that, will Sonarlint able to sync my newly added custom rules to SonarQubeServer?
if Yes then why I am not able to see those custom rule effect and reporting in eclipse classes.
Not sure about this, but i have activated Sonarlint support in pom.xml and it works for me. Here is the relevant entry, see <sonarLintSupported>:
[...]
<build>
<plugins>
<plugin>
<groupId>org.sonarsource.sonar-packaging-maven-plugin</groupId>
<artifactId>sonar-packaging-maven-plugin</artifactId>
<version>1.17</version>
<extensions>true</extensions>
<configuration>
<pluginClass>com.foobar.java.JavaRulesPlugin</pluginClass>
<sonarLintSupported>true</sonarLintSupported>
<sonarQubeMinVersion>5.6</sonarQubeMinVersion>
</configuration>
</plugin>
[...]
Related
Exit code: 1 - javadoc: error - The code being documented uses packages in the unnamed module, but the packages defined in https://docs.oracle.com/en/java/javase/11/docs/api/ are in named modules.
Has anyone been able to make javadoc work without having to change the source version to 1.8 (as suggested in other forums)? I'm using JDK v11.0.5 and the issue still present (also with JDK 12+).
Edit: This error originated from maven and thrown by the maven-javadoc-plugin. I have not been able to make it work for JDK 11+ even with the <source>8</source> configuration.
As suggested in OpenJDK issue tracker this can be worked around with defining source on Javadoc plugin:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<configuration>
<source>8</source>
</configuration>
</plugin>
Adding <detectJavaApiLink>false</detectJavaApiLink> to the Maven javadoc pluging configuration fix the error
I needed the bit from Carlos Santos to make this really work. The complete config that incorporates his answer is:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<configuration>
<source>8</source>
<detectJavaApiLink>false</detectJavaApiLink>
</configuration>
</plugin>
javadoc produces links to packages you use, e.g. to classes documented in .../javase/11/docs/api. While your comments are in an unnamed module, the targets are not, and javadoc can't combine those two. It produces either a package-list or an element-list file, so you can't mix unnamed modules (packages) with named modules.
I didn't find a way to limit the links that javadoc tries to produce; so you may have to use modules for your own project. This seems ridiculous to me, just to make javadoc happy. I guess this is just one of the reasons that so many people stick to Java 8.
I was able to get my own project to work by using a new version of the compiler plugin and setting the release property to 8.
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.1</version>
</plugin>
<properties>
<maven.compiler.release>8</maven.compiler.release>
</properties>
I was facing the same issue. I was using Java 11.0.3 and org.apache.maven.plugins:maven-javadoc-plugin:2.10.4:jar. Updating the maven-javadoc-plugin version to 3.2.0 worked perfectly for me.
We can use <detectOfflineLinks>false</detectOfflineLinks> in the configuration.
I'm working with a project that has, historically, been supported and developed in an Eclipse environment. I'm hoping to move this over to Intellij, and I'm currently using the full (Ultimate) package.
There are a few intricacies of the build process that don't appear to be working, which relate to selectively building the resources for the project. I could work around this, but would rather try and understand why IntelliJ and Eclipse are building the same project in a slightly different way.
I've noticed in my parent POM that the following code has an issue:
<plugin>
<groupId>net.alchim31.maven</groupId>
<artifactId>yuicompressor-maven-plugin</artifactId>
<version>1.2</version>
<configuration>
<includes>
<include>**/*.js</include>
</includes>
<nosuffix>true</nosuffix>
</configuration>
</plugin>
Intellij is saying element includes is not allowed here' and itcannot resolve symbol 'include'`.
As far as I can see, the declarations are valid and in the correct place, and maven appears to be set up as required with the maven plugins installed as required too. The POM uses the http://maven.apache.org/maven-v4_0_0.xsd schema.
This kind of stuff has generally been left untouched for a number of years, but I can't see why it is having issues with this particular symbol/declaration?
As above, I've checked the plugins, Maven settings, all the usual suspects. Another of the plugins uses <excludes> with no errors, which makes it a bit more of a puzzle to me?
Can anyone help?
Does anyone have a clean example of a maven project preprocessing class annotations at compile time with subsequent generation of classes to be compiled in the same compilation process?
Does anyone have a step-by-step procedure to implement such a project?
After navigating a lot in existing documentation on the net, I came up with the following:
What needs to be clarified:
In order to process annotations on a given project P, you first need an annotation processor compiled in a separate library S. P should have a dependency on S.
Implementing annotation processing in Java 5 is absolutely not the same thing as in Java 6.
Java 5 relies on a separate execution of apt. The corresponding tutorials here and here help understanding the basics of annotation processing and implementation in Java 5. Good reading for newbies.
Implementing annotation processing in Java 5 with Maven is tricky. One needs to add a local dependency to tools.jar to access the API described in these tutorials. Not clean. Some third-party plugins calling the apt are available, but not well documented.
Those using Java 6 should not jump-start implementing their processors according to the above tutorials.
Annotation Processing in Java 6 with Maven
A new package has been delivered in Java 6 to process annotations: the Pluggable Annotation Processing.
To implement a processor, create a separate Maven project. The above tutorial or this one explains how to proceed. This is our library S.
Then, create your project P and add a Maven dependency on S.
There is currently an issue with the maven-compiler-plugin, but a workaround is available here. Use it to compile your generated code as part of existing annotated code.
...and code generation
A great Java code generation library called CodeModel is available from Maven central. A good tutorial is available here. The javax annotation processing package offers some tools to generate output too.
maven-processor-plugin can do that...
https://code.google.com/p/maven-annotation-plugin/
Example from documentation:
<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>
The Maven-Antlr-Plugin exactly does this. It generates Java classes from a grammar and the compile plugin compiles the generated classes. May it might be usefull the maven-annotation-plugin
I am using PMD maven plugin for my project and I am seeing very strange behavior in it. The following pom.xml configuration fails the build with violations in basic.xml -
<configuration>
<rulesets>
<ruleset>${project.basedir}\ruleset\basic.xml</ruleset>
<!-- ruleset>${project.basedir}\ruleset\braces.xml</ruleset>
<ruleset>${project.basedir}\ruleset\design.xml</ruleset>
<ruleset>${project.basedir}\ruleset\controversial.xml</ruleset>
<ruleset>${project.basedir}\ruleset\coupling.xml</ruleset>
<ruleset>${project.basedir}\ruleset\clone.xml</ruleset>
<ruleset>${project.basedir}\ruleset\comments.xml</ruleset-->
</rulesets>
</configuration>
But the below one passes the build smoothly -
<configuration>
<rulesets>
<ruleset>${project.basedir}\ruleset\basic.xml</ruleset>
<ruleset>${project.basedir}\ruleset\braces.xml</ruleset>
<ruleset>${project.basedir}\ruleset\design.xml</ruleset>
<ruleset>${project.basedir}\ruleset\controversial.xml</ruleset>
<ruleset>${project.basedir}\ruleset\coupling.xml</ruleset>
<ruleset>${project.basedir}\ruleset\clone.xml</ruleset>
<ruleset>${project.basedir}\ruleset\comments.xml</ruleset>
</rulesets>
</configuration>
The build should have failed in the second scenario also. As per what I have noticed, if the last rule (in above example comments.xml) does not have any code violation then the build will not break even if any of the rulesets above it (basic.xml, braces.xml, etc.) have code violations. I am unable to understand the reason behind this behavior. Can someone help me out with this?
I found the issue. There was an issue with Maven Plugin version 3.3 . Now I am using version 3.1 and the exact same code is working as expected.
Is there a Checkstyle rule file with the Google Java Style?
The checkstyle team added it several days ago. Here it is :
https://github.com/checkstyle/checkstyle/blob/master/src/main/resources/google_checks.xml
If you have a maven-project, you can easily integrate google_checks (you have to use at least maven-checkstyle-plugin version 2.17)
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<version>2.17</version>
<configuration>
<configLocation>google_checks.xml</configLocation>
</configuration>
</plugin>
Executing checkstyle will use google_checks, e.g. do
mvn checkstyle:checkstyle
Version-background
Checkstyle-project integrates google_checks from version 6.9 on.
Maven-checkstyle-plugin version 2.17. is the first one, which is released after checkstyle6.9 (actually it uses checkstyle6.11.2). So, maven-checkstyle-plugin2.17 is the first version of this plugin, which actually ships with google_checks and provides it without any other dependency.
The Google Summer of Code project to create such a file implies, that it doesn't exist yet.
google_checks.xml comes with Checkstyle and the maven plugin.
See Google's Java Style Checkstyle Coverage,
also see Maven Checkstyle Plugin's config
Note that if you are going to customize the config based on google_checks.xml, you need to download the xml of the matching checkstyle version (on github), and modify on top of it.