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:

The NetBeans Platform itself has the udpate tracking name core/kit, the code base name org.netbeans.modules.core.kit, and the related JAR is modules/org-netbeans-modules-core-kit.jar.

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:

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):

Obtaining the update tracking name of a module

The table shown in the previous section has mainly been constructed by following the latter approach—with the exception of the modules’ update tracking names. They actually are not obtainable by either approach. Instead, you are required to download a stand-alone binary distribution of the platform. After unpacking the archive you will recognise a file named module_tracking.xml:

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.

Module-module dependencies

These are best taken from the Project Properties window of the corresponding source project as shown in the next figure for the Actions APIs module: