Missing plugins for your NetBeans nightly builds?

Do you use a Nightly-/Dev-Build of NetBeans or even a release candidate of 8.2 within the NetCAT-program and you are missing some of your favorite plugins?

First there is no plugin center for Dev-Builds. Also most plugins from the 8.1 plugin center are not verified for the new 8.2 build yet – including my plugins.

Nevertheless in the meantime you can still use the plugins and give the plugin authors feedback of the compatiblity to 8.2. Some plugins won’t work, because of using non-public API, but that is the point to find out!

How to do that?

At Tools|Plugins|Settings add the plugin center URL for 8.1 [1] and then at Tools|Plugins|Available Plugins click at “Check for Newest


If you are interested in testing non-verified plugins see the article [2]

[1] http://plugins.netbeans.org/nbpluginportal/updates/8.1/catalog.xml.gz
[2] https://benkiew.wordpress.com/2013/02/03/netbeans-ide-verification-of-plugins-and-update-center-urls-for-non-verified-plugins/


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



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 Bundle.properties
    • 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/genfiles.properties
  • remove nbproject/platform.properties
  • remove nbproject/build-impl.xml
  • remove build.xml
  • move manifest.mf 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 Bundle.properties)
  • 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 project.properties have a counterpart in the plugin configuration of the nbm-maven-plugin. See the detailed goal documentation at http://mojo.codehaus.org/nbm-maven/nbm-maven-plugin/nbm-mojo.html

But your mavenized plugin should start at least now.

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

NetBeans IDE: Verification of plugins and update center URLs for non-verified plugins

You developed a cool NetBeans plugin? Now you want it be to be available via the official update center, so that it can be installed directly from the NetBeans IDE via the built-in Plugins Manager and gets more attention from the users?

Then you have to adhere to the verification and quality rules defined in [1] and [2]. You have to define a license, sign the package and so on. Your plugin will also be tested from several trusted community members and they give a go or a no-go. For some plugin developers this process seems to be too much overhead and too time-consuming. They do not request a verification and therefore their plugin is not available in the Plugins Manager from your IDE. That is a pity, because this way you miss many useful plugins (Geertjans plugins, Compare to clipboard, JVisualVM samples, …). For example there are only 67 of 136 plugins verified for NB 7.2.

Of course you could download the plugin manually from the plugin portal at [3] and install them manually, but this not very comfortable IMHO. It is also not reasonable for me to contact all the authors and beg them for getting their plugins verified. So i opened a ticket [4] for an update center which contains those non-verified plugins. And guess what. The NB team now provides such URLs:

As warning: Using these URLs you are going to install non-verified, experimental and non-quality-checked plugins, which could make your NetBeans IDE unstable/slow down or even crash. Only install plugins you know and trust. You can be sure that the NetBeans developers will not support any issues regarding these plugins.

You want to have more quality plugins available and don’t want to go this inofficial way of experimental update centers? So please encourage the authors of your favorite plugins to request a verification. Thank you!

[1] http://wiki.netbeans.org/FaqPluginRequirements
[2] http://wiki.netbeans.org/PluginPortalQualityCriteria
[3] http://plugins.netbeans.org/
[4] http://netbeans.org/bugzilla/show_bug.cgi?id=225104
[5] http://deadlock.netbeans.org/hudson/job/nbms-and-javadoc/lastStableBuild/artifact/nbbuild/nbms/updates.xml.gz

NetBeans IDE 7.3: How to extend the context menu of the members and hierarchy view?

Today i will show you how to extend the context menu of the newly redesigned members and hierarchy view in NetBeans IDE 7.3.

Plugin your action at the following extension points


and get the TreePathHandle from the Node’s lookup. Easy isn’t it? Please note that these extension points are new in NB IDE 7.3 – see the issues [1] and [2].

This allows the integration of current/future actions which react on
TreePathHandle like

  • toggle method breakpoint (when a method is selected)
  • toggle class breakpoint (when a class is selected)
  • run/debug main method (when a class with a main method is selected)
  • run/debug test (when a class with testmethods is selected or when a testmethod is selected)
  • add as profiling root (when a method is selected)
  • integration of my own “Copy FQN” plugin (i will blog about it next time)

But now a more concrete example:

package de.markiewb.netbeans.sample.extendMembersAndHierarchyView;

import java.util.ArrayList;
import java.util.List;
import static javax.swing.Action.NAME;
import javax.swing.JMenuItem;
import javax.swing.JOptionPane;
import org.netbeans.api.java.source.TreePathHandle;
import org.openide.awt.*;
import org.openide.nodes.Node;
import org.openide.util.HelpCtx;
import org.openide.util.NbBundle;
import org.openide.util.actions.CookieAction;
import org.openide.util.actions.Presenter;

@ActionID(category = "Edit", id = "de.markiewb.netbeans.sample.extendMembersAndHierarchyView.SampleAction")
@ActionRegistration(displayName = "SampleAction")
    @ActionReference(path = "Navigator/Actions/Members/text/x-java", position = 1150),
    @ActionReference(path = "Navigator/Actions/Hierarchy/text/x-java", position = 1150)
public final class SampleAction extends CookieAction implements Presenter.Popup {

    public SampleAction() {
	putValue(NAME, "Hello TreePathHandle(s)");

    public String getName() {
	return "Hello TreePathHandle(s)";

    public JMenuItem getPopupPresenter() {
	return new JMenuItem(this);

    public HelpCtx getHelpCtx() {
	return null;

    protected boolean enable(Node[] activatedNodes) {
	//.. use tph from lookup in node
	for (Node node : activatedNodes) {
	    if (null != node.getLookup().lookup(TreePathHandle.class)) {
		return true;
	return false;

    protected int mode() {
	return CookieAction.MODE_ALL;

    protected Class[] cookieClasses() {
	return new Class[]{Node.class};

    protected void performAction(Node[] nodes) {
	List<TreePathHandle> treePathHandles = new ArrayList<TreePathHandle>();
	for (Node node : nodes) {
	//show all treePathHandles
	JOptionPane.showMessageDialog(null, "Hello\n" + treePathHandles);

The result:


The full sample project is available at [3]

[1] http://netbeans.org/bugzilla/show_bug.cgi?id=220057
[2] http://netbeans.org/bugzilla/show_bug.cgi?id=224499
[3] https://github.com/markiewb/nb-api-samples/tree/master/ExtendMembersAndHierarchyView
[4] http://wiki.netbeans.org/DevFaqAddActionToMembersOrHierarchyView

NetBeans: How to create a context aware action with an icon for the context menu

Here a small sample how to create a context aware action with icons for a NetBeans Platform RCP application or even the NB IDE. You may wonder and questions like “Why the heck he is doing this” or “Why he won’t use the standard action wizard?” may pop up.

Assigning icons to actions is easy. BUT the icons do will not be displayed in the context menu (by default). It is possible but not best practice in NB RCP. Keep in mind that icons in menus are not supported for MacOS. So use it wisely.

The important points are:

  • extend from AbstractAction to get access to putValue (you loose the standard context aware features, so you have to implement them yourself via keeping a proxy to the global lookup and enabling the action depending on the content of the lookup)
  • implement Presenter.Popup and return a JMenuItem instance for the current action (see [1], [2])
  • set the icon via putValue(javax.swing.Action.SMALL_ICON, ...)
package de.markiewb.netbeans.sample.contextmenu;

import java.awt.event.ActionEvent;
import javax.swing.AbstractAction;
import static javax.swing.Action.SMALL_ICON;
import javax.swing.JMenuItem;
import javax.swing.JOptionPane;
import org.netbeans.api.annotations.common.StaticResource;
import org.netbeans.api.project.Project;
import org.openide.awt.ActionID;
import org.openide.awt.ActionReference;
import org.openide.awt.ActionReferences;
import org.openide.awt.ActionRegistration;
import org.openide.util.ImageUtilities;
import org.openide.util.Lookup;
import org.openide.util.NbBundle.Messages;
import org.openide.util.Utilities;
import org.openide.util.actions.Presenter;

        category = "Build",
        id = "de.markiewb.netbeans.sample.contextmenu.HelloIconAction")
    @ActionReference(path = "Menu/File", position = 0),
    @ActionReference(path = "Loaders/Languages/Actions", position = 0),
        displayName = "#CTL_HelloIconAction")

@Messages("CTL_HelloIconAction=Hello Icon Action")
public final class HelloIconAction extends AbstractAction implements Presenter.Popup {

    private static final String ICON = "de/markiewb/netbeans/sample/contextmenu/sample.gif";
    private static final long serialVersionUID = 1L;
    private final Lookup context;

    public HelloIconAction() {
        context = Utilities.actionsGlobalContext();
        putValue(SMALL_ICON, ImageUtilities.loadImageIcon(ICON, false));
        putValue(NAME, Bundle.CTL_HelloIconAction());

    public boolean isEnabled() {
        return null != context.lookup(Project.class);

    public void actionPerformed(ActionEvent ev) {
        JOptionPane.showMessageDialog(null, "Hello colorful project.\n" + context.lookup(Project.class).toString());

    public JMenuItem getPopupPresenter() {
        return new JMenuItem(this);

[1] http://wiki.netbeans.org/DevFaqChangeMenuItemToolbarAppearanceForAction
[2] http://forums.netbeans.org/topic40762.html
[3] http://wiki.netbeans.org/DevFaqAddIconToContextMenu


The result:
Shows the result

See sample code at https://github.com/markiewb/nb-api-samples/tree/master/ContextMenuWithIcon

NetBeans IDE module development with JRebel

This post is mostly obsolete: See http://wp.me/pIpWO-n0 for an updated version.

In my previous post http://wp.me/pIpWO-5M i showed you how to create your own nbm-modules with the help of JRebel. Today i will show you how you can use JRebel to fasten up the development of the NetBeans IDE platform modules.

So if you want to use JRebel to “instantly reload” your compiled changes to a locally compiled bleeding-edge-development-version of NetBeans IDE you have to follow these steps:

  1. checkout the sources
  2. run “ant” to compile the sources and build a NetBeans installation
  3. open a module to be changed from the checkout sources
  4. create or open \nbbuild\user.build.properties
  5. add the line: tryme.args=-J-noverify -J-javaagent:d:/tools/JRebel/jrebel.jar -J-Drebel.log=true (update the path to the correct installation folder)
  6. create or generate a jrebel.xml in the sourcefolder of the module – let the JRebel-plugin do this for you
  7. run the module against the previously compiled version of NetBeans IDE (now called “target-platform“) using the context menu-entry “Run” (you will see the default JRebel headers in the output window, which means JRebel is loaded, and the Target-IDE will be opened)
  8. make your changes to the code, compile via F9
  9. go back to “target-platform“, do your actions again and the changes are reloaded instantly

FYI: The info about the correct location was taken from http://wiki.netbeans.org/DevFaqNetBeansFullHack