There is a new autoupdate task in the API support harness since NetBeans 6.9. It simplifies downloading, upgrading and installing of NetBeans NBM files. It can be useful in wide variety of situations. Some of them are listed here.


Incremental Binary Build

For years the NetBeans developers cried for having incremental binary builds. E.g. don't need to build the whole NetBeans sources by themselves, but download binary bits and just rebuild the module(s) they work on. With autoupdate task this is very easy. Just:

$ cd nball
$ hg pull -u
$ ant update
$ cd your.own.module
$ ant build

and you will get the most up to date bits including changes in your own module.

You can invoke the update target in individual module projects as well. If you provide URL to proper update center, you may use this functionality in module suites and its projects.

Headless Builds

One of the most complicated problems when developing applications on top of NetBeans platform is to set up correct target platform. Some people need just subset of platform cluster, some need additional modules. With autoupdate task this is now easy:

<!-- For property values see "Sample build.xml" in extenal links section -->    
<mkdir dir="${netbeans}/harness"/>
  name="autoupdate" classname="org.netbeans.nbbuild.AutoUpdate"
<autoupdate installdir="${netbeans}" updatecenter="${netbeans.updatecenter.url}">
  <modules includes=".*" clusters="platform[0-9]*"/>
  <modules includes=".*" clusters="ide[0-9]*"/>
  <modules includes=".*" clusters="java[0-9]*"/>
  <modules includes=".*" clusters="apisupport[0-9]*"/>

First of all one needs to get recent version of tasks.jar, which contain the autoupdate task. Then you can just point the task to installation directory and choose modules (from various clusters) that you want to install. The above example sets "small" Java IDE up. The target platform then contains only necessary JARs for development of NetBeans themselves.

# to get 6.8 version, specify:

Both names of modules and names of clusters are specified by regular expressions. Thus one can request an exact code name base of a module or specify multiple modules with various wildcards. The cluster name may be omitted. In such case the requested module is searched among all clusters.

Patching an Installation

An interesting aspect of the autoupdate task is its ability to upgrade to (newer) version of a module. Because of NetBeans versioning information the system is able to find out whether new version of a module is available and upgrade the module only in such situation.

You can however force an upgrade (which is what is used in the apidesign:Netbinox project) to replace one version of a module with another one:

<autoupdate installdir="${netbeans}" updatecenter="${netigso.updatecenter.url}" force="true">
  <modules includes=".*apisupport.*harness.*"/>
  <modules includes=".*apisupport.*project.*"/>

The above code replaces two apisupport modules with version available from different update center.

Working Locally

It is not always suitable to use a catalog with NBM files, sometimes the NBMs lay on a local disk and one just may want to install them properly. This is possible with AutoUpdateTask as well:

<autoupdate installdir="${netbeans}">
  <nbms dir="mynbms">
    <include name="*.nbm"/>
  <modules includes=".*"/>

For installing plugins that are not part of a suite:

<mkdir dir = "/tmp/install"/>
<autoupdate todir="/tmp/install">
  <nbms dir="/tmp">
    <include name="*.nbm"/>
  <modules includes=".+"/>


The build incrementally downloads new versions of modules based on a specification version. This means that if the specification version does not change, the update does not refresh the module, even if the module has changed. So if you'd like to get the latest improvements and fixes in all modules, make sure you do a clean build regularly.

External Links

Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo