Some workflows showing how the NetBeans module development support may be used.
Creating IDE Modules
How to use the support to develop modules you intend to plug into the IDE.
The user may first configure a NetBeans platform for use in module development. For this workflow,
a platform could be an installation of (some supported version of) the NetBeans IDE, or any application based
on the NetBeans platform, e.g. a suitably new version of Java Studio Creator. There may be several platforms
configured in the IDE at once; the platform selected for a given module (or suite of modules) is referred to
as the target platform.
This step is optional, because by default the IDE installation the user is running will be used as a target
against which to build modules. This is referred to as the default [NetBeans] platform.
Platform information is stored in the user directory (in build.properties). Currently there is
no support planned for sharing platform definitions among users. However, references to the active platform
are by name only, so each user can set up a platform of a given name with their local installations of the
platform (and possibly sources and/or Javadoc).
If the user already has some modules set up, he can open them using the usual Open Project dialog.
To start work on a new module, the user should use New Project and make an empty module. (No support
for importing existing sources currently planned.)
The user can instead use New Project to make an empty module suite, and then add one or
more modules to the suite. A suite is a collection of somehow related modules. Modules in a suite can refer
to one another via module dependencies. All modules in a suite share the same target platform setting. You
can retroactively make a standalone module part of a suite if you need to split off some of its functionality
into a sister module, for example.
A suite can be opened as a project; its subprojects are the modules it contains.
With an open module project, the user can use Properties to examine and modify basic configuration of
each module. A suite project can also be configured using Properties.
The usual project-oriented UI elements apply to modules: the user can add files, edit files, build, run (i.e.
launch the target platform with the built module in place), debug (similarly to run), unit test, build
Javadoc, etc.
As well as an editable build.xml, a build-impl.xml is generated for the project,
but unlike in other IDE project types it is quite short and does not do the real work of building the module.
Instead, it imports a standard Ant script from a build harness, which by default is contained in
the target platform (which should be distributed as part of most NB-based products). However, as with other
IDE project types, the user can override targets in build.xml, and can also make manual
customizations to project configuration in project.xml and various properties files (as
enumerated in the harness README).
The user can add a library wrapper module to a suite in order to work with preëxisting JAR
libraries.
Various wizards permit the user to add particular elements to his modules that comply with the NetBeans APIs.
For example, if the user wishes to install a menu item which launches a wizard, he could use the template for
an action combined with the template for a wizard, and just write the missing pieces of code: most of the
boilerplate code will be taken care of by the templates, as well as any required registration of metadata
according to the NetBeans module syntax.
When development of a module or module suite is complete, the user can build NBMs (module
packages) for his modules, ready to be distributed for use in the Auto Update wizard. Support is also planned
for generation of a complete Auto Update server descriptor which would make it simple to publish updated
versions of modules from the user’s web site.
Creating Technology Support Modules
How to build simple modules that add the basics of support for a Java technology (based on some library and
code patterns) to the IDE.
Use the targeted technology in the IDE to make a demo application, e.g. a plain Java project using the
technology. Make sure to wrap the JAR(s) in a library using the Library Manager dialog, including Javadoc
and/or sources.
Optionally, configure a platform, but the default platform is likely to suffice.
Make a new module project.
Use the module development support’s wizard to add a new Java library descriptor. Select the library
configured in the first step.
Use the wizard to add a new project template. Select the demo application created in the first step.
Select Run on the module to try it out in a fresh copy of the IDE: make a sample project from template
and verify that the technology JAR is already in its classpath as a library, that Javadoc code completion
works, that the demo project runs correctly, etc.
Create an NBM from the module and make it available for download. The single NBM file will include everything
a NetBeans IDE user needs to get started with the technology: the actual binary, the accompanying
documentation (and perhaps source code), and sample applications.
Creating Platform-Based Applications
How to create an application based on the NetBeans platform using the support.
The user might configure a NetBeans Platform to use. Typically the user would download the Platform binary
from the netbeans.org website and unpack the ZIP file onto disk somewhere, then use the NetBeans Platform
Manager to configure it for use from the IDE. The Platform download will already contain the requisite build
harness; it might also come with Javadoc for APIs contained in the Platform (TBD), in which case this Javadoc
would be ready to use out of the box.
Rather than downloading a dedicated Platform binary, the user might simply use the default platform, i.e.
part of the installed IDE, excluding the IDE modules. (See below.)
The user makes a new module suite project and adds one or more module projects to it. (Various features
needed for the application will be exposed from the suite project, so it will not suffice to make a
standalone module.)
Everything that applies to developing IDE modules can apply to modules used in the Platform-based application
as well. The user can select Run or Debug to test the behavior of his modules together with the
Platform modules.
The user opens the suite project properties dialog and selects a display name for the new
application, a branding token, perhaps a splash screen, etc. The new branding overrides are kept as part of
the suite project, and control the appearance and behavior of the application.
The user can opt to exclude certain modules (or whole module clusters) of the target platform from his
application. Only those modules which the user leaves enabled will be shipped with the application. Various
areas of the UI that display choices from the target platform will take this selection into account. The UI
makes it simple to use the default platform yet exclude non-IDE clusters and modules (just accept a prompt
when initially configuring branding).
The user can build a ZIP file of the application from the suite project, which will include
modules he has developed in the suite;
modules in the Platform he has not disabled;
product-specific branding; and
native (Windows / Unix / Mac) launchers for the application.
Such a ZIP file could later be used as input for an installer such as InstallShield. The IDE might also
provide the ability to make simple native packages.
Alternately, the user can build a WAR (web application archive) containing
modules he has developed in the suite;
modules in the Platform he has not disabled;
product-specific branding; and
JNLP (Java Web Start) descriptors for the application.
Such a WAR could be deployed to any compliant servlet container and used to provision the application to end
users via their web browsers. (Deployment to a plain HTTP server, or even network file server, should be
possible if advanced support for incremental download of updates is not needed.)
