Sep 242012
 

Building an update center for your NetBeans Platform application with Maven is easy – simply call the nbm:autoupdate goal from the parent folder. Unless you choose another outputDirectory, the updates.xml and nbms will be available in the target/netbeans_site folder after the goal is executed.

The interesting tip is this: If you copy other nbms into that folder before running the nbm:autoupdate goal, they will be included in the updates.xml file! This is the easiest way I have found so far to combine modules from different suites into one update center. 🙂

Sep 042012
 

I discovered another cool feature in the latest development builds of the NetBeans IDE. When viewing a pom.xml file in any Maven-based project, you can now see the effective pom. This means that the configuration inherited from one or more parent pom.xml files is shown in this view too. Very useful indeed!

image

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 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>

May 112012
 

The ability to easily build an update center that users of your application can use to update their software, is a very useful feature of the NetBeans Platform. And being able to build this from the command line means that it can be useful on a build server.

For an Ant-based application, you can call the nbms target in the build script of the suite. The nbms and update.xml file will be built to <suite folder>/build/updates. This can also be executed from the NetBeans IDE by right-clicking on the suite project > Package As > NBMs.

With a Maven-based project, you can use the following command in the parent project folder:

[text]mvn nbm:autoupdate[/text]

The nbms and update.xml file will be placed in the parent project folder, under target/netbeans_site.

Apr 242012
 

Everything is subtly (or not so subtly) different between building and running a NetBeans Platform application with Ant and with Maven. When running an application from the IDE, only one instance of the application is allowed to run at a time. The error message displayed when trying to run a second instance with an Ant-based project is clear:

[text]C:NetBeansharnesssuite.xml:502: The following error occurred while
executing this line:
C:NetBeansharnessrun.xml:198: The application is already running within
the test user directory.
You must shut it down before trying to run it again.[/text]

The Maven one is a little less informative, particularly for Java developers who are not used to building .exes:

[text]Failed to execute goal org.codehaus.mojo:nbm-maven-plugin:3.7:cluster-app
(default-cli) on project test2-app: Cannot process etc folder content
creation. C:ProjectsTeststest2applicationtargettest2bintest2.exe
(The process cannot access the file because it is being used by another
process) -> [Help 1][/text]

Hopefully the knowledge that these two things have the same cause will be useful to developers new to developing NetBeans Platform applications with Maven. 🙂

Apr 172012
 

Today I discovered another great new addition to the latest development builds of the NetBeans IDE: building installers from the IDE for a Maven-based NetBeans Platform application!

I am using NetBeans 7.2 development build 201204150400, but I don’t know exactly when this was introduced. In this development build, I can right-click on the the App project in the Projects view and choose Build Installers. The installers are built to the target folder of the app (the output tells you exactly where the files are generated).

As with Ant-based projects, you can configure which installers get built. For Maven-based platform applications, you will find this configuration in the properties of the App project under the Installer category.

You can also build the installers by calling Maven from the command line:

[text]mvn nbm:build-installers[/text]

Have a look at this AgroSense page for related information.

Mar 132012
 

Originally all NetBeans Platform applications were built using the Ant-based build harness. And of course this option is still available in NetBeans 7.1. However, the IDE also has tool support for creating platform applications built with Maven, which was added in more recent versions.

I have been working with the NetBeans Platform since 5.5 days, and I have learned a good deal about the Ant build harness over the years. Last week I started a new job and now I am wrapping my mind around building a platform application using Maven. This is the first of an (as yet) unknown number of articles documenting the lessons that I am learning in this process about the differences between the two approaches. It is my hope that the information will make the mind shift from Ant to Maven easier for other developers. 🙂

One of the first questions that came to mind after I created my first Maven-based platform application, is “where did the Package As… menu go?” The context menu of an Ant-based suite used to contain a lot of separate packaging actions back in the day. More recently, all these actions (including the one that builds a zip file) were moved to the Package As… menu. But for my Maven project, no such menu was anywhere to be found!

After a brief moment of frustration, I decided to have a look at the folder structure of the project once it was built. And there I found a zip distro that looks identical to the one I would have expected from an Ant-based project. As it turns out, this always gets built when you build the application, and is stored in the application/target folder.

Another useful thing in the same location is the userdir folder – this is the equivalent of the build/testuserdir folder for an Ant-based application.

Read the Maven Best Practices wiki page for some more interesting information.