While I really like the Scenic View application that Jasper, Richard, and Jonathan have put together I do have to say getting it working is a bit of a struggle. But like most things I wind up blogging about this is something that can be fixed with a little bit of magical Gradle dust.

Skinning the Cat

Getting Scenic view to work shouldn’t be a struggle since there are three ways to start it up. Well the fact there are three ways may be part of the problem actually. The first is to rely on auto-discovery. This is the same thing that JVisualVM relies on. However this doesn’t work for me since I do my personal hacking on a MacBook Air, and the auto-discovery isn’t as reliable as it is on Windows machines. I.e. you get the mac experience of it ‘just working’ on windows but no mac. To be fair, this is option number three on the list and they openly admit it’s not the best choice currently.

Another option is to bundle in the jar and explicitly start the scenic view. The code is incredibly terse and has no real dependencies on your application code, except that the code needs to be run and the node to view. The downside here is that you always need the code available to compile and you always need the line in your code. You can hide the invocation with bear-claw clicks and keystrokes but the burden remains on you to either properly hide it or strip the code before you publish.

The last option, and the preferable one according to the docs, is to add the scenic view code as a java agent to your JVM. This is very reliable method but it has a very specific incantation you need to add to your launch command. And to add on to the troubles, there is no standard place this jar files live, it lives where you drop it. And old man Murphy says that you cannot depend on others placing it in the same place, unless you do it for them.

Integrations with Gradle

The first problem is that this program is not released into Maven Central. With gradle we can punt on running a maven repository and just upload it to an ivy repository. In this case I am doubling up with the Gradle JavaFX Plugin repository. Unlike the FXExperience Tools the code isn’t in a public repo so I cannot guess the license. I’ll err on the side of sharing.

The next problem is getting the jar local. I tried several approaches. I don’t need the jar at build time for the plugin. And adding it to the plugin dependencies creates some unneeded weirdness for application build scripts. Finally what I settled on was to dynamically alter the gradle script via the DSL. As part of the task I create a new configuration, add a new repository, and add a dependency to that configuration, Then I find all the tasks that are considered execution tasks and I prepend the needed agent string with the local cached copy of the scenic view jar. Did you catch and understand all of that? Don’t worry, you don’t need to understand the magic to use it.

This task will be part of the next release of the plugin. If you are using the snapshot script you already have it.

Too Long; Didn’t Read

To use scenic view with the gradle plugin just add the task scenicview before your execution task. Really you have two options. If you are not attaching a debugger:

gradle scenicview run

if you are attaching a debugger:

gradle scenicview debug

There will be no random jars added into your released code as long as you stick with the above incantations. And it will magically work.