Setup sonar-runner for multiple java projects - java

I am trying to run sonar-runner to analyze multiple Java projects in one go. According to the documentation it is just a matter of creating a sonar-project.properties file for each project. But it is not clear to me where exactly I have to put these sonar-project.properties files.
I tried to add multiple .properties files in the $SONAR_RUNNER_HOME/conf folder but the runner does not seem to pick them up. It only sees the sonar-project.properties file.
Any suggestions on how to run sonar-runner for multiple projects?

Actually it is quite simple to let the sonar runner analyze multiple projects as long as they are in the same file system. Just put a properties file in a directory that is not to far away from the projects. Then declare each of your projects in this properties file.
Lets assume you have 4 projects in dev/general/BasicStuff, dev/service/CoolStuff, dev/utility/UtilStuff and dev/display/FrameWorkStuff.
As described in hereWay #2 you create a file in dev which contains the line
sonar.modules=BasicStuff,CoolStuff,UtilStuff,FrameWorkStuff
And for each of the "modules" a line like
BasicStuff.sonar.projectBaseDir=general/BasicStuff
CoolStuff.sonar.projectBaseDir=service/CoolStuff
Inside the project directories you in turn create a file which contains the other needed information, e.g.
sonar.projectName=BasicStuff
sonar.sources=src
If you start sonar runner with the top level properties as target you get a comprehensive result which shows metrics across the projects as well as allowing you to drill into each of them.
Hope this was what you were looking for.

The Sonar runner supports projects with multiple modules. It doesn't support the analysis of multiple projects in one invocation.
The Java runner needs to be run against each project, picking up the properties file in each project directory.

Since 2.0, Sonar runner works with multiple modules, as described here

Related

what is the equivalent project file for a Java project?

What is the equivalent project file for a Java project? For example, a C# project file is denoted by the delimiter of .csproj. So what would it be for a Java project? Is it dependent on what IDE I am using for Java?
I did some search online about this and it seems to me that the answer to this question is dependent on the IDE. From memory, it seems to me, that all I have to do is drop the Java files into an IDE and then, somehow, a project file is automatically generated. I do not want to be steered in the wrong direction on this and so I want to first ask around for guidance.
You're probably looking for the build file, not the IDE project definition.
Is it dependent on what IDE I am using for Java?
Yes. IntelliJ has .iml files, and Eclipse has .project (that's not a file ending - that's the file), as well as .classpath, .factorypath, and more. But, many of these are effectively generated or just refer to the build file. In C that tends to be called Makefile, in the Java ecosystem, Gradle and Maven are the 2 most popular build tools; they have build.gradle and pom.xml respectively. These would be more useful as basis for knowing how a project is 'put together', so to speak.
From memory, it seems to me, that all I have to do is drop the Java files into an IDE and then, somehow, a project file is automatically generated.
That's very basic and should rarely work except for the simplest projects. For example, most Java projects have source files, test files (also source files but they are not part of the distribution), and resource files (non-Java files that are also needed for the app; think about the images for the icon on a button), as well as a ton of dependencies (third party libraries used by the Java app).
Given that folks like many IDEs, the IDE 'config file' is not what you are looking for, and many projects don't even check these into source control (and probably shouldn't). Together with the source, you have a build file. This build file knows how to download dependencies, compile every artifact (there doesn't have to be one; maybe there's the test code to the built, the main app, a plugin for some other tool, and an installer. Build tools can handle all that), run the tests and report on them, possibly even tell you about code coverage, and they usually can run the app, but more generally, you just want to tell the build tool to build a distributable for each relevant artifact.
Those build files are what you're looking for. With those you can build your project, or point an IDE at them and then you can edit the project with all the dependencies and classpath linkages all worked out for you.

Options to compile and build jar files dynamically/programmatically?

