There are four basic ways a module can install configuration data or objects. Three of the ways are declarative - these mechanisms are preferred.
If you are writing a module that has an API you want other modules to plug in to, you probably want to read when to use which registration mechanism.
A file in META-INF/services in the module JAR
For global services, singletons and such, this is the preferred way. The general format is to create a plain-text file whose file name is the name of the interface being implemented - for example, creating a file called org.openide.awt.StatusDisplayer. Then in the content of that file, put a single string, which is the fully qualified name of the class being implemented - for example, com.foo.mymodule.MyStatusDisplayerImpl.
What exactly you put in META-INF/services is a contract between you and whatever module is providing the interface and will, presumably, do something with what you put there. What's really happening is that you are adding your implementation of this interface to the default lookup.
This pattern is commonly used for modules which require a singleton implementation of some interface to be available in the system. To use it, simply create the directories META-INF/services underneath the source root of your project, and put what you want there, and it will be included in your module JAR automatically.
Any module can specify interfaces that it would like other modules to register instances of. For example, the basic Project support module asks that each module that implements a project type (the things you see in the New Project wizard in NetBeans) register their ProjectFactorys there.
To get an instance of something registered this way, call
If there can be more than one registered object of this type, you can get them all as follows:
Collection c = Lookup.getDefault().lookup( new Lookup.Template (TheInterface.class)).allInstances();
Registering objects in the System Filesystem
The system filesystem allows for more detailed information in registering objects. It is a virtual filesystem composed of XML fragments from all (well, most) of the modules in the system. The top layer of the system filesystem is $USERDIR/config which is where changes that are written at runtime are put.
The system filesystem is composed of folders. Some folders have special meanings to the system; what folders exist and are meaningful depend on what modules you have installed. For example, the core window system defines the folder Menu/, which contains subfolders - one for each menu in the main window's menu bar. If you add an instance file? to the folder Menu/File called com-foo-mymodule-MyAction.instance, an instance of com.foo.mymodule.MyAction will be created, and a menu item will be put on the menu for it.
For more details on registering objects, defining an order in which they should appear, etc., see the XML layers FAQ item. In the short form, a module registers a layer by including a line in its manifest (if you are using NetBeans module support in 5.0 or later, you already have a layer file):
which points to an actual XML file by that name inside the module JAR file. A layer file is an XML file defining a mini-filesystem:
<filesystem> <folder name="SomeFolder"> <file name="SomeFile"/> </folder> </filesystem>
Registering objects in the module's manifest
Some types of objects are installed by adding a section to the module manifest. This is the oldest form of declarative registration in NetBeans, and is still used for a few things, but no new kinds of manifest-based registration will likely be added to the APIs. In particular, it is the way DataLoaders are registered:
Name: org/netbeans/modules/povray/PovDataLoader.class OpenIDE-Module-Class: Loader
You can also register context-sensitive actions this way, but this style of action registration is on its way to deprecation.
Important: add this section at the end of the manifest, and make sure there is a blank line above the Name: line. Also make sure there is at least one newline after the last line since the Sun JDK's manifest parser may have a bug causing it to silently ignore the last line of a manifest file if there is no newline after it!
Programmatic registration - ModuleInstall classes
The module system allows you to provide a ModuleInstall class, which runs some code during startup or when the module is loaded, and can run cleanup code when it is uninstalled or disabled. This is the least desirable way to do things, because running code on startup means slowing down startup. Before you use such a class, be sure there is no declarative way to do what you're trying to do.
To have some code run on startup/installation/uninstallation/etc., add a line like the following to your module's manifest file:
This line should be part of the group of lines at the top of the manifest, with no blank lines before it. It is a pointer to a class file inside the module. The class file must extend the class org.openide.modules.ModuleInstall.
Source: NetBeans FAQ