Gradle Sonar source compatibility

I'm slowly migrating a large project to Gradle. One of the major selling points is the Sonar plugin. I switched a module to Gradle and ran the 'gradle sonar' command. I got a screen full of exceptions that looked like this:

Fail to execute PMD. Following file is ignored:

/Users/spina/Code/apt/StagingGround/Utilities/src/main/java/gov/nasa/gsfc/util/VersionChecker.java
net.sourceforge.pmd.ast.ParseException: Can't use annotations when running in JDK 1.4 mode!
at net.sourceforge.pmd.ast.JavaParser.checkForBadAnnotationUsage(JavaParser.java:32)
at net.sourceforge.pmd.ast.JavaParser.MarkerAnnotation(JavaParser.java:5353)
at net.sourceforge.pmd.ast.JavaParser.Annotation(JavaParser.java:5272)
at net.sourceforge.pmd.ast.JavaParser.Modifiers(JavaParser.java:347)

I was building for Java 7. I did the obvious google searches and didn't find an answer. A bit more work and I found the solution here. Basically, I needed to add the following to my build.gradle file:

sonar {
// Tell sonar where the cobertura codecoverage reports are and what version of java to use.
projectProperties([ 'sonar.java.source': '1.6', 'sonar.dynamicAnalysis': 'reuseReports', 'sonar.cobertura.reportPath': 'build/reports/cobertura/coverage.xml' ])
}

The important bit was this: 'sonar.java.source': '1.6'. Hope this helps someone =).

What can I do?

I want to have a list of the skills that I have. This is to help me track my growth and may help me identify solutions to problems that I face in the future. Hopefully I'll update this occasionally...

1) Java - 3+ years professional experience as of 2011.
2) CVS - Version control.
3) Mercurial - Better Version Control.
4) Groovy - Writing a 'Domain Language' for external users (still not sure how successful I was)
5) Groovy Scripting - Shell scripting using a Java Dialect
6) JavaFx - A rendering language for Java. Needs better tooling.
7) Html - Through Notepad and WYSIWYG editors
8) Ajax - 1 graduate level class where I learned how it works.
9) Eclipse - A good IDE
10) Omnigraffle - A good diagram creation tool
11) Cosi - a listening infrastructure (developed by STScI).
12) Bugzilla - a bug tracking system.
13) Mylyn - a task management tool in Eclipse.
14) ant - build system
15) maven - better build system
16) gradle - even better build system
17) Sonar - build analysis
18) cobertura - code coverage analysis
19) jUnit - unit testing of Java and Groovy code
20) Objective c - initial implementation of an iPad app.
21) SVN - better than CVS

Announcing Gradle-Plugin-JavaFx! JavaFx built by Gradle.

I complained earlier about how JavaFx is missing some really critical tooling. I mentioned debug support, and build support. In particular I was wishing that there was a JavaFx plugin in Gradle.

Because it was lacking and I really wanted FxBattle to build using Gradle. I decided to make such a plugin. Well, this is the official release of Gradle-Plugin-JavaFx version 0.1.0. I know, the name just rolls off your tongue.

It's an open source project that exists only to enable the FxBattle build. Still, others may find it useful. If they do, I'd love to hear from them. Keep up the great work Gradle developers. I love your product and am hoping to use it more widely soon.

Why I love OkGo

This is a beautiful video. Their use of vivid color and clever production combines with their mellow, trance-like music to give a really excellent and somewhat trippy experience.

in reference to: YouTube - OK Go - End Love - Official Video (view on Google Sidewiki)

What do I want to see developed for JavaFx?

JavaFx is a decent language for coding a User Interface. The interface for FxBattle would have been a bear to write in Java. Other languages might be easier than JavaFx, but I don't know of any that run on the JVM.

====== Performance Debug Tools ======

When I started work on the FxBattle GUI, I discovered that there was little support for Eclipse (my preferred IDE) so I worked on it using NetBeans. This was fine until I managed to get NetBeans into some strange state where I couldn't really build the project. Not Good. A bit later, I discovered a terrible performance issue in the code.

I spent hours trying to track down the problem. I looked online for 'best practices' for JavaFx. What I found was advise like 'don't use too many bindings', 'make unused components invisible', and others. At JavaOne this year, I went to a talk on performance tricks. They gave similar advise.

