Several weeks ago, I posted blurb about a JavaFX project I had cobbled together, DoctorFX.
It is an effort to build a semi-graphical editor for Asciidoc, but it is, currently,
very basic. I had some spare time last week, so I decided to add some features to it. As I thought about what needed to
be added and what that would require, I thought that, perhaps, an architectural change was warranted. With some time and
an itch, I pulled out the sledge hammer and out came a NetBeans plugin. This plugin though, does more than Asciidoc: it
offers full(-ish) support for the Awestruct framework.
There are a lot of features I’d like to add still, but, currently it supports only basic project loading and editing.
It technically has code to preview Asciidoc files, though I’m having issues getting the rendered page from displaying.
(In case you want to take a crack at it, that code is here.)
I’d also like to add preview support for Slim and Haml, but that may have to wait a bit.
If you’d like to lend a hand to the effort, you can find the current source on Bitbucket.
This is, of course, a bit heavier than DoctorFX, but most of my work with Asciidoc is, currently, in the context
of Awestruct, so this fits my needs better, and it was fun dipping my toes into the NetBeans Platform API. :)
Using Maven, to run a single test (class), you would issue mvn -Dtest=MyTest. Gradle has similar functionality (gradle -Dtest.single=MyTest), though it seems to be much more powerful. You can get all the details here.
In a recent post, I showed how to attach a debugger to tests run from the command line via Gradle. While it worked, it turns out that it’s a bit over kill. Try this instead:
1
2
3
4
5
6
7
8
9
| $ gradle -Dtest.debug test
:compileJava
:processResources UP-TO-DATE
:classes
:compileTestJava
:processTestResources
:testClasses
:test
Listening for transport dt_socket at address: 5005
|
Attach your debugger to port 5005, and off you go. No need to modify your build. Kudos to the NetBeans debugger output for helping me find that. ;)
Java Champion and JUG leader Antonio Goncalves recently released his third book on Java EE, Beginning Java EE 7. Just from the title and the table of contents, it’s clear that Antonio set a very ambitious goal for this book, and I think he delivered what he promised.
I’ve recently been migrating all of my personal projects to Gradle. Since I use Arquillian, that means migrating that part of the build as well. However, being still fairly new to Gradle, how to handle that integration wasn’t immediately obvious. Thanks to Benjamin Muschko and Aslak Knutsen, I’ve finally gotten a working setup.
I’m not a real big fan of using standard out as a debugging strategy (I prefer an IDE and break points, for what it’s worth), but there are times when it’s either necessary or just convenient. The standard Gradle configuration, though, makes this a bit more difficult than it probably should be. Fortunately, Gradle also makes it easy to change:
build.gradle
1
2
3
| test {
testLogging.showStandardStreams = true
}
|
If you’d like to make this change globally, that’s also easy:
$HOME/.gradle/init.gradle
1
2
3
4
5
| allprojects {
tasks.withType(Test) {
testLogging.showStandardStreams = true
}
}
|
Maven offers a nice script to allow for attaching a debugger to your build, mvnDebug. Gradle does not. Again, though, Gradle makes it pretty easy to add this to your build.
At the Lee House, we have an email problem: there’s just too much of it. Over the years of signing up for contests, coupons, and other things, we seem to have amassed a giant number of subscriptions to various lists, which gives us a lot of (usually) junk email. The simple solution, of course, is just to unsubscribe, but some of those are actually occasionally useful. Throw in a pinch of proscratination and laziness, and, well… it all just keeps coming. Email clients can help manage this by providing email filters to move these emails out of the inbox, but, in the case of Thunderbird, there are only so many rules you can add to one filter, so you either create multiple rules, or give up trying. Several months back, I moved these rules to a perl-based system, but, thanks to a hard drive crash, I lost all of those. Rather than rebuild that setup, which had its own limitations, I did what every good geek would do: I wrote my own, and here it is. :)
Sometimes, such as when building command line Java apps, it would be nice to bundle all of the app’s dependencies in a single jar so that the user need not collect and manage these. With Gradle, that can be easily accomplished with the following lines:
build.gradle
1
2
3
4
5
6
7
8
9
10
| jar {
from {
configurations.compile.collect {
it.isDirectory() ? it : zipTree(it)
}
configurations.runtime.collect {
it.isDirectory() ? it : zipTree(it)
}
}
}
|
When you run gradle assemble, you should find your now very hefty jar in build/libs.
WebJars, for those that haven’t heard, is a project that takes popular client-side web libraries and packages them in JARs to make their use in Java-/JVM-based web apps simpler. The web site notes that you can easily see which libraries a project is using simply by looking at its dependencies, and that transitive dependencies automatically appear. It’s a pretty compelling project, but, for some reason, it doesn’t show how to integrate it with JSF. I’d like to think it’s because it’s so trivial, but I’ll show it here anyway. :)
My name is Jason Lee. I am a software developer living in the middle of Oklahoma. I’ve been a professional developer since 1997,
using a variety of languages, including Java, Javascript, PHP, Python, Delphi, and even a bit of C#. I currently work for Red Hat
on the WildFly/EAP team, where, among other things, I maintain integrations for some MicroProfile specs, OpenTelemetry, Micrometer,
Jakarta Faces, and Bean Validation. (Full resume 