Introduction

In the previous articles we have already mentioned some of the platform modules. Except for those constituting the NetBeans™ runtime container the whole picture is incomplete until now. First, let us have a glance at the module table; it is the most important part of this article. Next comes a statistical overview of the module-module interdependencies answering the question which modules are most frequently referenced within the platform. Then we take at look at how the table of all platform modules and accompanying information was figured out.

Overview of all platform modules

The listed modules refer to the platform7 cluster corresponding to the NetBeans™ IDE 6.0. As a matter of fact, the number of platform modules is steadily growing: while the platform of the NetBeans™ IDE 5.5 had 34 modules we now have 46 with the NetBeans™ IDE 6.0.

The text colours of the following table are used to distinguish different items in multi-caption columns. The Module name column lists a few names which are stroken-through: such modules are deprecated. And the API access column points out whether the public API packages exposed by a module are really meant for public use (that is: in your applications or modules) or just for friend modules within the platform. Here comes the table sorted alphabetically by module name:

Module dependency statistics

The following table shows how many times a given platform module is refered to by a module-module dependency by other platform modules:

How to gather module information

Having the overview tables above is a nice thing, but how was all the information assembled? The admittedly tedious work starts with examining the files of the platform7/update_tracking directory and involves these steps explained more thoroughly further below:

1. Open an update tracking XML file; it normally references a module status configuration file as well as a module JAR file.
2. Open the runtime module XML metadata file to obtain the module's activation type and whether the module is activated (or: enabled) or not.
3. Open the JAR file of the module and look at the manifest file to gather information about public packages, friend modules, dependencies and more. Particularly pay attention to the localising bundle given by manifest attribute OpenIDE-Localizing-Bundle.
4. Open the localising bundle: it contains the actual module name and descriptions.

Let us look at these steps in more detail now. From the update tracking directory we pick the Progress API module as an example. Its update tracking file is org-netbeans-api-progress.xml:

A typical update tracking file is just an entry point which refers to files associated with the module (namely the module status configuration file and the JAR file(s)):

The config/Modules/org-netbeans-api-progress.xml file reveals further details such as the activiation type, whether or not the module is enabled (or activated), again the JAR location, and others:

Most information is provided by the JAR file's manifest; it contains a bunch of data like public module packages, friend modules, different kinds of dependencies and many more:

Notice, that the manifest has no locale-specific information in it. These things are kept in the localising bundle file specified by the OpenIDE-Module-Localizing-Bundle attribute; of course, the bundle also contained in the JAR.

Open the bundle within the IDE and figure out the module's human readable name (attribute OpenIDE-Module-Name) and things like the long as well as the short descriptions (OpenIDE-Module-Long-Description and OpenIDE-Module-Short-Description, respectively):

Open that file to gather the last piece of information from the name attribute of the module element:

Remember that the update tracking name is nothing but the relative location of a module's project within the source distribution of the platform. So, if you want to do some source code mining it is a good idea to have a module's update tracking name at hand, as it saves you a number of trials and errors when searching for the corresponding NetBeans™ project.