Aug 282012
 

A new version of the nbm-maven-plugin has been released – version 3.8 is now ready to be used. 😀 The documentation for the new version can be found here. To build your platform application with the new version of this Maven plugin, simply change the version of the plugin in the parent pom.xml to 3.8.

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>nbm-maven-plugin</artifactId>
    <version>3.8</version>
    <extensions>true</extensions>
    <configuration>
        <brandingToken>${brandingToken}</brandingToken>
        <cluster>${brandingToken}</cluster>
    </configuration>
</plugin>

You are probably now wondering why this release is noteworthy. I have been waiting a long time for this, since it provides 64-bit launchers support! This means that if you are running the IDE on a 64-bit JDK, and you run a Maven-based NetBeans Platform application from the IDE, you will see the application’s output as expected in the Output window of the IDE. (See this post for more background information.)

In this release the use of the modules.xml file is deprecated in favour of specifying the properties in the pom.xml itself. Have a look at the nbm:nbm goal documentation for more information about the new properties. They include author, licenseFile and licenseName.

Aug 232012
 

I can almost not believe that it has been a month since the release of NetBeans 7.2! Time flies indeed. This week I decided to download the latest development build to experience first hand what the NetBeans development team has been up to since.

As soon as I opened the first Java source file in the new version (I am using the development build from 20 August 2012), it struck me that something looks different. I couldn’t place it at first, but then when I selected a bracket something new and useful appeared. 🙂 Bracket matching has been around for some time, so lets look at what the bracket matching in 7.2 looks like. (The source code shown here comes from the NetBeans Platform splash screen, from a NetBeans 7.2 dev version.)

Bracket Matching in NetBeans 7.2

Bracket Matching in NetBeans 7.2

So in short, when you select a bracket the matching one gets highlighted in yellow. That is very useful indeed. However, in the development versions another cool feature was added.

Brackets in NetBeans Development Build (20 August 2012)

Brackets in NetBeans Development Build (20 August 2012)

In the margin, you can now see an extra bracket (indicated by the arrow in the screenshot above) that shows you how far the block contained in the brackets stretches! This definitely makes the information more visible.

Edit (29 August 2012): I noticed an even more awesome part of this feature today! If you have the closing bracket selected with the line where the bracket was opened scrolled outside the current view, it will show up at the top of the file! See the screenshot below.

Showing the Opening Line

Showing the Opening Line

Aug 212012
 

The NetBeans Platform Application I am working on is required to update itself silently, before the user interface appears. Most of what we used comes from Jiri Rechtacek’s excellent post How to update NetBeans Platform Application silently? It is highly recommended that you read that before reading the rest of this post, otherwise this will make no sense! 🙂

Edit: Also have a look at Geertjan’s blog entry entitled How to Push NetBeans Plugins Silently to End Users? for related information.

I ran into one interesting problem, probably due to the fact that all the update stuff happens before the GUI is ready in our particular implementation. When there are updates available for the first time, unit.getAvailableUpdates() is always empty. Only once the updates have been found while running the user interface, would the updates appear in that list on next start up. So after much debugging through the NetBeans Platform source code, I found out that the update items are read from a cache. And I had to force the providers to read from the update server to overcome that. The solution finally was as simple as just adding this:

List updateUnitProviders = 
        UpdateUnitProviderFactory.getDefault().getUpdateUnitProviders(true);
for (UpdateUnitProvider provider : updateUnitProviders) {
    ProgressHandle handle = ProgressHandleFactory.createHandle(
            provider.getDisplayName());
    try {
        // the second parameter forces update from server when true
        provider.refresh(handle, true);
    } catch (IOException ex) {
        Exceptions.printStackTrace(ex);
    }
}

On a related topic: there is another way to update an application. Simply put the .nbms in the update/download folder as described by Geertjan in hist post update/download.

Aug 142012
 

Functional testing with JellyTools is fairly unfamiliar territory for me, so this morning I decided to spend some time to learn how it works with a Maven-based NetBeans Platform Application. JellyTools is a library based on Jemmy, which allows you to manipulate GUI components during automated functional testing.

My first attempt at following the Writing JellyTools Tests Guide almost succeeded. I created a JUnit test in one of my modules and modified it according to the guide. I also added a test dependency on org.netbeans.api:org-netbeans-modules-jellytools-platform. The test compiled and was executed as expected, but the error message returned by the test was that the class org.netbeans.Main was not found.

So I decided to try moving it to the application module. And that did the trick!

Now I have the following test class in my application module:

import java.util.logging.Level;
import junit.framework.Test;
import org.netbeans.jellytools.JellyTestCase;
import org.netbeans.jellytools.TopComponentOperator;
import org.netbeans.jemmy.operators.JButtonOperator;
import org.netbeans.junit.NbModuleSuite;

public class FirstScreenTest extends JellyTestCase {
    
    private JButtonOperator _btn;
    private TopComponentOperator _tc;

    public FirstScreenTest(String name) {
        super(name);
    }

    public static Test suite() {
        NbModuleSuite.Configuration conf = 
                NbModuleSuite.createConfiguration(FirstScreenTest.class).
                clusters(".*").
                enableModules(".*").
                failOnException(Level.INFO).
                failOnMessage(Level.SEVERE);
        conf = conf.addTest("clickButtonTest");
        return NbModuleSuite.create(conf);
    }

    public void clickButtonTest() {
        System.out.println("test case: click button");
        _tc = new TopComponentOperator("TC");
        _btn = new JButtonOperator(_tc, "Button");
        _btn.push();
    }
}

