What is the difference between the Sonarqube java plugin repository under rules>repository> Sonarqube Java rules and the default profile Sonar way under quality profiles. The first one has 322 rules, while the second one has 229. What is missing from the Sonar way profile? I am using Sonarqube 5.2 server.
First, the version of your Java Plugin is more relevant than the version of your SonarQube server. The server ships with a copy of the Java plugin, but the two are versioned independently, and it can never be assumed that you're running the version of the plugin that ships with the server.
To answer your question, the Sonar Way profiles are designed to be absolutely non-controversial out of the box. So rules about what line '{' should be on, for instance, aren't included. There are also rules that are desirable only in certain coding situations. For instance, not everyone is going to be interested in the proper use of Struts, so those get left off too.
Related
We have a repository built using Java 8. There are multiple rest services within the repository. We want to migrate to Java 11 and trying to figure out the best way of doing this. We are considering doing module by module. For example changing one service over to Java 11 while the remaining are still Java 8. We are unsure if Maven supports this?
Disclaimer: This is not an answer but just a partial report of my recent experience. Feel free to flag this answer if you feel that it doesn't meet the SO standards.
Does Maven supports this?
Yes, use the compiler plugin 3.8.0/3.8.1
However this migration requires addition care.
Recently we did something like this by migrating from ORACLE JDK 8 to OPENJDK 11. As we have houndreds of repositories with different missions, we faced all kind of problems. Just to cite some that I got here in my e-mail box tagged as [jdk11_migration]:
It is quite obvious but I'd like to highlight that in order to migrate from java 8 to 11 we have to meet the requirements from java 9 and 10 as well
Some maven plugins like cobertura do not support Java 11 and I guess they will never support it. In some cases, these plugins have reached the abandoned life cycle stage. The solution was looking for alternatives in a case to case manner. For example, we replaced cobertura by Jacoco.
rt.jar and tools.jar have been removed! Everything you have explicity refered from them will probably break.
some classes which we shouldn't use in java 9 or less now in java 11 no longer exist. I'm talking about to access classes in packages like sun.*, sun.misc etc. The solution is to look for a one-to-one replacement or refactor the code to avoid the usage.
Reflection usually is the last bullet to use and, for these cases, in java 9 and above we geta warning messages like:
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by ...
WARNING: Please consider reporting this to the maintainers of ...
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
Although it is not exactly a solution, there is a flag to get rid of this warning --illegal-access=permit . This is particulary important when using surefire maven plugin.
Java 9 introduced the module system then "now" we have the phenomena of clash of packages. For example, messages like "The package org.w3c.dom is accessible from more than one module: , java.xml" . The solution is to find the source of reduntant inclusion (notably duplicated maven dependences or dependences of dependences) and remove it.
Althought it wasn't a problem for us, I just noted that your repository consists in REST components in majority. Probable you will face ClassNotFound issues regarding some packages like javax.xml.bind which were basically dropped out of java standard edition. You can fix it by including they explictly in your pom.xml.
Luckly you may find good questions & anwswers for each issue you will find in your migration here in SO or over internet. There are some migration guides in the wild which are good start points. Specific issues, like obfuscation and IDE integration, can take a little bit of time, but, at least in my experience, this migration was painless than I have supposed.
My suggestion is to upgrade the entire project. Try to have some Java8 and some Java11 modules can be very difficult. As you already know, starting from Java9 module appears. The answer is very generic, so it's difficult to give a detailed response. I suppose:
Your project is managed with maven
You have many artefacts (jar)
You are using some library or framework (who said Spring?)
You are using a Source Version Control (Git or Subversion for example)
You have a multi-module project
The code you wrote works on Java8 and on Java11 platform
My suggested plan:
Create a branch on your SVC for Java11 project's version and start to work on it.
Create a parent module for common definitions
Upgrade maven plugin and all your library to the latest version. For Maven compiler set the Java11 target (the Java11 is supported only by the latest version of Maven Compiler Plugin).
For each module define the exported packages (and specify which packages are required)
If there are many modules, start with only a few of them and then include the remains.
If it can help you, let have a look at this simple project on github (It target Java11 and it's a multi-module Maven project).
Hope it helps.
I'm using SonarQube 6.3.1 with default profile Sonar way. I have the newest SonarJava plugin installed (4.8.0.9441).
I can see that the rule SQL binding mechanisms should be used is activated.
I have installed SonarLint 2.9.0 plugin for Intellij and connected to running SonarQube server.
After copying example violation from Sonar page I can see in my IDE that plugin works fine. Everything seemed perfect up to this moment.
Unfortunately, analysis on SonarQube server doesn't find this vulnerability. The same goes for another owasp-a6 rule Cookies should be secure (also found by Sonarlint). But on the other hand, some owasp rules work (i.e. Console logging should not be used).
Is this a known Sonar issue that some rules are omitted? Exclusions are not a problem, I'm pretty sure that those files are being analyzed because some other issues have been found.
We have Eclipse Java EE IDE for Web Developers.
Version: Luna Release (4.4.0)
Build id: 20140612-0600
I have installed SonarQube Plugin in my eclipse and have configured the SonarQube Server. Tested the Server connection in Eclipse.
Windows>Preferences>Sonar>Servers. Connection is successful.
I am able to associate my project to Sonar in eclipse and get the report locally.
After fixing the violated issues , Is there a way we can publish the new report from our Local to the SonarQbe server dashboard.?
First, you appear to be using an old version of the plugin; the most recent version of SonarLint for Eclipse has not yet re-established the connected experience (although that's coming soon). You may be interested in upgrading because SonarLint checks your code as you work; there's no longer a need to trigger the analysis. This way, issues are brought to your attention immediately instead of your having to remember to look for them.
Now to your question: there is not a way to push your updated results from Eclipse directly into the SonarQube platform; you'll need to perform a full analysis. Keep in mind that in-IDE analysis runs most but not all rules. I.e. you're not going to get issues in Eclipse from the rule about too-low coverage thresholds, for instance. Ditto duplicatons. Those are only run as part of the full analysis.
How I can make maven to download only java 1.6 compatible libraries?
I have tomcat 6 and java 1.6.0_38. Or how I can find incompatible libs?
http://pastebin.com/WnwZL2RX list of dependencies.
If it's a one-time task which you have to run over the list your have provided then I would propose a manual approach described here:
What version of javac built my jar?
As for automatic check then you would have to implement your own maven plugin which will use similar approach to the one described above or drill into JAR manifest in order to get the Java version.
A very interesting question i hope to be able to check back for a more satisfying answer.
Maven is not able to perform such a task - and as faar as i know (i only checked back with a 5 minute websearch) there is no plugin available for this task.
In the end Maven supports with the dependency management by resolving dependencies of dependencies and has default approaches when it comes to versions of the same dependency ("the closest version wins") - regardless of this you will be in charge when it comes to compatibility between your own source and third party source.
Especially when talking about runtime incompatibility this could be a quite hard task to find out about issues.
I'm currently coding a plugin for sonar ( custom rules ) . Which JDK and API should I use in order to be compatible for teh majority of sonar instances ? JDK6 ?
Thanks for your response
From the Sonar website
Prerequisite
The only prerequisite for running Sonar is to have Java (Oracle JRE 6
onwards) installed on your machine.
Check more details here
You can use Java 6 onwards It is also mentioned in the SONAR web site.
As said above you can use Java6. Indeed you must use Java6.
When a sonar analysis is launched, the launcher of the analysis (sonar runner or maven) will use your sonar instance as a plugin repository. This means that each jar plugins will be downloaded on the machine performing the analysis. Then each plugin will be asked if it should be executed or not.
Hence, if a plugin is built using Java7, you need to run sonar using Java7 and you also need to run any analysis with Java7, even if this plugin is disabled.