Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

On the NetBeans Platform Build System (Part 2)

DZone's Guide to

On the NetBeans Platform Build System (Part 2)

· Java Zone
Free Resource

Learn how to troubleshoot and diagnose some of the most common performance issues in Java today. Brought to you in partnership with AppDynamics.

In part 1 of this series, you were introduced to the NetBeans Platform build system by Hermien Pellissier, who works on NetBeans Platform applications for the South African National Defence Force, at Saab Systems Grintek in Johannesburg, as explained here. Now, in part 2, she introduces you to NetBeans Platform project structures, user folders, and the build harness.

3. The Project, the User Folder and the Build Harness

Firstly, a brief look at the physical structure of a NetBeans Platform project. This is again something that the developer often does not need to know much about since the IDE manages all the details for you. However, when exploring the build harness, this is a good place to start.

3.1 The Project

Let’s start off with a new NetBeans Platform Application (a bare basics suite):

A new Platform Application in project view.

Figure 2. A new Platform Application in project view.

… and now inspect the project in files view…

A new Platform Application in files view.

Figure 3. A new Platform Application in files view.

The build.xml file is the main project build file (called Build Script in the projects view). This file includes the build-impl.xml file in the nbproject folder. The developer is free to edit build.xml since all the automatically generated build details are kept in build-impl.xml.

The file build-impl.xml is responsible for handling a number of project-specific property files, as well as the inclusion of the entry point into the build harness, specifically suite.xml. More about that later. The properties are read from two files:

  • nbproject/platform.properties: This file indicates which platform to use and which platform clusters and more specifically modules form a part of the suite.

  • nbproject/private/platform-private.properties: This file specifies where the user folder, and more specifically build.properties, is located. Note that the files in the nbproject/private folder is by default not checked into source repositories. The idea behind the folder is maintaining data that is private, i.e. specific to a PC.

The build-impl.xml file (as well as build.xml) inherits all the targets from the build harness scripts, such as build, clean, debug, run and build-zip.

It is worthwhile briefly mentioning what is contained in the other files that are not directly involved right now:

  • nbproject/branding folder: The splash screen and other branding related data is stored here.

  • nbproject/private/private.properties: Information that is private to the project in your IDE, such as which files were open the last time the project was saved.

  • nbproject/genfiles.properties: Used by NetBeans to maintain the integrity of generated files. Do not edit.

  • nbproject/project.properties: Properties of the suite such as the application name.

  • nbproject/project.xml: It contains the settings that the IDE requires to handle the project, indicating that it is a org.netbeans.modules.apisupport.project.suite project.

So far, we have covered the following structure (only showing the relevant files):

File structure showing the suite folder and the very first entry point into the build harness.

Figure 4. File structure showing the suite folder and the very first entry point into the build harness.

Before we continue on to the other folders, let’s add a new module called MOD_HarnessExample to the suite and see what happens.

The file view after adding a new module.

Figure 5. The file view after adding a new module.

The new module is created by default inside the suite folder, as seen above. For the purpose of this example, that is perfect. Note that the module has its own build.xml file and nbproject folder. It contains a file we have not encountered yet – suite.properties. It specifies where (relative to the module) the suite that it belongs to is located. The module has no platform.properties files – it inherits those properties from its parent suite.

The build-impl.xml for a module imports the build.xml file from the harness.

Note that a module can also be created as a standalone module, in which case it has no suite.properties file and has its own platform.properties.

Since the module is part of the suite, the suite needs to know where to find this module. The relevant properties are set in the nbproject/project.properties file of the suite:

modules=\
${project.za.co.kitt.examples.buildharness}
project.za.co.kitt.examples.buildharness=MOD_HarnessExample

Now the build file in the suite is able to locate all the modules that it has to build, and is able to call the build.xml file in each one. Let’s take a look at the complete picture now:

The file structure, now including a module.

Figure 6. The file structure, now including a module.

3.2 The User Folder

The user folder is where the NetBeans IDE saves its settings for a specific user on the computer. The location of the user folder is specified in etc/netbeans.conf in the NetBeans installation folder, together with other IDE settings. In 6.7.1, the property is by default:

# ${HOME} will be replaced by JVM user.home system property
netbeans_default_userdir="${HOME}/.netbeans/6.7"

On Windows XP, for example, this is effectively something like

C:\\Documents and Settings\\user\\.netbeans\\6.7

As mentioned earlier, the build.properties file is of special interest to us. The locations of all the platforms configured in the IDE are persisted in this file. For example, the default platform is specified as follows (in version 6.7.1):

nbplatform.default.harness.dir=${nbplatform.default.netbeans.dest.dir}/harness
nbplatform.default.netbeans.dest.dir=C:\\Program Files\\NetBeans 6.7.1

So when the platform.properties file specifies nbplatform.active=default, this refers to the platform as specified above. Remember that the harness folder can be specified independently of the platform folder, so do not assume for platforms other than the default that it will be inside the platform folder.

Let’s add this information to our ever growing diagram:

The file structure, showing the relationships of the build.properties file.

Figure 7. The file structure, showing the relationships of the build.properties file.

3.3 The Build Harness

The build harness folder contains, amongst other things, a number of scripts that are of interest to us. The scripts are shown in the completed diagram below:

Finally the entire structure.

Figure 8. Finally the entire structure.

Read more in Part 3.

From kitt.co.za.

Understand the needs and benefits around implementing the right monitoring solution for a growing containerized market. Brought to you in partnership with AppDynamics.

Topics:

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}