When I test the application (right-click on the application project and choose Test), the GUI is started up and the first button on the first screen is successfully pushed by the testing framework. 🙂

Useful Links

And only after writing this I also found the useful pages below. Where were they hiding earlier? 🙂

And here are some resources on running these tests as part of a Jenkins build.

Aug 082012
 

The nbm:build-installers Maven goal allows you to build the platform application installers using Maven, as I wrote about in an earlier blog post. Yesterday I decided to investigate how to configure the installer when building it using that goal.

The first thing that can be customised is which platform(s) to create installers for. This can be configured in the IDE from the application project’s properties, under the Build > Installer category. I chose to build an installer only for Windows. And when I looked at the pom.xml for the application project, I found the following:

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>nbm-maven-plugin</artifactId>
    <configuration>
        <installerOsLinux>false</installerOsLinux>
        <installerOsMacosx>false</installerOsMacosx>
        <installerOsSolaris>false</installerOsSolaris>
    </configuration>
</plugin>

Looking at [1] (see Useful References below), we see that there are a number of other properties that can be set in addition to those now set by the IDE. This includes the parameters that get passed to the template.xml file via the userSettings property. To understand what this actually means, run the nbm:build-installers goal and have a look at the target folder of the application. In the folder targetinstallernbistub you will see the file template.xml. It is the ant script that will get executed during the process of building the installer. And that is the script that the properties get passed to.

The first useful thing is setting the icon that is displayed in the installer when it is running (see also [2]). After adding the icon, the same section in the pom.xml now looks like this:

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>nbm-maven-plugin</artifactId>
    <configuration>
        <installerOsSolaris>false</installerOsSolaris>
        <installerOsMacosx>false</installerOsMacosx>
        <installerOsLinux>false</installerOsLinux>
        <userSettings>
            <nbi.icon.file>${basedir}/src/resources/icon.png</nbi.icon.file>
        </userSettings>
    </configuration>
</plugin>

However you will most likely not want to stop at the icon, but also change all the other images in the installer (see [4]). The template.xml provided with NetBeans 7.2 does not allow this out of the box. But the changes are simple (see [3] for some info towards the bottom of the page and also [5] as an example of a template.xml). First lets add a new property called nbi.instleftcorner.file that will specify the location of the image to be displayed at the top left of most of the installer wizard pages.

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>nbm-maven-plugin</artifactId>
    <configuration>
        <installerOsSolaris>false</installerOsSolaris>
        <installerOsMacosx>false</installerOsMacosx>
        <installerOsLinux>false</installerOsLinux>
        <userSettings>
            <nbi.icon.file>${basedir}/src/resources/icon.png</nbi.icon.file>
            <nbi.instleftcorner.file>${basedir}/src/resources/left.png</nbi.instleftcorner.file>
        </userSettings>
    </configuration>
</plugin>

Then we create a copy of the template.xml file and specify the templateFile property in the pom.xml:

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>nbm-maven-plugin</artifactId>
    <configuration>
        <installerOsSolaris>false</installerOsSolaris>
        <installerOsMacosx>false</installerOsMacosx>
        <installerOsLinux>false</installerOsLinux>
        <templateFile>${basedir}/src/resources/template.xml</templateFile>
        <userSettings>
            <nbi.icon.file>${basedir}/src/resources/icon.png</nbi.icon.file>
            <nbi.instleftcorner.file>${basedir}/src/resources/left.png</nbi.instleftcorner.file>
        </userSettings>
    </configuration>
</plugin>

The final part of the puzzle is changing the template.xml file to also copy the new file (see [5] again for a more complete example). As a quick fix, I just added the following

<copy file="${nbi.instleftcorner.file}"
    tofile="${installer.build.dir}/ext/engine/src/org/mycompany/installer/wizard/wizard-description-background-left.png"
    overwrite="true"/>

to the -prepare-icon target. Now when the nbm:build-installers goal is executed, the custom template.xml is copied including this change and the wizard-description-background-left.png image will be replaced before the installer gets built. The same can be done for any of the images. 🙂

Useful References

  1. NBM Maven Plugin documentation
  2. Developers FAQ Create Installers
  3. JIRA Build installers goal proposal
  4. Geertjan’s Blog: Customizing the NetBeans Platform Installer
  5. template.xml from osm2garmin

Edit (4 October 2012): Another useful resource:

Edit (1 February 2013): Timon Veenstra of AgroSense provided the following additional very useful information:

“If you want to adjust only the installation folder for windows, you will need to copy the default template.xml and adjust this part:

<replacefilter token="{product-install-directory-name}"         
        value="${suite.props.app.installdir}"/>
<replacefilter token="{product-install-directory-name-windows}" 
        value="${suite.props.app.installdir}"/>
<replacefilter token="{product-install-directory-name-macosx}"  
        value="${suite.props.app.installdir}"/>

If you want to adjust all of them, you could change your branding token. But beware that the branding token should be the same as the parent artifactId (without -_[0-9]).”

Also read Timon’s article entitled How to Change a NetBeans Platform Executable Icon with Maven for more valuable information!

Aug 032012
 

Even after working with a Maven-based NetBeans Platform application for a few months, there are still lots of new things that I discover every week. 🙂

Quite a while ago I was looking in detail at the update center for our Maven-based NetBeans Platform application. And I wanted to change the module author that appears in the Plugins UI. Only today did I find out how to accomplish this, and as with all things Maven it is simple once you know how.

In the parent pom.xml of the application, just add the following:

<organization>
    <name>Hermien Pellissier</name>
    <url>http://www.pellissier.co.za/hermien</url>
</organization>