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.
Product Version: NetBeans IDE Dev (Build 200903250219) Java: 1.6.0_11; Java HotSpot(TM) Client VM 11.0-b16 System: SunOS version 5.11 running on x86; UTF-8; es_ES (nb) Userdir: /export/home/antonio/.netbeans/dev I think there're weird dependencies between the following modules: CVS -> IDE Platform -> Editing Files -> CSS Visual Editor -> [...] All Javascript Modules. So to summarize: to add CVS support to a NB RCP Application you end up having to add *LOTS* of modules. I was wondering if a dependency with IDE Platform is really mandatory, and if it could be removed and substituted with dependencies to some different modules.
The reason is that in reality, CVS *does* depend on some parts of IDE Platform. Internally, IDE Platform is composed of many individual submodules, but in the Plugins dialog, it is represented as a single visible item. Internally, individual submodules can be enable or disabled, but the principle we follow is that each item visible in the Plugins dialog should be either *entirely* enabled or *entirely* disabled. The dependency of CVS on IDE Platform enforces this. BTW, how do you deal with deal with the IDE Platform module (ide.kit) and its submodules in your RCP application? Is it included, or not? Are some of its modules included? What is the build process you use to assemble the entire application? This could help in finding a solution for your request. In essence, the dependency of CVS on IDE Platform is not mandatory, if you do not include most parts of IDE Platform in your app.
Hi, I can understand that, from an users perspective, the Plugins Dialog groups "submodules" in bigger components. (I don't understand "submodules", though, I just know about "modules" and "clusters". Is IDE Platform a "cluster"?). But from a NB RCP developer point of view this is a problem. A NB RCP developer should be able to include only those "submodules" that require dependencies. If the CVS module requires *some* "submodules" from "IDE Platform" then a NB RCP developer should be able to select those "submodules", and not the whole "IDE Platform" module. With the current Plugins Dialog I *must* select IDE Platform, even though CVS depends only on some submodules (i.e., answering your question: the dependency *IS* mandatory from the Plugins Dialog). I imagine this should be marked as a RFE and moved to people working on NB RCP stuff (is that apisupport?), so that that dependency between CVS (or any other) and IDE Platform is better handled.
I agree with reporter that this dependency is incorrect and harmful to RCP developers. (This is not an apisupport issue - the dependency cannot be worked around.) There are likely other examples of similar problems. I think the root issue is "the principle we follow is that each item visible in the Plugins dialog should be either entirely enabled or entirely disabled" which IMHO is a goal that should be abandoned in favor of precise dependencies. If the UI of Plugin Manager needs to change to indicate that a "plugin" is technically disabled while some of its "interesting" dependencies are enabled, then that is a PM issue. For 6.7 I would recommend removing gratuitous kit -> kit dependencies that were introduced during the 6.7 cycle.
I would like to add that, as an IDE user, I am also in favor of being able to see and enable/disable individual modules. The change in 6.1 (IIRC) to show a very minimal list of modules in Plugin Manager was detrimental. IDE users are, by their very nature, technical people and are therefore more likely to prefer the flexibility of seeing a more granular list of modules.
The _granularity_ of plugins is a somewhat different issue. The problem here is not that the plugins are too coarse-grained as such (which may or may not be a problem for IDE users), but that there are artificial dependencies between plugins (which is definitely a problem for RCP users).
> which IMHO is a goal that should be abandoned in favor of precise dependencies Well, I think this must be a case by case decision. In some cases, the lack of these dependencies causes real bugs, e.g. there used to be a situation when you disabled the database modules, and the db explorer continued to be enabled, because it was needed by something like SOA. It is more correct to tell the user that by disabling databases, SOA will also be disabled. However, in the case of versioning system modules I agree - these intersect with IDE Platform in modules such as diff or editor options, so there is not really any danger of user confusion. I will remove the dependencies in IDE Platform from CVS, Subversion, Mercurial and Local history modules - I have the change locally, will push tomorrow.
Right, if "Databases" is a collection of things really needed by "SOA" then the dep makes sense. But we need to be very careful with deps on "IDE" or other vague collections.
Fixed: http://hg.netbeans.org/web-main/rev/47192c081095
Hi, I'm glad to hear this is to be included in next releases!! Thanks!! (it isn't included in 6.7M3 though). Thanks, Antonio
Integrated into 'main-golden', will be available in build *200904030200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/47192c081095 User: pjiricka@netbeans.org Log: #161403 - removing dependencies of versioning modules on ide.kit, as they are not really needed.
Working great!! Thanks!! I'm setting this as verified (I assume this is the way to go?)