Will's Blog

One problem every Java Desktop developer has to deal with is that Java apps just don't act like native applications. Whether it's the JRE dependency, the swing look and feel, or just bad memories about slow performance in old versions of Java. On Mac OSX there is an additional hurdle where users expect their applications to be a .app bundle inside a DMG image with a shortcut to /Application allowing them to drag/drop the installation. The built in Netbeans Platform installer is nice, but it's a far cry from the native behavior. With that in mind, I'm going to describe how you can really step up your Netbeans Platform Maven build to include an OSX deployment with a bundled JRE all packaged up as an APP inside a DMG image. What a mouth full. All of the source code for my implementation in Universal Gcode Sender can be found on GitHub in this commit . The techniques used in this post were heavily inspired (and in many cases copy/pasted from) the Gephi project , which ...

The Good The Netbeans Platform is incredibly simple to get started with. There are extensive tutorial based guides to get you started, like this tutorial about  creating a CRUD application with zero code , or making  a paint app , and  videos too , not to mention  Geertjan's Blog  which goes into many advanced examples. If you're using the Netbeans IDE you also get a huge assortment of wizards to help you along with various annotation-based integrations. The wizards have excellent ANT support and pretty good Maven support as well. There are many advanced features in the box from window management, plugins, configurable key-bindings and an auto-update framework. The Bad When you want to do something advanced which isn't covered by a tutorial, you quickly need to roll up your sleeves and dig into the source code. For example, if you choose to migrate from the default ANT build to Maven,  this guide is lacking  if you aren't very familiar with Mav...

For the past year Universal G-code Sender has suffered pretty severe feature creep. Lots of people had lots of good ideas, but it made the front end code confusing and hard to extend. In large part this is just because it's hard to compartmentalize a complex GUI. GRBL has had a lot of interesting features added in the past year which are begging to be leveraged, but UGS wasn't in a position to use them. With all this in mind I started trying to come up with a solution. The first step was to decouple the "model" object from the GUI. Inspiration for this started nearly a year ago when Bob Jones implemented a web interface for UGS. Bob made a thin API layer which exposed a few simple functions and allowed him to build a completely separate web-based user interface. This pattern is known as Model-View-Presenter , and allows for multiple front ends which use the same back end code. It enhances test-ability of the business logic and helps facilitate a flexible front end...

I've been converting UGS to run on the  Netbeans Platform  over the past week, and in general its been great.  The features and documentation I used while migrating UGS away from Swing were very well done. So aside from a couple hiccups, the Netbeans Platform has been great. Until a few days ago when I decided it was time to integrate my new changes with my Jenkins CI server. It turns out that you can't build a Netbeans Platform application without connecting to the Netbeans IDE first. This has to do with the extra modules, platform components and build harness. Searching the subject online provides a lot of documentation, everything I've found is either out dated, contradictory, or I could only get it working with a new project and not my existing one. The final solution was so simple, and minimally invasive that I wanted to create this blog post. There are 4 interesting files for a Netbeans Platform build: build.xml  - Some documentation suggests addin...