This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
The current "disabled.modules" property in platform.properties causes two major problems for standalone platform application developers: 1. When the platform version is updated or extended, the set of available modules can change which requires updating the disabled.modules property to prevent the platform application from uselessly growing in size over time. 2. Keeping required modules separated from ones introduced by a platform upgrade is a serious exercise in long-term memory, and newcomers to the project are truly doomed. Also, in project properties the user currently specifies enabled modules so changing it to disabled.modules in the properties file goes against all intuition.
(In reply to comment #0) > 1. When the platform version is updated or extended, the set of available > modules can change which requires updating the disabled.modules property to > prevent the platform application from uselessly growing in size over time. Right, but the alternative is for the app to not work at all because it is now missing newly required indirect dependencies. No plans to fix in stated form, though see DependencyBasedModuleIncludes proposal for another possible direction which would obviate this issue.
On the other hand, it's *much* easier to resolve the dependency issues you mentioned than it is to try and figure out which unnecessary modules got added to the project. When things break with enabled.modules, you click "Resolve" in the application properties. When things get altered with disabled.modules, you have to: 1. Find an old dist. build of your application. 2. Write down all the modules which were included with the build. 3. Go through every section of modules in application properties looking for any new check marks which weren't included in the earlier build, and uncheck each of these. 4. Click "Resolve" in case you removed one which was an actual new dependency. Both disabled.modules and enabled.modules require the user to perform Step #4 if the set of modules included with the platform changes. Only disabled.modules requires application of steps 1-3, which means disabled.modules is more cumbersome than enabled.modules under *every* update scenario.
(In reply to comment #2) > When things break with enabled.modules, you click "Resolve" in the application > properties. Not necessarily that simple. There are often new modules which are not direct dependencies of anything in your suite but which are in practice needed for the app to function normally. Fixing this mechanically is not necessarily possible. Anyway, as I said, I am not about to waste time changing this system without dealing with the more general issues listed in DependencyBasedModuleIncludes. Also note that Maven-based apps can at your option use either includes or excludes, since Maven dependencies are by default transitive.