Because people build non-IDE applications on top of NetBeans, it's important that NetBeans be as modular as possible.  A platform developer should be able to include just those parts which are relevant to his application.  

The project customizer dialog for a suite project makes it easy to choose which clusters (and which modules within those clusters) to enable, but this has become more cumbersome as the clusters have gotten larger.  The 'ide' cluster is the best example of this.  While I understand why the 'ide' cluster contains modules like 'Project API' and 'Editor Utilities', I don't understand why support for HTML, XML, CSS and JavaScript should be in that cluster.  I'd think having one or more separate clusters for those languages (and having that cluster depend on the 'ide' cluster) makes more sense.

I therefore request that the list of clusters (and modules within the clusters) -- especially the 'ide' cluster -- be reexamined and refactored into several, smaller clusters.  

I found that the 'ide' cluster currently offers the following broad categories, each of which could be the foundation of one or more clusters:

   0. Editor core modules (language agnostic)

   1. UI, API and scanning code for task lists

   2. Diff and Versioning support (both local history and SCM)

   3. Integration API and implementations for Issue tracking and Continuous Integration systems

   4. Debugger support

   5. Project API and UI

   6. Utility modules of general use (e.g. image support, directory chooser, TreeTableView model, terminal emulator, spellcheck)

   7. Embedded browser and support for controlling an external browser

   8. Support for various languages and file types (.diff, manifest, HTML, CSS, JavaScript, HTML, XML, YAML).  

   9. Various local and third-party libraries to support the above.

I think an additional benefit of this refactoring is that unnecessary dependencies between modules will be more obvious with smaller clusters.  For example, the 'Editing Files' module in the 'ide' cluster depends on CSS Visual Editor, which itself has a lot of other dependencies.  It's perfectly reasonable to want to support basic text editing in a platform application without wanting support for CSS and all of its many dependencies.