Over a million developers have joined DZone.

On the NetBeans Platform Build System (Part 3)

· Java Zone

Discover how AppDynamics steps in to upgrade your performance game and prevent your enterprise from these top 10 Java performance problems, brought to you in partnership with AppDynamics.

In part 1 and part 2 of this series, Hermien Pellissier, from Saab Systems Grintek in Johannesburg (read about their work for the South African National Defence Force here), discussed the structure of the NetBeans Platform build system. In this part, she addresses three related areas that you should be aware of when working with the NetBeans Platform build system.

4. You must define ‘nbplatform.default.harness.dir’

If you create platform applications in the NetBeans IDE, and only ever build them on a developer PC, you will probably never encounter the dreaded “You must define ‘nbplatform.default.harness.dir’” error. However, if you try to build the platform from the command line on a build server, especially if the server is running some flavour of Linux, you will sooner or later run into this issue. Since there are several aspects involved, and different solutions available, lets explore how the harness produces this result.

This exact error message only occurs in NetBeans 6.5 and earlier. Since version 6.7 the check has been changed, and more recently the error message has been changed to be more descriptive.

Let’s start off by discussing where this check occurs and how the variable is normally defined on a developer PC. The check to see whether the variable is defined, is done in the generated build-impl.xml. If you inspect the suite-private.properties file, you will see that the user.properties.file property is defined there. And it points to the build.properties file containing the nbplatform.${nbplatform.active}.harness.dir property. If we look at the relevant parts of the file structure diagram, we can see the same path defined there:

File structure showing where the harness.dir property is defined.

Figure 9. File structure showing where the harness.dir property is defined.

By explicitly passing the relevant properties (nbplatform.${{nbplatform.active}}. netbeans.dest.dir and nbplatform.${{nbplatform.active}}.harness.dir) to ant, a build system can build a platform application without the need for a platform-private.properties file.

If your build server is running Linux, ensure that the folder where the platform and harness resides is accessible to the operating system user that executes the build process.

5. Suite chaining

From 6.7, it is now possible to chain suites. So you could have suite SUITE_A with module MOD_A, and include it in another suite as you would have with a platform module. See Figure 10 for an example.

Suite chaining.

Figure 10. Suite chaining.

The following screenshot of the suite’s properties shows the new features:

Suite properties showing suite chaining.

Figure 11. Suite properties showing suite chaining.

Each suite (project) or cluster that is added here is listed in the cluster.path property.

6. Disabling the Generation of Auto Update Information

I posted this information a while ago on the technews@kitt.co.za blog. However, it is worthwhile including it in this more comprehensive discussion of the build harness. Below is slightly extended version of the same facts.

NetBeans platform application developers will be very familiar with one of the steps in the build process: “Generating Information for Auto Update”. The reason is that it takes quite a while compared to most of the other steps in the process. After a reasonably extensive search of the Internet, I realised I will have to go look for this step myself. Here is the process that was followed:

  • The first step was to search through the NetBeans platform source code (version 6.1, the only source version I had available) for the log message “Generating Information for Auto Update”. This message was found in the source file nbbuild\antsrc\org\netbeans\nbbuild\MakeListOfNBM.java. (The nbbuild source folder contains a number of ant targets that are used in the build process.)
  • Armed with the knowledge that the ant target class that is responsible for this process is called MakeListOfNBM, a search was conducted through the source folder once more to find what the target is called. The ant task is called ‘genlist’.
  • Now a search of the harness folder provided the last bit of information. The ‘genlist’ task is called by the ‘netbeans’ target in the harness/common.xml ant script. If you comment this out, the “Generating Information for Auto Update” step will not be performed.

This is very useful when developing new applications, since it really speeds up the build process significantly if you skip this step. However, it existed for a reason. And that reason is to manage automatic updates when using NBMs. So do be aware that if you skip the Auto Update Generation step, you will not be able to build NBMs.

Commenting the task out is perhaps too hard-coded. It would be better to execute it (or not) depending on a property that is set in, for example, the project.properties file.

Read more in Part 4.

From kitt.co.za.

The Java Zone is brought to you in partnership with AppDynamics. AppDynamics helps you gain the fundamentals behind application performance, and implement best practices so you can proactively analyze and act on performance problems as they arise, and more specifically with your Java applications. Start a Free Trial.

Topics:

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

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

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

{{ parent.tldr }}

{{ parent.urlSource.name }}