Upgrading from 2.6 version to 3.0

There are a few significant incompatible changes introduced in 3.0's version of NBM packaging lifecycle. The result should be easier to setup builds and better support for building NetBeans platform based applications.

  • The lifecycle mappings have changed. There is no more nbm:jar goal and it was replaced by nbm:manifest which is executed at different phase, namely "process-classes", right after the module's classes are compiled.

Important: In order to have maven-jar-plugin to pick up the generated manifest, you need to add the following configuration snippet to your projects with nbm packaging.

    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-jar-plugin</artifactId>
        <version>2.2</version>
        <configuration>
            <useDefaultManifestFile>true</useDefaultManifestFile>
        </configuration>
    </plugin>
  • The project's dependencies that shall end up on Class-Path of the module and now processed transitively. In earlier versions, you had to either explicitly list all such items in the pom as direct dependencies, or list them in the module descriptor. Only transitive dependencies that descend from non-NetBeans module direct dependencies are included, eg. if you depend on module that includes Apache's commons-httpclient, the library will not be included (unless defined in your project directly). Possible trouble makers are transitive depedencies that are defined both in a dependening module and a regular jar dependency. Based on Maven dependency tree resolution, the binary could end up on the Class-Path or not. The resolution to the problem is to define The troubled dependency directly and either define the scope as "provided" if you don't want it included in Class-Path, or keep the default "compile" scope if you want.
  • NBM file is always generated for any NetBeans module project. You can skip the NBM file generation by setting the parameter to nbm:nbm goal, but please be aware that having NBM files in local and remote repositories is crucial for the new tools that create a NetBeans Platform based application binaries.
  • In previous versions the ultimate final binary for the platform based application, was a directory with the cluster(s) of modules. Now a new packaging is defined "nbm-application" that allows for creating a final application zip file, webstartable jnlp files, and an update site. All are constructed solely from the repository content (assuming all relevant modules have NBM files in repositories) and the primary project for the binaries is the "nbm-application" packaging project, unlike in previous versions where the root pom was the primary project and required all included modules to be built as part of the reactor in the same build.
  • The nbm:manifest goal besides generating the manifest, will also check if the runtime dependencies match the actual classes being used in the project and it's libraries on Class-Path. That's analogous to the dependency:analyze goal but takes the NetBeans module system constraints into account (non-transitivity of module dependencies, public vs. private packages constraint etc)
  • The previous versions didn't define the OpenIDE-Module-Public-Packages entry in the manifest file. The result was a deprecated state that made all classes publicly accessible from other modules and printed a warning to the application's log file. In 3.0, we introduced a new optional parameter "publicPackages" that lists all public packages in the module. If not defined, no package is exported as public. See issue MNBMODULE-32 for details. If you have previously placed the OpenIDE-Module-Public-Packages entry in the manifest file manually, it will not be overriden by the new parameter.