Version 1.10.2 of Eclipse Code Formatter for Java introduces support for Workspace Mechanic and much more

In the last days and weeks I was busy enhancing the Eclipse Code Formatter plugin. The main focus was the support of the Workspace Mechanic [1] configuration file to be in compliance with my coworkers.

Offtopic: Workspace Mechanic is a plugin for Eclipse IDE itsself, which makes sure that shared Eclipse configurations are applied to your local installation. Have a look. It’s useful in a team of several developers.

Workspace Mechnanic also synchronizes the configuration of the formatter. Luckily its file format is quite simple and thus supportable by my plugin. So next to the standard XML-formatter file you can now use Workspace Mechanic EPF-files too.

I also added some other useful features you may like. That was the reason, why the release of this version took so long. For example now the “format on save”-action can optionally format the changed lines only. You can use formatter settings from .settings, you can configure the Java source level and the line feed. And the download size of the plugin has been massively decreased.

The full changelog can be found at [2]


In a few days it will be available as an update from within your NetBeans IDE. If you are curious and you don’t want to wait for it, then you can install it manually from [3] or [4].

Feel free to file issues and even better, provide pull-requests! We see us at NetBeans Day Germany in Munich on the 31st of March 2016. Get your ticket at [5]!

[1] Workspace Mechanic
[5] NetBeans Day Germany in Munich

Quicktip: Maven-based NBM development and the user-dir

When you develop a NetBeans module using the Maven-approach, every time you “Clean & build” your module the userdir, which is placed in the target-directory by default, will be deleted. “Clean & Build” is necessary if you’re altering the layer.xml directly or indirectly by using annotations like @ActionReferences.  So after that you have to reconfigure your target platform again, f.e. by opening the same projects and files to restore the previous state. That is annoying, but easy to fix.

Add a profile to your settings.xml



After that you can choose the profile from the profile-dropdown or in the context-menu of the project node.


This way the configured userdir is used for running/debugging your NetBeans module. It won’t get deleted automatically.

Advanced tips: Of course you can also configure an absolute path or even make the profile default by applying activeByDefault



Code outline plugin 1.3.0 now supports dark themes

As you might already read in the NetBeans weekly newsletter, I also updated the Code outline plugin this week. This plugin shows the document content in miniature at the right gutter of the editor. Some of you know that feature from “Sublime Text” editor. This implementation is a bit simpler.


A highly requested feature was the support of dark themes. And now it’s supported. The basic text color and the background color of the editor is used. You can also check the “Darkening” option, which lowers the brightness of the code outside of the viewport. Try it!

Other improvements: You can define the font-size, but I propose to use single-digit font-sizes. The display quality has also been improved by applying anti-aliasing.


The plugin is already available from the plugin dialog within your NetBeans IDE 8+. Or it can by downloaded manually from the plugin page at [1] and github [2].

Please file issues/enhancement at [2]. I also like to merge your pull-requests for further improvements! Happy coding with NetBeans!


New version of Eclipse Code Formatter for Java provides support for Eclipse 4.5.1 Mars.1 and @format:off

Within the last days I had time to update the formatter plugin, which allows you to format java source code using the formatter engine of Eclipse JDT. In a few days it will be available as an update from within your NetBeans IDE. If you are curious and you don’t want to wait for it, then you can install it manually from [1] or [2].

The major change is that the jars for the formatter engine are now taken from Eclipse 4.5.1 Mars.1.

As you might know, the plugin already provided support for @format:off before – if it was enabled in the formatter file. But now it provides some code templates, so that it easier to use. See the documentation at [3]



Feel free to file issues and provide pull-requests to see your enhancement in the next release! Happy coding and a happy new year!


NB platform: Catching missing resources at compile-time using @StaticResource

When you develop a NetBeans platform application sometimes you like to refer to existing resource files like images.

Therefor you have to hard-code the path into your sources in a string literal. Normally you would notice a wrong path at runtime because of a FileNotFoundException – not very professional.

But wait! Use the org.netbeans.api.annotations.common.StaticResource-annotation from the Common Annotations module (/org.netbeans.api:org-netbeans-api-annotations-common) instead. Backed by an annotation processor NetBeans will check whether the path is correct at compile-time. This is pretty cool.

What do you get? NetBeans shows missing resources in the editor, in the “Action Items”-view and even the build will fail.



NetBeans: Switching project groups from toolbar

Today I saw that a new version 1.7 of the “Cool Editor Actions” plugin has been uploaded by anchialos to the plugin portal [1]. It introduces switching of project groups and toolbar configurations right from the toolbar, which is very nice.



BTW: A similar much older plugin named “Project Group Toolbar” from Aljoscha Rittner already exists, but  unfortunately it does not work in a stable way anymore – regarding to multiple comments at the plugin portal [2].


How to convert an ANT-based NetBeans Module to a Maven-based NetBeans Module

I am currently converting some of my ANT-based NetBeans Modules to Maven-based ones. I didn’t found a step-by-step migration list, so I decided to create one and to share it with you. The following list was created while converting a simple plugin with less than 20 classes, so the migration steps of large projects might vary. But you should get the basic idea.

  • create a new maven based NBM using the “New Project”-wizard (to reuse a working configuration)
  • copy the folder src and pom.xml to the old project
  • in pom.xml
    • define a groupId
    • set the name from OpenIDE-Module-Name entry in
    • set the artifactid from OpenIDE-Module entry in MANIFEST.MF
    • set the version from OpenIDE-Module-Specification-Version entry in MANIFEST.MF
  • remove the line with OpenIDE-Module-Specification-Version entry from MANIFEST.MF
  • remove the line with OpenIDE-Module entry from MANIFEST.MF
  • remove nbproject/
  • remove nbproject/
  • remove nbproject/build-impl.xml
  • remove build.xml
  • move to folder src/main/nbm
  • move your sources (*.java) to src/main/java (or src/test/java) (GIT is very useful here, the commit history isn’t lost)
  • move your resources (not *.java) to src/main/resources (or src/test/resources) (especially
  • add dependencies (the most annoying part)
    • foreach dependency entry (code-name-base) in nbproject/project.xml add a dependency via the “Add dependency” dialog OR add a dependency manually to pom.xml

    For example use




    (!) Note that the dots in the dependency name have to replaced by a dashes

  • add test dependenciesFor example use



There is still more to do. Like to configure export packages, signing, homepage and so one. Most of these configuration settings defined in the original have a counterpart in the plugin configuration of the nbm-maven-plugin. See the detailed goal documentation at

But your mavenized plugin should start at least now.

PS: The whole process is worth a plugin itself.  Any volunteer?