trying to make a multi module project I dowloaded the samples in github: I use this folder
https://github.com/SonarSource/sonar-examples/tree/master/projects/multi-module/sonar-runner/java-sonar-runner-modules-own-configuration-file as a project base dir
In a command line in this folder, I type /opt/sonar-runner/bin/sonnar-runner
First thing I find is that sonar-project.properties has a property named sonar.sources=src, but executing throws
Exception in thread "main" org.sonar.runner.RunnerException: You must define mandatory properties: sources
Then I correct this property with sources=src and runner execution finish, adds the project to my sonar server, but no code, modules or file is detected. It is like if all project is empty.
It is exactly the same with other examples and with my own project. No matter if is java, python...
Any help is welcome
You are using an old version of Sonar Runner and/or Sonar. Please update to the latest versions (Sonar Runner 2.2 and Sonar 3.5.1).
Related
How do I setup a Rascal-MPL project to consume the DSL built with Rascal?
I don't seem to find any resource that details how to solve that particular problem
The documentation hasn't been written for that case but here goes:
Use newRascalProject from util::Reflective to create a basic setup. For both the DSL project and the consuming project that makes sense.
mvn install in the DSL project, if you won't have the DSL project folder open in Eclipse or VScode or if you are working bare bones Unix/Maven.
In RASCAL.MF of the client project add Require-Libraries: |lib://dsl-project|
In pom.xml of the client project add a dependency on the DSL jar.
Restart the console or terminal for a file of the client project.
In the terminal the active version of the path configuration for the interpreter will be printed. It should have the DSL project in the list of srcs.
In VScode log for the Rascal LSP you can see the path configuration printed when compiling/checking source files in the client project. There the DSL project should be in the libs path.
If the DSL project isn't compiled to .tpl files that appear in the target folder and eventually in the jar, you will get spurious error messages in the client code. In that case trigger the compiler in the DSL project by saving the top module, or run mvn install again. Revisit the pom file for the settings of the rascal-maven-plugin
For those landing at this page and trying to find an example of calling newRascalProject with working parameters...
The first parameter is a 'location'. While it is documented how to use this parameter (https://www.rascal-mpl.org/docs/Rascal/Expressions/Values/Location/), it still took my some time to figure out that a location is not a regular string, and not using double quotes " but |.
So if you try:
newRascalProject ("home:///Projects/rascal_playground", "hello2")
You get the following error:
Advice: |https://www.rascal-mpl.org/docs/Rascal/Errors/CompileTimeErrors/UndeclaredVariable/UndeclaredVariable.html|
Including the variable name for the 2nd parameter...
newRascalProject ("home:///Projects/rascal_playground", name="hello")
... gives the same error.
This is the correct example:
newRascalProject (|home:///Projects/rascal_playground|, name="hello")
When doing an ant build (thought jenkins) for a test project, I get the below error. As this test project will be deployed in tomcat why does the build require a netbeans specific module
Obviously I can add the jar file to a path in jenkins and then continue the build, but want to know why it needs a netbeans specific jar?
Is it because the project setup in Netbeans is wrong?
Thanks in advance.
Tony
======Error below here =========
var/lib/jenkins/workspace/DeployTest2/nbproject/build-impl.xml:797: The libs.CopyLibs.classpath property is not set up.
This property must point to
org-netbeans-modules-java-j2seproject-copylibstask.jar file which is part
of NetBeans IDE installation and is usually located at
/java/ant/extra folder.
Either open the project in the IDE and make sure CopyLibs library
exists or setup the property manually. For example like this:
ant -Dlibs.CopyLibs.classpath=a/path/to/org-netbeans-modules-java-j2seproject-copylibstask.jar
I'm running sonar scan with following versions:
ant v3.0.5
sonar v4.5.4
sonar-ant-task v2.3
My ant project contains 100+ submodules; about half of them have external libs, and half don't
In my ant build file, following sonar properties are set:
sonar.projectKey = com.foo:bar
sonar.projectName = foobar
sonar.projectVersion = ${build.version.major}.${build.version.minor}.${build.version.subminor}
sonar.sourceEncoding=UTF-8
sonar.language = java
sonar.sources = src
sonar.java.binaries = build/classes
sonar.java.libraries = build/dependency/*.jar
Initial problem with above is that for the modules that don't have external libs, it fails since there's no jar inside /build/dependency after compilation.
According to this archive link: http://sonarqube-archive.15.x6.nabble.com/Analysis-aborts-because-of-quot-No-files-nor-directories-matching-lib-jar-quot-td5035215.html
I should be able to change the libraries property to
sonar.java.libraries = build/dependency/*
But this did not work for the combination of app versions i listed above. Using only "*" results in class not found error so i don't even think it correctly grabs the dependency jar files.
Could anyone advise if i'm using incorrect combination of the versions, or if this have regressed?
My current workaround:
Keep the "*.jar" as default project property, and add individual module's libraries property to the empty folder for those that do not have dependency jar. e.g.
module1.sonar.projectName=module1
module1.sonar.projectBaseDir=modules/module1
module1.sonar.java.libraries=build/dependency
module2.sonar.projectName=module2
module2.sonar.projectBaseDir=modules/module2
module2.sonar.java.libraries=build/dependency
... x 50 more of these
Is there more elegant solution?
thanks,
Scott
sonar.java.libraries property is handled by the SonarQube Java plugin. Please provide its version and if it is not the latest try to update.
You're on the right track. The analysis of Java multi-module projects is only easy for Maven users. :-(
I have a multi module project set up for sonar analysis using way #2 from Analyzing with SonarQube Runner.
The only difference is that I dont use a global sonar-project.properties file.
The global properties are defined in jenkins in the sonar runner build step.
This works perfectly fine with Sonar Runner 2.3.
As soon as I switch from 2.3 to Sonar Runner 2.4 this fails with the error that the mandatory sonar.sources property is not defined.
I have tried setting it in my global properties to sonar.sources=src but then sonar can't analyze a module that doesn't use src as source folder.
It looks to me like Sonar Runner 2.4 doesn't use the module's sonar-project properties anymore.
Or is there a way to tell Sonar Runner 2.4 to use the module's sonar-project.properties file?
The two supported layout when using SQ Runner are:
put all properties of all modules in root sonar-project.properties file
put each module properties in its own sonar-project.properties in addition to the root sonar-project.properties
It is also possible to add properties via command line (this is what you do when you define properties in SQ Runner build step).
Your attempt to not have a root sonar-project.properties but having individual sonar-project.properties files in sub modules was not identified as a supported use case. So I'm not very surprised it is no more supported (it was likely a side effect).
See http://docs.sonarqube.org/display/SONAR/Analyzing+with+SonarQube+Runner#AnalyzingwithSonarQubeRunner-Multi-moduleProject
Im trying to run a sonar analysis on a Jenkins Job. Im using ant so im using Sonar Runner and sonar.properties in the projects. Im configuring the the binaries to
sonar.binaries=build/ant/classes
After a successfull build Sonar starts and is running a while. But i get a lot of warnings during bytecode analysis.
Im getting WARN XX - Class 'XX' is not accessible through the ClassLoader.
for every class...
I dont really know why classes are all there?
These are warnings issued by Findbugs, which requires access to source, compile binaries and 3rd party libraries.
To resolve these warnings you need to include an additional sonar.libraries property, populated with the 3rd party jars your code depends upon (See Analaysis Parameters documentation)
I actually had the same problem, but that was because of an issue with the maven caches.
I had run mvn clean install in the directory on my local machine, but was running sonar on the directory on a virtual box. This resulted in classes not being found.