If you have a module file created using the Module
template (this will
appear with the special icon ), this is a
special type of JAR which can also be manipulated in terms of the Open
API's module format specification.
Also, any JAR created by the JAR Packager (with a *.jarContent
information file) will be handled as a module provided that it contains
the magic tag OpenIDE-Module
in the manifest.
You can assemble your module like any other JAR, so refer to the JAR Packager documentation for details. To use the special features of the module JAR, look at the properties of the node, and expand it to show its children. You may want to turn on the Property Sheet, or simply double-click the JAR file to pop up its properties.
The main node's Module Properties sheet has an overview of the module's global attributes. At a minimum, you should specify a code name (suggested: a significant package name used by code in the module), and a display name which the user will see in different contexts. You can also specify the version of the module and any dependencies it may have on its environment. Refer to the Modules API for more details. Note that localization of attributes such as display name is not supported here; please refer to the Modules API and manually edit the manifest.
The Manifest Parsing sheet tells you if there are problems with your manifest, either because it is just not syntactically a valid manifest, or some settings are not usable by the Modules API. If you have a bad manifest, a red X will appear on the module's node. You can see details of the ptoblem on this sheet; use the ... button to see a long message.
Underneath this node you will see several subnodes. Each of these represents a category of object you can develop which can be included in a standard place in the module. Any such existing objects will be shown within each category. To add objects to the manifest, copy them in the Explorer and paste them onto the category node. (You may need to compile Java classes first.) Do not forget that if you are creating a module JAR, you will need to explicitly include all of the required files in the JAR, as well as making the manifest entry.
Each object node has at least two properties in the OpenIDE Manifest sheet. Resource Path gives the path to the object as listed in the manifest. Exists in JAR lets you check whether the JAR file currently contains the object; this must be True if you want the module to work. Various types of sections have additional special attributes as given by the Modules API, which you may edit directly here without touching the manifest.
You may remove an object from the manifest by deleting its node.
You can also manipulate the JAR just like any other with the JAR Packager's generic features, so for example you can add files to the JAR or manually edit its manifest. Refer to the general IDE documentation for more details.
When you have the module selected, you can just
click Execute
to install it right away into the IDE for
testing purposes.
If you make some changes to your code in the Repository,
then execute it again, the module JAR will be rebuilt and reinstalled--that is, its
uninstall
and install
methods will be invoked,
and the changes you have made will be visible. (First, make sure you close
all open windows created by the module, etc.)
For technical reasons having to do with file locks, the module will actually be installed from a temporary file whose name ends in -test.jar, and this filename changes each time; the IDE should delete these files when it is done with them, but if not it is harmless to delete them yourself.
A bare manifest
having the correct magic tag will also be recognized (any file ending in
*.mf
or beginning with mf-*
with OpenIDE-Module
). Such module manifests
are also recognized as belonging to modules, and you can verify the manifest format
as for full module JARs. Cutting-and-pasting in objects to different sections
also works to add things to the manifest, but of course you cannot really add files to it;
sooner or later there must be a JAR to make a module out of.
You can edit the manifest as plain text, and any changes in either direction are reflected immediately (including errors, so this is a good option if you are not comfortable with the syntax). It will show up in the Explorer named according to the module display name, if any; check the Name property for the actual name of the manifest file on disk.
You can get the same effect of testing modules dynamically without the API Support by adding -J-Dnetbeans.module.test=true to the IDE command line, and right-clicking on Tools | Options | ... | Modules to add a new "testing" module that can be dynamically reloaded. Or, start with a regular module, make it reloadable, disable and then enable it. (This system property is automatically turned on by the API Support too.)
Read more about using XML layers as part of a module's installation. Also read about using Ant to build modules rather than the JAR Packager.
NBM (NetBeans Module) files are used to package
and distribute modules together with libraries and other files they need. See
the Auto Update web page for
more information on this format. NBM files are a kind of ZIP files; to mount
them in the NetBeans Filesystems tab, choose
File | Mount Filesystem... | Archive File
and in the second panel, choose All Files under
Files of Type: (since otherwise the *.nbm
extension will not be recognized).