The problem with this kind of advise is that they are asking you to hunt through your entire code base and do guess-and-check debugging. You're suppose to find a binding, ask the question 'Is this the problem binding?' Then you're supposed to find some way to implement your logic without bindings and see if it's better.

Imagine debugging performance in an enterprise application like this. Our database updates are taking too long... let's look through all our DB queries and change them one at a time to see if the process gets faster. Of course that's out of the question. Instead we use profiling software to help us find the performance problem.

I did use YourKit to profile FxBattle. It told me that most of the processing was spent redrawing the GUI. This was no surprise. The problem was, YourKit couldn't tell me what code was queuing up the redraws that were taking up the time. So I had to fall back to the guess-and-check debug system. This completely killed my progress. I was guessing that the problem was in the JavaFx core anyway, so I just waited for JavaFx 1.3. When it was released the performance of FxBattle was greatly improved.

====== Build Tools ======

Another reason I was working on FxBattle was to learn about build systems. The build for FxBattle is somewhat complex. Lots of subsystems, some of which are JavaFx, some use Protocol Buffers, some are Java, some are Clojure.

The first build system for FxBattle was Maven. I find I liked it better than I like Ant. It gives you more features in fewer lines of build logic. However, trying to get it to do anything it isn't already good at is really tough. There were no tools to build JavaFx, Clojure, or Protocol Buffers. Getting a sensible build put together was a real bear.

Given that Maven is a very popular build system, why wouldn't there be a plugin to build JavaFx already available? On top of that, I had Java Code which tried to invoke JavaFx code. Doing this required the JavaFx Runtime Jars on the classpath. So I should be able to specify a dependency in my POM that makes those Jars available. Nope, can't do that. The Jars aren't allowed in the Maven Central Repo. Why? Doesn't SUN (now Oracle) want people to develop JavaFx apps? Doing that means we have to be able to access the Jars during our build process.

At JavaOne this year, I decided to try rewriting the build to use a new build technology called Gradle. I'm nearing completion of this task. I really like Gradle.
I was surprised to find that there is already a plugin for Clojure and Protocol Buffers. Great! That makes the build much simpler. Though it did take a while for me to figure out how to hook them all up.

Okay, got the back end compiling, now it's time to compile the front end. Where is the JavaFx plugin for Gradle? There isn't one? There is a lot of hype around JavaFx, but an up-and-coming build system doesn't already have a plugin to compile it?

So, I wrote a plugin for Gradle that compiles JavaFx. It is based on Clojuresque and appears to do the job for my use case. I will probably publish it once I hear back from a few people that there isn't already a tool that does this job.

===== Summary =====

We need to be able to debug JavaFx performance.

We need to be able to build JavaFx in all the popular build systems.

Better Controls, CSS, and other such features aren't useful if we can't do the above.

Google Sidewiki entry by Andrew

I was looking for this to help me assemble my assignments for my AJAX course. I had lots of code and html files that I had to assemble into a PDF for turn in. This made it much easier!

in reference to: Automator Tip of the Week #3: Convert Word Documents to PDF | Mac Help from Maciverse (view on Google Sidewiki)

FxBattle will be built by Gradle

One of the hold ups with FxBattle was JavaFx 1.3. When that was resolved, we'd forgotten how to build the system. It took a night at JavaOne to get it running again. We can build and run now using Fx 1.3 (which is WAY FASTER- YEAH!).

However, it's a big old hacky system and I don't like it. I used Maven, but lack of documentation, and severe rigidness were sufficient to make me want to abandon the technology. At JavaOne I learned about Gradle. It's a different kind of build toolkit.

I'm finding that I like it immensely. It is somewhat immature right now, but the activity surrounding it seems huge. The documentation is surprisingly complete for a product that isn't even version 1.0 yet. I've had some trouble getting plugins working in version 0.8. It required a bit of hacking and wasn't particularly strait forward. This said, 0.9 will have a much better plugin system (just drop a Jar into your system). There also appear to be plans for a plugin repository in the future so you can just ask for it by name.

I don't see a plugin for Gradle which builds JavaFx. If the plugin development documentation gets better, I may start such a plugin. At least, we'll have to be able to build JavaFx in FxBattle through Gradle.