We could consider getting rid of the facility to exclude individual modules from an app. Instead, assume that no platform modules are included by default, unless they are listed as (possibly indirect) dependencies of some modules in the suite. (You still need to create config/Modules/*.xml_hidden entries for anything that should be excluded.) The key here is that you could pick up big "blocks" of functionality very easily by depending on "kit" modules (AutoUpdate-Show-In-Client: true), just as you do when using Plugin Manager; new standalone modules would by default depend on the "Platform" kit module, and for new suites a "branding" placeholder module could be created with this dependency. Such a system would align much better with how Plugin Manager works in 6.1+, where clusters are not directly relevant and feature modules are combined into overlapping kit modules. This would allow us to eliminate the Modules list in the Libraries panel and simplify the life of Platform developers.

This is one reason I suggested that every suite be created with a dedicated kit module (even for non-app suites I think it makes sense), which would be a convenient place to put branding, would be marked AutoUpdate-Show-In-Client: true, and would be a natural place to add (runtime-only) dependencies on miscellaneous platform modules you decided you needed in your app. This kit module would be the "face" of the suite as far as Plugin Manager is concerned. For an application suite, you would likely want to also have it be marked AutoUpdate-Essential-Module: true so that the modules you ship cannot be turned off. The kit module would also be the logical place to put JavaHelp and update centers.

For some large and advanced applications it would make sense to have more than one kit module so that users can decide to install only certain pieces. That's fine and the developer can configure that; you would still likely want one "low" kit module containing branding and some basic dependencies, but also some "higher" kits with optional features.

A kit module should normally also express (runtime-only) dependencies on the other invisible modules in the suite. Adding such dependencies automatically from the build harness would perhaps make sense for single-kit suites but not for multi-kit suites. In the case of modules, we have an automated test which fails in case the update center contains some non-autoload/eager modules which are invisible but not depended on by any kit, because these would essentially be ignored by Plugin Manager. Perhaps the suite build process could run a similar test. It's not critical for applications, where you would be shipping all your modules from the start anyway (though you could not update them if they failed this test); it is critical for suites intended for download over AU.

Eventually I think we should do the same thing for nbbuild, replacing our current hard-to-manage "cluster configs" with a simple list of those modules we would want visible in Plugin Manager immediately after doing an IDE build.

(tomwheeler) I am strongly in favor of this. Whenever we upgrade to a new version of the platform (IDE), we find that there are many additional modules which were previously not there. The workaround is to exclude them, but this is fragile because the exclude list will change over time and must be maintained. Including only those clusters/modules I want in the app is a much better approach. I suspect this comes with the implicit danger that my module list will also need to be maintained (so that new dependencies are properly handled when changing to a new platform version), but that will be much less work.

See also: ModuleSystemModestProposal#Cluster_config_replacement Bug #106183

Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo