Improved Maven-based NetBeans Platform Application Development using JRebel

Some months ago I already blogged about how to tweak the pom.xml of your Maven-based NetBeans platform application so that you can use JRebel to reload your changes. [1] This process has been simplified in the meantime. Thanks to Peter Hansson for letting me know. Steps:

  • Install the JRebel NetBeans IDE Plugin (from the Plugin Center or from your IDE)
  • Make sure “Compile on Save” is enabled for your project.
  • Make sure the “Enable/Disable JRebel” toolbar button is checked.
  • Generate a rebel.xml file: In the context menu of the project choose “Open JRebel panel” and check the checkbox next to your project in the JRebel Panel.
  • Alter the properties section of the pom.xml like this
        <!-- for JRebel 5.x / JRebel 6 Legacy Client -->
            <>-J-javaagent:"${current.jrebel.agent.path}" -J-Drebel.log=true ${}</>
        <!-- for JRebel 6.x (Non-Legacy Client)-->
            <>-J-Xbootclasspath/p:C:\temp\rebelboot.jar -J-javaagent:"${current.jrebel.agent.path}" -J-Drebel.log=true ${}</>

    The NEW and COOL thing is that you do not have to bother yourself with the path of the JRebel jar file anymore. The JRebel NetBeans IDE plugin sets the path to the JRebel jar from your IDE into the Maven property “current.jrebel.agent.path” and you can reuse it in your pom.xml. Now there will be no hardcoded paths anymore, when you check-in your pom.xml to SCM – except the JRebel6 bootclasspath edge-case.

  • run the module – the application with your module and JRebel should start up
  • make changes to your classes and JRebel will pick them up

Here a screenshot to illustrate the previous steps: 2014-09-03_23h34_17 Tested with NetBeans 8.0, JRebel NetBeans IDE Plugin 5.6.2 [1]


NetBeans: Fix Maven dependency issues in the graphical pom.xml view

Recently I noticed that the pom.xml view in NetBeans not only shows you conflicting dependencies but it also provide fixes within this view.

Click on the light bulb (you know it from the quickfixes/hints in the Java Editor) and a conflict resolving dialog will open. Nice to know


NetBeans 7.2: Hint/quicktip for resolving missing dependencies

In NetBeans 7.2 there is a cool hint within maven projects, which allows you to search for dependencies when a class dependency is unknown.

But wait. The hint can be configured too. I optionally searches in your maven repos and shows you all matching gav which may contain the requested class. Cool stuff.

Netbeans module development with JRebel

This post is mostly obsolete: See for an updated version.

In [project]\nbproject\ add the following line

run.args.extra=-J-noverify -J-javaagent:e:/tools/jrebel/jrebel.jar -J-Drebel.log=true


  • This requires a proper installation of jrebel in the path e:/tools/jrebel/
  • Do not forget to generate a rebel.xml into the root of your classpath
  • You have to compile the changed java source manually by Menu->Run->Compile file(“Compile-on-save” is not yet available for netbeans modules)
  • There will be some OSGI-exceptions when running/debugging the application, but class reloading works properly.

Tested with NetBeans IDE 7.1 RC2 (Build 201111302200)+7.1, JRebel 4.5.3

Other resources:

Update: You can also have a look at Javeleon

Update 2: In maven-based nbms you can run modules the following way (JRebel 4, 5)

  • enable “compile on save”
  • generate rebel.xml to /src/main using the context menu of jrebel (this way it will be copied to target/classes)
  • alter the properties-section of the pom.xml like this
            <>-J-noverify -J-javaagent:e:/tools/jrebel/jrebel.jar -J-Drebel.log=true ${}</>
  • run the module the normal way – you will accounter some osgi-exception as mentioned above
  • make changes to your classes and jrebel will pick it up like [207230] JRebel: Reloading class ''.
  • small issue: the jrebel-messages do not appear on the output-window – but in jrebel.log

Update 3:
@mkleint also blogged about JRebel and NBM-development at

[Quicktip] Importing a “dependencyManagement”-section from an external artefact

Situation: You have a parent pom with defined dependencies in the “dependency management”-section. This way you do not have to provide versions for your dependencies. Standard-Maven-Stuff.

New situation: BUT for some reason you have to switch to another totally different parent pom with totally different “dependency management”-section. Your previously declared dependencies have no version, so there will be errors when invoking maven on this pom.

One solution: A cool thing you can do since Maven 2.0.9 is the import of the “dependency management”. So still no versions required for your previously declared dependencies…

This is accomplished by declaring a pom artifact as a dependency with a scope of “import”.

The offical documentation can be found here

Status code 401 on mvn site:deploy?

Are you faced to a 401 status code when invoking mvn site:deploy?

Like this one?
Embedded error: Failed to transfer file: http://server:port/dir/projectname//./changes-report.html. Return code is: 401


  1. check your pom.xml if the site-id in the distribution-section of the pom.xml matches any server-id setting in your settings.xml.
  2. check if the password is still valid!

For example the following pom.xml and settings.xml DO NOT match. Note the difference between BARNAME and FOONAME! This cannot work.


       <!-- does not match FOONAME -->


<?xml version="1.0" encoding="UTF-8"?>
<settings xmlns=""
       <!-- does not match BARNAME -->

maven-surefire-plugin only uses 67MB of heap?

Today i  had to do some merging of artifacts (code and pom.xml). Then i wondered, why the tests didn’t run properly.

java.lang.OutOfMemoryError: Java heap space” was the reason. But why? I didn’t change the tests and i carefully merged the configuration. So i connected VisualVM to the surefire process and saw that only ca. 67MB max heap were available. I reviewed my MAVEN_OPTS, but my settings didn’t apply…

The culprit is a bug. See

The workaround is to place your max heap configuration in the configuration section of the plugin. As seen in the linked bug issue:

    <!-- -->