Clusters and Feature Packs for NetBeans 6.0

This is a working draft.

Problem/Motivation

The new NetBeans installer will allow the user to select feature sets for installation. This should replace the separate installers for packs used in 5.5 for profiler, mobility, etc. This customization could also be used to let the user deselect parts the current standard distribution if they do not wish to use it - for example Java EE support, database support, etc. The goal of this customization is to optimize the download size - the user will only download what she intends to use. It will also reduce the set of installed components which affects the startup time of IDE, memory consumption and the complexity of IDE user interface (number of options in menu, number of templates, etc.).

1. We need to defined the granularity of feature sets. Individual modules are clearly too low level (e.g. JSP editor is broken up into about 4 modules). The current packs may be too big. Enterprise pack includes SOA, BPEL, and XML, and its installer already asks the user to select which of these three to install.
2. We need to define what feature sets will be available in NetBeans 6.0 and which modules belong in which feature set.
3. How should the feature sets be implemented? How does the concept of feature sets correspond with clusters?
4. Integration with runtimes. The new installer is capable of installing JDKs, application servers, databases, etc. Some of these may be componentized (e.g. Glassfish) and there may be ties between the runtime components and/or runtimes and NetBeans feature sets.

Content of Feature Sets

These are potential feature sets:

• NetBeans Platform and NetBeans IDE: infrastructure, VCS, tasklist, editing XML, HTML, etc.
• C/C++
• Java SE (projects, editor, debugger, profiler)
• Visual Swing (a.k.a. Matisse) including visual DB in Swing
• Java ME (should some optional parts be a separate feature set?)
• Web Apps - probably including visual development and DB-centric web apps
• Java EE: EJB, Application Client, EAR

Questions:

• DB support (connecting to DBs, editing and running SQL, creating tables, etc.) should be included if one of the selected feature sets requires it, but probably does not need to be shown separately
• JAX-WS - support in Java SE should be part of Java SE feature set, similarly as JPA support? Should WS support be part of Java EE set or web apps or separate?
• Should XML support be separate? Is there any demand for it to not be included? (For example for C/C++ developers it may not be so common to use XML?)
• SOA, BPEL - TBD by Todd
• Ruby, PHP - each should probably be a separate feature set, there is not much overlap between users of PHP and Ruby. Could also be part of web apps (especially if integrated with WAR).
• Phobos (if included in NetBeans) should be part of web apps? Or a separate cluster?
• Client side (browser) JavaScript support should be part of web apps
• JVM scripting should be part of Java SE support?

Implementation of Feature Sets

Jarda points in his document about split of IdeX cluster that clusters were not primarily meant to serve as feature packs, they are API compatibility units. In particular they should not be changed every release to fit marketing requirements which drive the definition of feature sets.

Regarding development process, a cluster is a set of modules developed and released simultaneously and also for this reason there are less strict requirement for stability of APIs used between modules within one cluster then for dependencies between clusters.

Moving modules between clusters is costly as shown in JPAInIdeCluster.

We should make it possible to create a new revision of one feature set without changing the other feature sets. This means that the implementation of a feature set should ideally be as independent of the other feature sets as possible. As a result of these parameters it seems that we need to be able to separate parts of the IDE into clusters and build feature sets out of them. In other words one cluster should not be split into multiple feature sets.

Auto Update

Auto Update since NB6.0 would like to introduce grouping of modules to logical units which are handled in AutoUpdate transparently to users. Described at AutoupdateGroupsModulesTogether.

AutoUpdate's use-cases cover browsing IDE installation, installing updates of installed features and searching and installing new features into IDE. Proposed Feature Sets should be handled in AutoUpdate as units presented and handled in AutoUpdate UI. -- JiriRechtacek