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.
Summary: | CVS -> IDE Platform -> Almost whole IDE | ||
---|---|---|---|
Product: | versioncontrol | Reporter: | vieiro <vieiro> |
Component: | Code | Assignee: | issues@versioncontrol <issues> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | CC: | jglick, jtulach, pjiricka, tomwheeler |
Priority: | P2 | Keywords: | ARCH |
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: |
Description
vieiro
2009-03-28 11:33:39 UTC
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. 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?) |