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 know there's been a discussion to this, but options panel|build is not very intuitive! User might be confused, he selects some modules or clusters in module list, but changes don't take effect until branding checkbox is checked. My solution: Rename Build branch to Branding and place branding checkbox there, so it's clear that checkin'/uncheckin' this has an impact on whole branch of branding settings including module list. Or another solution: If branding checkbox is not checked,make module list's checkboxes non-editable, because the don't have an effect. Otherwise user might be very confused, that he still develops against IDE, although he's checked only platform cluster!
I'm not sure what problem you're describing. You *can* exclude clusters and/or modules without setting up branding. Or you're supposed to be able to. When filing a bug report, stick to raw facts: what build you were using, what you did in precise order, what you saw, what you expected to see instead.
Steps to reproduce: - run IDE - create new suite - invoke properties of the suite and uncheck all clusters except platform6 (means you want to develope against platform) from Module list panel - run the suite -> NB5.0 started - not platform ! - now select "Use basic branding information for branding" checkbox - run the suite once again -> Platform started Hope, it helps. Tomas, please provide exact steps to reproduce in the future.
True, run.xml#-prepare-as-app is wrong; it ignores the list of disabled clusters. (Disabled modules should still work.) I think before it was passing an explicit --clusters param to nbexec, but I don't think that can be passed to netbeans/nb.exe. Could rewrite this target to not use netbeans/nb.exe at all, only nbexec, but then we would need to explicitly add back in default branding for the target app - which will harm usage of e.g. Creator as a target platform - and will break various common NB features like default proxy setup under Gnome or screen menu bar setup under Mac OS X. So I am not sure what to do here. Maybe we have to do three modes: -prepare-as-platform; -prepare-as-app; and a new -prepare-as-app-with-disabled-clusters, which would use nbexec and ignore the problems I just mentioned.
Possible beta candidate?
Jesse, I don't think so. Do you want to fix it for Beta?
Up to QA, just suggesting, as it is a visible functional regression.
I am not sure it's regression, because the functionality was not implemented in NB 4.1 ;) But, if you think you can fix it soon, we have no objection. Let us know, when you'll get the fix. I think it has to be mergerd to the beta branch till tomorrow evening (at least we need to test it).
Regression vis-a-vis 5.0 dev builds, I meant.
Actually pretty easy.
Now even if the application name & branding have not been configured, the suite is run in "platform mode" if you Run it when there are any excluded modules and/or clusters. This means that e.g. the default branding of the "platform" (e.g. NB IDE) will not be enabled. But that is not necessarily wrong, if you were e.g. excluding the nb5.0 cluster anyway. committed Up-To-Date 1.9 apisupport/harness/release/run.xml
seems to me like a correct behaviour! Verified in 20051005, closing