I have installed Sonarqube 6.7.5 with several plugins, including the Sonar CSS plugin version 1.0.2.611. I ran a scan locally with "publish" mode and everything was good. But then when I ran a scan as part of a Team City job that ran with "preview" mode, I got this failure:
You must install a plugin that supports the language 'css'
I have my 6.7.5 version of Sonarqube running, and when I run a build using the new Sonarqube server, I get that message about the "css" language. None of the Team City build parameters are changing other than the mode--it works when I run in "publish" mode and it gives that error when I run in "preview" mode. My Team City builds use the Gradle sonar scanner (2.6.2).
I believe I haven't spelled the language name incorrectly. The Sonarqube server shows CSS listed under Quality Profiles, with a default profile set:
And it shows under the Quality Profile I am using for this project:
Here's the section from my Gradle build file:
sonarModules {
module {
name "CSS"
property "sonar.language", "css"
property "sonar.projectBaseDir", "."
property "sonar.sources", "jcr_root/etc/designs"
}
}
What could be causing this issue when I run it via the Team City build?
I never did totally figure it out, but here's how I resolved this:
The CSS plugin I had been using was the one listed on the Sonarqube plugins list: SonarCSS version 1.0.2.611
I removed this plugin and instead installed a different CSS plugin, the Sonar-css plugin from https://github.com/racodond/sonar-css-plugin/releases (version 4.18)
This different plugin works for me, both for Publish mode and Preview mode. I presume there is some issue with the module configuration in Preview mode with the plugin that the docs.sonarqube.org site uses. Maybe this will help someone else!
Related
Installed clean windows10(1607) and intellij idea(2020.1.2 community edition). When i create new gradle project
Invalid Gradle JDK configuration found. Open Gradle Settings
"gradle-wrapper.properties not found".
How can I fix it?
Install gradle 6.7
sdk install gradle 6.7
brew install gradle
Go to IntelliJ and set gradle version:
On File >> Settings >> Build, Execution , Deployment >> Gradle
or
Preferences >> Gradle
In Use Gradke from specific the correct location
If IDEA is set to use the Gradle wrapper (as it is in your screenshot: "Use Gradle from:" is set to "gradle-wrapper.properties"), IDEA expects the following file structure:
Gradle wrapper JAR: [project root]/gradle/wrapper/gradle-wrapper.jar
Gradle wrapper properties: [project root]/gradle/wrapper/gradle-wrapper.properties
Gradle wrapper script: [project root]/gradlew.bat
If you are missing one of these three elements, IDEA will attempt to generate the wrapper by calling the gradle wrapper task. It will do this using the Gradle JDK, which may or may not be the project SDK (File > Settings > Build, Execution, Deployment > Build Tools > Gradle > Gradle JVM).
I'm not sure how it selects the version of Gradle it uses - I only have 6.8.3 installed on my machine, and I had my wrapper properties set to 7.0-rc-1, yet somehow it used 6.7.0 when generating the wrapper.
I tried various options for clearing the cache, but did not get the result.
Openjdk-14 installed by default and does not work. From site adoptopenjdk.net install OpenJDK 11 (LTS). When creating the project, I chose 11 version. Then the program suggested updating gradle to version 6 and it worked.
I ran into this problem a while ago when I upgraded to intellij 2020.* The first time I created a new project there was no problem: gradle daemon did its work and the project was created with no problems.
In my case, the project would start a new gradle daemon, and attempt to build the project, would get rejected by windows Security, and nothing would happen, so intellij goes ahead and starts another (unsuccessful) daemon. Soon, I had 20+ gradle daemon processes running on my system, all of them doing nothing.
So, it looks like intellij has messed in enabling that it places the appropriate permissions it requires for these folders that it depends on to run properly. So, you need to manually give these permissions, and then things (should) work.
The real issue here is security on your machine: either a virus checker or the security software, Windows Security on Windows 10, for example. The first time you make a project, Intellij goes and produces a number of folders that they need access to.
However, once these folders are available, for whatever, intellij doesn't make sure to give itself access.
On windows 10, in AppData, you'll find several folders required by Intellij to produce, in my case, produce gradle projects.
Try finding the various folders that Intellij has produced on your system, and give them exceptions on your virus checker and on whatever firewall/security software programs that may block access.
I'm using a MacBook Air OS X 10.9 (Mavericks) and IntelliJ IDEA, but the IDE won't let me execute the test "ProjectImportedOKTest" which is in src/test/java/java_bootcamp/. I followed the exact same steps of this video:
https://www.youtube.com/watch?v=ZgKxjwImKAs&index=3&list=PLi1PppB3-YrVq5Qy_RM9Qidq0eh-nL11N
But for some reason my green arrow to run the test is always disabled. It could be something with the configuration option in the top left of IntelliJ, which I left blank or even something with gradle.
Thanks a lot!!
You can invalidate the caches of the intelliJ by using the option
file -> invalidate caches/Restart.
It helped for me.
There are several things you could try.
Ensure that your source java or kotlin folder is marked as "Sources Root". Do this by right clicking the folder and selecting "Mark Directory as"
Go to view -> Tool Windows -> Gradle and hit the refresh icon
Try opening the project a different way, such as importing the project or just opening the project
Rebuild the project and ensure there are no errors
Go to File -> Project Structure and ensure Java 1.8 is set as the Project SDK
Got to File -> Settings 0> Build, Execution, Deployment and select Gradle. Ensure Gradle JVM has Java 1.8 and that "Use default gradle wrapper" is selected.
Again under Settings and Build, Execution, Deployment, go to Compiler -> Kotlin Compiler and check that Target JVM version is set to 1.8
I ran into the same problem running on Windows and ran into this question trying to find the solution. It turns out Gradle wasn't installed on my machine and that was causing the problems.
According to the Corda Docs - "Gradle - we use 4.10 and the gradlew script in the project / samples directories will download it for you."
However, I installed from the Gradle website here - https://gradle.org/install/#with-a-package-manager -and configured it in the PATH variable. After doing so, my green arrow was enabled and I was able to run the test successfully.
I'm trying to do code analysis of Java unit test using maven sonar plugin. But the plugin doesn't seem to take into account my sonar properties "sonar.*". I've tried to modify simple examples and it did work either. According to MSONAR-70, the issue has been fixed and I'm using the version 2.4.
For the test, I've tried it on a simple case:
Clone sonar-examples.git
use the project sonar-examples/projects/languages/java/maven/java-maven-simple as example
Renamed src/main to src/test
In the pom.xml, add to the properties section :
<sonar.sources>src/test/java</sonar.sources>
<sonar.binaries>target/test-classes</sonar.binaries>
Run mvn sonar:sonar.
--> the code analysis didn't took into account my settings. The project is created on SonarQube but code as not been analyzed.
If I use the sonar-runner command line, it's analyzing the code:
sonar-runner [...] -Dsonar.sources=src/test/java
-Dsonar.binaries=target/test-classes
-Dsonar.language=java
-Dsonar.sourceEncoding=UTF-8
-Dsonar.projectKey=org.codehaus.sonar:example-java-maven
-Dsonar.projectName="Simple Java Maven Project"
-Dsonar.projectVersion=1.0-SNAPSHOT
According to a previous revision of the question, the OP solved their problem like this:
We were using SonarQube 4.0 version. Updating the version to 4.4, made the properties be taken into account.
That was in 2014; the current version now is 5.5.
The steps to upgrade can be found here:
Stop the old SonarQube server
Download and unzip the new SonarQube distribution in a fresh directory, let's say NEW_SONARQUBE_HOME.
Start it using the default H2 database and use the update center to install the plugins you need.
Manually install any custom plugins.
Stop the new server.
Update the content of the sonar.properties and wrapper.conf files located in the NEW_SONARQUBE_HOME/conf directory with the content of the related files in the OLD_SONARQUBE_HOME/conf directory (web server URL, database settings, etc.). Do not copy-paste the old files.
If a custom JDBC driver is used, copy it into NEW_SONARQUBE_HOME/extensions/jdbc-driver/.
Back up your database.
Remove the data/es directory.
Start the new web server
Browse to http://localhost:9000/setup (replace "localhost:9000" with your own URL) and follow the setup instructions.
I am getting this error while importing an adt project(after exporting and creating gradle file) into Android Studio on mac os x.
The android-studio version is 3.6 (latest) and the gradle version is 1.8 (latest).
The error shows up as:
Unsupported method: GradleProject.getBuildScript(). The version of
Gradle you connect to does not support that method. To resolve the
problem you can change/upgrade the target version of Gradle you
connect to. Alternatively, you can ignore this exception and read
other information from the model.
Consult IDE log for more details (Help | Show Log)
I have no idea where to look for IDE logs...
I was getting a similar error today opening a project after upgrading to Android Studio 0.3.6. Here is what I had to change to get it working again for me.
Changed the following line in gradle-wrapper.properties from gradle-1.6-bin.zip to gradle-1.8-bin.zip
distributionUrl=http://services.gradle.org/distributions/gradle-1.8-bin.zip
Also changed the following line in build.gradle from 0.5.+ to 0.6.+
classpath 'com.android.tools.build:gradle:0.6.+'
In Windows, gradle-wrapper.properties is located at \project folder\gradle\wrapper\gradle-wrapper.properties
build.gradle is located at \project folder\module folder\build.gradle
The Files that Needed changed are highlighted in the project explorer screen shot below.
After those changes I sync'd the project with the gradle files and then could build and test.
Hope that helps.
Note that you should use default or customizable gradle wrapper:
Maybe, this question is silly but I'm very new. I try to search without luck.
I got two errors when building maven project with sonar:
No information about coverage per test.
Although I had test code and these testing classes cover the code.
The global property 'sonar.doxygen.deploymentPath' is not set. Set it in SONAR and run another analysis.
I dont know it should be set where in sonar server. I set in web.xml or sonar-server.properties but it does not work.
Thanks.
About the first warning message this is not an error but a warning : since Sonar 3.5 this is possible to get the code coverage relating to each unit test. Here the message just says that this feature is not activated which is expected by default. Nevertheless I do agree that this warning message can be misleading.
About the second error message, I don't know the doxygen plugin but the message seems to be pretty clear : the sonar.doxygen.deploymentPath property has not be defined. See the plugin documentation : http://docs.codehaus.org/display/SONAR/Doxygen+Plugin.
Two things:
There is no war folder anymore since the sonarqube has given up tomcat support
The doxygen plugin is not implemented to upload the files in to the sonarqube server &/ installation, which means it only can be done by referencing the path inside your installation, e.g.:
run "mvn install sonar:sonar" in your project "/root/test.example.sonar.com"
in sonarqube set the cfg-key "sonar.doxygen.deploymentPath" the value: "/root/sonarqube-4.1.1/web/" and the cfg-key "sonar.doxygen.deploymentUrl" the value: "http://:9000"
have fun with your doxygen
Remember that the plugin will only be run through your mvn cmd, refreshing the page only will not do the job, you will have to analyse again after each cfg set :/
Check the file system and folder permission