We are currently using sonar 4.3.3 release.Here we had uninstalled
sonar-java-plugin-2.1.jar and had moved to sonar-java-plugin-2.5.1.jar
Parallely we had removed the other related plugins also i.e :
sonar-surefire-plugin-2.1.jar
sonar-jacoco-plugin-2.1.jar
sonar-squid-java-plugin-2.1.jar
sonar-findbugs-plugin-2.1.jar
Now the problem we are facing is after our quarterly maintenance activity is over and sonar-server restart happens, Sonarqube update-center is downloading the uninstalled old plugins on restart.
List of such plugins:
sonar-surefire-plugin-2.1.jar
sonar-jacoco-plugin-2.1.jar
sonar-squid-java-plugin-2.1.jar
sonar-findbugs-plugin-2.1.jar
This is causing the sonarqube auto restart to fail with below-given error
2017.01.29 20:32:43 ERROR [o.s.s.p.PlatformServletContextListener] Fail to start server
org.sonar.updatecenter.common.exception.IncompatiblePluginVersionException: The plugins 'jacoco' and 'java' must have exactly the same version as they belong to the same group.
Please guide if there is any way to disable this behaviour.
Have checked the extensions/downloads/ folder also and no jars were present there.
The jars were present in lib/bundled-plugins folder.Removing from there solved my purpose.
Related
(On Elasticsearch version 6.5.1)
How can I build/run Elasticsearch from source with local plugins?
I've tried the following command to install the plugins:
./distribution/build/cluster/run\ node0/elasticsear-6.5.1-SNAPSHOT/bin/elasticsearch-plugin install file:/<path_to_plugin_zip> and that says it successfully installed the plugin.
However, when I run elasticsearch via ./gradlew run --debug-jvm, it cleans out the contents of that directory before running ES.
The reason I installed the plugin into that particular directory is that I put a debugger in the PluginsService.java file, and saw that the Path pluginsDirectory parameter in the constructor was set to /Users/jreback/Desktop/elasticsearch/distribution/build/cluster/run node0/elasticsearch-6.5.1-SNAPSHOT/plugins.
So, how can I get my plugin installed on my local ES version and run ES such that the plugin code doesn't get removed as the process starts up? Many thanks in advance!
FWIW, I got this working with some manual code changes (there may be or likely is a more recommended way to do this, but this worked for me).
In my ES checkout, I made the following code change to server/src/main/java/org/elasticsearch/env/Environment.java:
replace this line: pluginsFile = homeFile.resolve("plugins"); with pluginsFile = Paths.get("<path to plugin directory");
(Also, you must import java.nio.file.Paths at the top of that file).
The directory structure for the directory you listed above should look like this:
- plugin parent directory (should whatever you put in the Environment.java file)
- plugin directory (name of the plugin)
- plugin-descriptor.properties file
- plugin jar file (generated from building the plugin in some prior step)
Then you should see that it loaded the plugin you've just added in the logs when you start up ES again.
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!
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 having issues with Jenkins that I am unable to resolve, and all the solutions I've found online I've used in the past, but are not helping.
I am on windows 2008r2, utilizing svn, jenkins version 1.407.
Initially the service failed, and was not resolved with past methods. In the past I have successfully troubleshoot Jenkins by killing hung processes, restoring the war file, ect.
I have attempted a new install with bringing over the files in the jobs folder. The end result was a partially functioning Jenkins would attempt a build it would report no change and not update.
What I'm trying to determine is a list of files/folders beyond the jobs folder that I need to move to the new install. The initial install predates me and was Hudson. The folder has a number of obviously obsolete files and folders (both a jenkins.war and a hudson.war)
Go to Jenkins home folder and collect:
all ./*.xml files in - these are configuration files for plugins and jenkins itself
users/* in case you have security enabled
subversion-credentials/** and secrets/** for any kind of keys provided in jenkins to access svn or other resources
plugins/*.*pi folder for all plugins - you don't need to have the unpacked folders
jobs/*/config.xml - to retrieve all job configurations; jobs/*/nextBuildNumber if you care to continue build numbers
plugins may create additional folders which you may want to use
with that you should recreate Jenkins as it was. Pay especially attention to config.xml file in root folder - this holds main jenkins configuration. If your issue reproduces on new system most likely a plugin is cause for problems - in that case review log files most likely you will find out which plugin causes trouble.
You didn't indicate if you tried new setup with same version of Jenkins or newer one; if you are using newest version it may be that ssh key handling / svn authentication for each job needs to be updated as somewhen in last few months authentication / security handling changed. Best is to look into Jenkins release log.
I'm using Jenkins 1.55x on CentOS installed as RPM; given that it is a webapp I assume Windows 1.4x setup is similar.
I have the latest version of Jenkins, and I launched it with
"java -jar jenkins.jar."
Then I got an error
????: Failed Loading plugin rest-plugin hudson.util.IOException2: Unable to create instance of org.hudsonci.rest.plugin.RestPlugin from rest-plugin
After that, when I visit Jenkins at localhost:8080, Jenkins shows "New version of Jenkins (2.1.0) is available", and download link to Hudson.war 2.1.0**
Did the Jenkins merge back into Hudson? As far as I know, most people are saying Jenkins will be better than Hudson.
Is there anybody that knows what happened?
It sounds like what happened is this: you kept your old settings when you upgraded to Jenkins. This included the update URL, so Jenkins is polling the old Hudson url for updates. Once you fix this, you should be golden. To fix it, just do this:
Under Manage Jenkins, go to Manage Plugins and click on the advanced tab. Make sure that the Update URL is set to http://updates.jenkins-ci.org/update-center.json