I have a Gradle project with subprojects and a somewhat complicated build.gradle file. I imagine that running SpotBugs from Gradle will make it easier because then SpotBugs can pick up all the classpath configuration and whatnot from Gradle. It was very easy to add SpotBugs to Gradle, and now I can run the corresponding SpotBugs task from Gradle and it produces reports in XML files.
The missing piece is that I would like to view the resulting errors/warnings/problems in IntelliJ. There is a SpotBugs plugin for IntelliJ, but it doesn't seem to know anything about Gradle. When I ask the SpotBugs plugin to analyze a module, it says the module is not compiled and doesn't report any issues. (But there are classfiles under the build directory (created by Gradle I think) as well as under the out directory (created by IntelliJ).)
How to run SpotBugs with the configuration specified by Gradle, while viewing the results in a nice IntelliJ window?
Some background:
Different team members use different IDEs, and we would like to make sure that everyone fixes certain warnings to keep the code quality high. I've looked into configuring the IntelliJ "analysis" settings to match the Eclipse compiler warnings, but it's going to be a slog. (We also have different subprojects with different warning settings.). So I thought it would be helpful to have an external tool that everyone can run from Gradle, and if that tool says green, then it's green. Each developer can then configure their IDE settings to their liking, but it will be easy for them to run their code through this external tool (here: SpotBugs) to confirm that all is well.
Related
There are at least two ways of using the checkstyle in the NetBean maven project
(at the time of 2019-07-24):
using the NetBeans's plugin checkstyle-beans
v4.1.0, last Update: 2016-02-09, uses Checkstyle v6.15.
The last declared supported version is NetBeans v8.1
*although it works with v8.2
using the Maven's plugin maven-checkstyle-plugin
v3.1.0, last Update: 2019-05-12, uses Checkstyle v8.19
The last version of the github.com/checkstyle itself is v8.22
Questions:
Can I update them both to the last checkstyle?
Does they completely independent ?
the checkstyle-beans shows the marks beside the line numbers in the IDE
the maven-checkstyle-plugin can be used for the manual launch in the console, outside the IDE (mvn -e checkstyle:check).
Can it be configured and used inside the IDE ?
As a Netbeans user, you are stuck with Checkstyle-Beans as far as in-IDE support goes.
Maven and Checkstyle-Beans are completely independent of each other, but both depend on Checkstyle, of which they should use the same version.
This means you are also stuck with Checkstyle 6.15 (no upgrade unless Checkstyle-Beans gets a new version), which you must consequently use everywhere else also, or your Checkstyle configuration will not work (for example Checkstyle 6.15 config XMLs won't work with Checkstyle 8.22).
So, you have three options:
Use a different IDE, such as IntelliJ or Eclipse. Both have up-to-date Checkstyle support, so you can use the latest Checkstyle both in Maven and in the IDE.
Continue with Netbeans, and use Checkstyle 6.15. This is actually feasible imho. Checkstyle docs are versioned these days, so you can see the correct docs at https://checkstyle.sourceforge.io/version/6.15/. This will get you Checkstyle 6.15 support in Maven and in the IDE.
Continue with Netbeans, and use latest Checkstyle. Then you can only run it via Maven, but I suppose you can configure a button in NetBeans to make this easy.
Currently, my built structure for a plugin in is a bit messy: I'm using the normal IDEA project file to build the plugin locally. When I push it to the repo and travis-ci is building it, it uses the maven pom.xml because for travis to work, it always has to download the complete IDEA sources.
Although this works, this has several drawbacks:
I need to keep two built mechanisms up to date. This is
When a new IDEA version is out (every few weeks), I need to change the SDK in maven and in my IDEA settings
When I add a new library, change resources, etc. I need to do this for two the two settings as well
I ran into problems when I kept the IDEA Maven plugin turned on because it saw the pom.xml and interfered with my local built. Turning it off means, I cannot download libraries with Maven which has the feature of tracking dependencies.
I saw that Gradle has an 'idea' plugin and after googling, I got the impression that Gradle is the preferred choice these days. I have seen Best way to add Gradle support to IntelliJ IDEA and I'm sure I can use the answers there to turn my pom.xml into a valid build.gradle.
However, maybe someone else has already done this or can provide a better approach. What I'm looking for is a unified way to build my plugin locally and on Travis-CI.
Some Details
For compiling an IDEA plugin, you need its SDK which you can access through an installation of IDEA or a download of the complete package. Locally, I'm using my installation for the SDK. With Travis, my maven built has the rule to download the tar.gz and extract it.
It turns out that in particular for building an IntelliJ plugin, Gradle seems to have many advantages. This is mainly due to the great IntelliJ plugin for Gradle which makes compiling plugins so much easier. With Gradle, I could turn my >220 lines of Maven build into a few lines of easily readable Gradle code. The main advantages are that
It takes care of downloading and using the correct IDEA SDK while you only have to specify the IDEA version.
It can publish your plugin to your Jetbrains repository and make it instantly available to all users
It fixes items in your plugin.xml, e.g. you can use one central version number in gradle.build and it will keep plugin.xml up-to-date or it can include change-notes
It seamlessly integrates with Travis-CI
How to use Gradle with an existing IDEA plugin
Do it manually. It's much easier.
Create an empty build.gradle file
Look at an example and read through the README (there are many build.gradle of projects at the end) to see what each intellij property does.
Adapt it to your plugin by
Setting the intellij.version you want to build against
Setting your intellij.pluginName
Define where your sources and resources are
Define your plugin version
Define a Gradle wrapper that enables people (and Travis) to build your plugin without having Gradle
Create the gradle wrapper scripts with gradle wrapper
Test and fix your build process locally with ./gradlew assemble
If everything works well, you can push build.gradle, gradlew, gradlew.bat and the gradle-folder to your repo.
Building with Travis-CI
For Travis you want to use the gradlew script for building. To do so, you need to make it executable in the travis run. An example can be found here.
I'm playing around with gradle, mostly to explore if its a viable alternative to maven for my builds. I quite like the idea of a more programmatic approach to build configuration, so it's quite promising so far.
However, I do have a couple of minor annoyances I'm trying to wrap my head around. One particular issue is to identify what actually generate the top level build folder in my project, as the top level project doesn't have the java plugin applied.
For example, I got a hierarchy something akin to this:
/POC
build.gradle
settings.gradle
/subproject1
/subproject2
Now, in my top-level configuration, I'm applying the java plugin only to the subprojects, and I can see from the output of gradle build, that indeed the build steps are only executed on the subprojects.
However, I still get a build folder in the top level directory, in addition to the build folders in the subprojects.
This isn't a huge deal, but, it tickles my OCD, I want to know why it pops up there. I feel like I'm missing something important in respect to how gradles build lifecycle works.
I have a set of 15 or so interdependent Gradle Java modules/projects that build correctly with Gradle. However, I run into issues importing them into Eclipse.
If I import them via the Gradle Eclipse plug-in (import as Gradle project) and select "Build Model" in the root folder, it imports the projects, but doesn't treat them as Java projects. Specifically, syntax errors are not recognized.
If I import each project individually, they are recognized as Java projects, but they are not linked properly and Eclipse shows build errors.
How do I properly import/link Gradle projects into Eclipse?
Check if your project has eclipse specific files like .project, .classpath etc. These are hidden files so you need to run command $ls -la to confirm that.
If those files are not there then you need to convert your project into a valid eclipse project. Gradle provides plugin to do that.
Add eclipse plugin in gradle build file (i.e. build.gradle).
apply plugin: 'eclipse'
Run $gradle eclipse
I have provided these details on my blog, here.
Unfortunately is not easy to answer that, it depends on the details of your project. I found that for complex projects it often needs specific tweaks in the build script.
I am going to assume your projects have never been used in Eclipse. These are some tips that may work for such cases (or they may not, and will need more specific tweaks).
1) make sure to apply the 'eclipse' plugin to all your projects if they are plain Java projects, or the 'eclipse-wtp' plugin if they 'war' style web projects.
2) import your projects with 'dependency management' disabled (this is one of the options in the import wizard.
If this doesn't work, I will need more details about your projects and/or exactly what is going wrong with the import. It sounds like maybe your projects are not getting a proper java nature, or the source folders are not correctly configured. The contents of the .classpath and .project files for the 'badly configured' projects would be helpful.
Sourceforge.net has a filter for Java projects, but I'm looking for a way to narrow them down to ones that are meant to be built in Eclipse.
Edit I'm using Eclipse Metrics and Omondo plug-ins to analyze open-source Java projects. I'm looking for a quick way to find Eclipse open-source projects that can build quickly in Eclipse, so I can use these tools on them for analysis.
I presume that a project that is "meant to be built in Eclipse" is one that has an Eclipse .project file and other stuff checked into the source repository.
First, checking in Eclipse-specific stuff can a bad idea because it is easy to include stuff (e.g. build pathnames, preferences) that are specific to the developer. You then get problems if there are multiple committers ...
Second, this should unnecessary. Most of the stuff in the .project file can be generated when you import the project. If that's not possible, then the project should provide instructions for setting up the buildpath etcetera. (Note that if the project uses Maven, this is all taken care of for you.)
Third, any project worth its salt will include build scripts of some kind that allow you to rebuild without using any IDE.
Finally, any project that only supports building using Eclipse is excluding the significant subset of developers who use other Java IDEs.
Note that neither Maven or Ant builds require Eclipse to work. Both of these build tools can run from the command line, or from other Java IDEs.
OK. I understand your requirements now. You don't actually care what the project is ... or that it is sound / worthwhile project. You just need it for testing your plugin. (I won't comment on the "validity" of doing this. It depends on what you hope to achieve.)
I suggest that you install the m2eclipse plugin and look for projects with a "pom.xml" file. The projects don't need to be eclipse specific. The m2eclipse plugin automatically creates the ".project", ".classpath" and so on based on the "pom.xml" file. There's no need to exclude any particular version control system, because the m2eclipse plugin can import Maven projects that you checked out from the command line.