The scenario is that I have a bunch of java projects with source files and lib jar files (for example apache-commons). I have multiple projects like that in different locations (shared drives, web servers, etc). Some of these projects depend on others. For example the output (.jar) from one project is used to compile and produce output for an other.
What I want to do is, programmatically (headless), using java, collect the source files and libs for all projects, compile them in order, and at the end produce jar files for the end projects. So, for project #1, brings all source files to a directory, bring all dependent libs in the same directory, compile, and create a .jar. Then do the same for project #2 but also include in the libs (or class path) the output of project #1, etc.
The projects dependency is known. The order on which the projects need to compile is known.
Bringing the source files and lib files together is not a problem. What I am looking for is suggestions on how to go about compiling programmatically. One option that I am considering is maybe Eclipse JDT. But before I go that path, I would like to see what other similar options exist out there
(I do understand that there are better procedures and processes that can be followed in order to make it easier to get the end result but I have no control over those. The build needs to be done dynamically/programmatically as described above)

Can I create an Eclipse Project that produces multiple executable Jars?

I have a project with a library JAR and a set of applications. Right now the applications (all 5 of them) are in a single project. These tools each have one or two classes, they run from the command line with one exception. Even the GUI tool has only about 8 classes. I am struggling with how best to structure this in Eclipse.
I have seen that I can use maven-shade to create multiple executable JARs from one project. I would need to convert the project to Maven, but I assume that is not a big problem.
I can create a separate project for each tool. This seems like overkill to have several projects with one or two classes in each.
Additionally, both of these solutions will leave me with either a bare class file or a JAR plus the dependent library JAR. Not ideal for deployment.
Before I pick one of these, I thought I would ask here if there is a different approach that I am missing for packaging these tools.
In eclipse, Export --> Archive file, You can select/deselect what classes you want to export into your Jar File
Yes, but You could/need to create using Maven, and for each build building jar you need to set the main Class.
Checkout the documentation of Maven.
I think You could to the same with Gradle, but not sure.
https://maven.apache.org/plugins/maven-jar-plugin/examples/attached-jar.html

How could I have Eclipse export files into a different location than their source?

I am writing a Bukkit plugin in Eclipse in which I separate different functions into different packages and export each package as its own jar file.
However, I would still like to keep these packages in the same project, rather than separating them into different Eclipse projects. These plugins each have files which must be in the root of the jar file, such as plugin.yml. I have moved each jar's files into their respective packages, but these files are put into plugin.jar\com\Preston159\plugin rather than in the root of the jar file (plugin.jar\), causing the plugin not to work.
Does Eclipse have any function to make these files automatically compress into the root of the jar file even though they are contained within the package in the source, or, is this something that I could solve by using Maven? My current solution to this problem is to move the files manually after exporting the jar, but this is becoming increasingly annoying.
EDIT:
The project builder XML I ended up using to complete this task can be found here
You would need to use a Build Tool. There are several supported by Eclipse. Ant and Maven are now built-in, but there are several build tools that run directly within Eclipse, but Eclipse can also be configured to run an external build tool as well.
Do a quick search on build.xml for examples of ANT build jobs.
Unless you're specifically required to use MAVEN for continuous integration, etc. then what you want to accomplish would be easily done with ANT.

Separate class paths for test code and main code

I have two source trees in my Java application in Eclipse. One is "src", and one is "test". Each one contains a directory tree of .java files. So far, so good.
However, I would like the classes in "test" to be able to see the classes in "src", but for the classes in "src" to not be able to see the classes in "test". Similarly, I want to include some test libraries. I don't want any of those libraries to be available in the "main" tree, lest I accidentally use one without thinking.
Is there an easy way to set this up in Eclipse?
There is no way to solve this in Eclipse without splitting the two source trees into separate projects (with one depending on the other). Maven could handle that at build time though.
You don't need separate projects if you use IntelliJ. You just specify application and test packages. It's possible to mark libraries as part of application and test as well.
Eclipse ought to have equivalent buried under all those plugins. If not, IntelliJ has a community edition now.
Or just use Ant. Personally, I prefer it to Maven. I find Maven to be too complex for such a simple job.

Categories