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.
I would like to point the problem with disabled.clusters and disabled.modules suite's properties. I've created FeedReader example from New Project->Samples wizard. It seems, that FeedReader was created based on "default" platform. My IDE has profiler installed => not possible to Run FeedReader before changing properties of Suite and disabling "profiler" cluster. (filled http://www.netbeans.org/issues/show_bug.cgi?id=70799) I consider it as bug in design. It's not correct to use disabled.clusters and disabled.modules. Unfortunatelly, it's not enough to use enabled.modules also. In current situation problem was easily mentioned, but it could be more serious: Suppose, that someone created Suite based on "default" platform. He checked all and prepared distribution. After that he gave me sources and I also build everything (not Run) and prepared distribution based on my "default" platform. Unfortunately my platform has "profiler" cluster => congratulations! My distribution is 10 times bigger, than expected and will never start correctly. The same problem could be with modules, which are added to different clusters of NB Platform. This modules can't be "excluded", because there are no info about them during development => all new will be added on next building distribution. But "new" module could have dependence on anything, that was in exclude list => the same problem as with "profiler" cluster. May be the origin of the problem is the formulating of the goal. Goal shouldn't contain "NOT" in formulating, Goal should be positive. Not: "not include following modules", but better "include following modules with necessary dependences" and special ant task should check it.
As (currently) designed, as explained on the mailing list. Re. having an Ant task to insert dependencies automatically - won't work well. Some dependencies are "soft", i.e. the module will not be disabled due to lack of them, but neither will it work as well as it should (e.g. some GUI elements will be missing which are needed for some functionality of the module to be useful). It is safer to start with the full set of modules and then remove modules which are definitely not needed. Might be more reasonable to have an include list for clusters and an exclude list for modules within a cluster. Will consider it for a future release, but is a potentially incompatible format change for now.
Should leave open for possibility of having e.g. ${enabled.clusters} in a future release; cf. last comment and issue #70799.
disabled.clusters is probably really nonsense - they should be enabled.clusters as the launcher is supposed to enumerate which clusters to use as --clusters property. disabled.modules may have its problems but actually reflect the situation when one uses a cluster shared among multiple applications and that cluster is one day updated to newer version with a new module without recompilation of any of the application built on top. If this happens the new module will be picked up by the runtime and enabled. So the disabled.clusters is a mistake, however the disabled.modules at least mimic the runtime behaviour. Re. compatibility it shall be possible to change the ModuleSelector class to also accept an include list (by default includes everything). Until someone would use the enabled.clusters, the behaviour would be the same. New UI project customizer would use the new property and delete the old one.
Agreed re. 1st and 4th paragraphs. Re. 2nd (and 3rd) paragraphs - interesting point, I hadn't thought of it quite that way. To rephrase a bit: when you build a branded app, what you are really making is 1. A cluster with your own modules. 2. A launcher which specifies a list of platform clusters to use. 3. A set of config/Modules/*.xml_hidden masks refining an included cluster. 4a. A ZIP (JNLP, ...) containing #1, #2, #3, and the appropriate clusters from the target platform. 4b. But alternatively, in principle (not yet in practice!), a package (RPM, MSI, ...) consisting of #1, #2, #3, and a dependency list referring to the desired platform clusters by name, which are assumed to exist as independent packages that could be shared by other apps. For purposes of #4a, the choice between enabled.modules and disabled.modules comes down to choosing the lesser of two evils when you try to upgrade to a new platform which contains a different list of modules: - [disabled.modules] Possibly needing to exclude some more modules in the customizer, either because they cannot be enabled or because you just don't need or want them. Such refinements do not prevent you from rolling back to the older platform or working with either. (Unused excludes are just ignored.) - [enabled.modules] Possibly needing to include some more modules in the customizer; in some cases just to get modules you were already using to be enabled again, in other cases because they introduce new GUI/features which are recommended in the new platform. Such a refinement may work only with the new platform (i.e. you might need to revert your changes to go back to the old platform); though this could probably be fixed by making unused includes be ignored. (A little scarier than ignoring unused excludes!) But for purposes of #4b, only disabled.modules is really correct. The property precisely matches the build product and your development environment matches the runtime environment.
Working on it.
committed * Up-To-Date 1.38 apisupport/harness/release/README committed * Up-To-Date 1.30 apisupport/harness/release/jnlp.xml committed * Up-To-Date 1.18 apisupport/harness/release/run.xml committed * Up-To-Date 1.30 apisupport/harness/release/suite.xml committed * Up-To-Date 1.27 apisupport/project/src/org/netbeans/modules/apisupport/project/layers/LayerUtils.java committed * Up-To-Date 1.28 apisupport/project/src/org/netbeans/modules/apisupport/project/suite/SuiteProject.java committed * Up-To-Date 1.22 apisupport/project/src/org/netbeans/modules/apisupport/project/ui/ModuleActions.java committed * Up-To-Date 1.49 apisupport/project/src/org/netbeans/modules/apisupport/project/ui/customizer/SingleModuleProperties.java committed * Up-To-Date 1.27 apisupport/project/src/org/netbeans/modules/apisupport/project/ui/customizer/SuiteCustomizerLibraries.java committed * Up-To-Date 1.28 apisupport/project/src/org/netbeans/modules/apisupport/project/ui/customizer/SuiteProperties.java committed * Up-To-Date 1.12 apisupport/project/test/unit/src/org/netbeans/modules/apisupport/project/jnlp/GenerateJNLPApplicationTest.java committed * Up-To-Date 1.5 apisupport/project/test/unit/src/org/netbeans/modules/apisupport/project/suite/BuildZipDistributionTest.java committed * Up-To-Date 1.3 apisupport/project/test/unit/src/org/netbeans/modules/apisupport/project/ui/customizer/SuiteCustomizerLibrariesTest.java committed * Up-To-Date 1.10 apisupport/project/test/unit/src/org/netbeans/modules/apisupport/project/ui/customizer/SuiteCustomizerModuleListTest.java committed * Up-To-Date 1.3 apisupport/samples/PaintApp-suite/nbproject/platform.properties committed * Up-To-Date 1.3 apisupport/samples/feedreader-suite/nbproject/platform.properties committed * Up-To-Date 1.9 nbbuild/antsrc/org/netbeans/nbbuild/ModuleSelector.java committed * Up-To-Date 1.39 nbbuild/antsrc/org/netbeans/nbbuild/ParseProjectXml.java committed * Up-To-Date 1.7 nbbuild/test/unit/src/org/netbeans/nbbuild/ModuleSelectorTest.java
*** Issue 72178 has been marked as a duplicate of this issue. ***
The issue is stopper for NetBeans 5.5 Preview. The fix should be merged in javaee5 branch. Thanks.
No way a complex fix like this is getting merged to 5.5. Please see issue #72178 instead.
The problem of this bug is that FeedReader project tries to load jse clusters which depends on excluded NetBeans clusters (enterprise2, ide6). The project should disable jse clusters: infra2, soa1, visdev3, xmltools1, uml3 in nbproject/project.properties.