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: | Updates of invisible modules not offered in Plugin Manager | ||
---|---|---|---|
Product: | platform | Reporter: | Jesse Glick <jglick> |
Component: | Plugin Manager | Assignee: | dlipin <dlipin> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | anebuzelsky, apireviews, av-nb, mmirilovic, pjiricka, sreimers, tpavek |
Priority: | P1 | Keywords: | API, API_REVIEW_FAST, UI |
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Bug Depends on: | 170812 | ||
Bug Blocks: | |||
Attachments: |
API change diff
Overall implementation new version of impl, including minor fixes and new unit test. No change to api in comparison with the previous patch |
Description
Jesse Glick
2008-07-25 19:23:48 UTC
Refinement to previously suggested UI: in the case that there is one and only one installed visible module which depends on the invisible module being updated, use that visible module's display label in the UI. Hi Jesse, I see what you say but it's designed PM behaviour, let me recap the design from my point of view: * less granularity modules for end-users. In other words, separate whole functionality in IDE into visible features aka plugins * each feature consists from several "infrastructure" module which are hidden and transparent for end-users * it means hidden module I(mpl) is serving to one or more features K(it) to offer its proper functionality * alone update I1.1 of module I1.0 is not enough to make it deliverable to end-users * once feature K find update I1.1 as value added to its functionality, then it will apply for this update (technically to increase itself version 1.0->1.1 and increase dependency K1.1->I1.1) That's the design in my understanding. In my point of view I should close it as WONTFIX. On the other hand I see it's not easy to live with this concept sometimes: * Sustaining team have to pay attention for finding visible ancestor for each patch delivered post NetBeans release (but the sustaining team can make it) * code changes contributor of 'I' module has to change visible ancestor on each version of 'I' module How to help there? 1) Show updates of 'I' even though no feature apply for it. I'm afraid this way will make end-users confused because they don't know anything about infrastructure modules, it would be a step back in less granularity to end-users. Moreover, such update will be visible only in Updates tab and not among Installed and end-user has no feedback whether update is installed or not. In this case, it has to have a review of HIE due to non-trivial UI change minding more and more update will be uncovered. I think it means RFE for next release for reasons upcoming NB6.5 UI freeze. 2) Show warning that a catalog contains some updates which are not covered by any feature. Log such information as warning for module developers. Document the concept somewhere in wiki and link on it from that warning message. I guess it's feasible for NB6.5. In this case I'm going to track it as less-urgent issue in NB6.5. What do you think of it? Thanks I agree that it would be useful to at least have a warning in console that an update was found for a hidden module which will be ignored. The <verifyupdatecenter> Ant task could also check for this condition, but this would be of no help to third-party module developers. I still think it would be best for updates of hidden modules to be visible in the UI but with labels of corresponding visible modules substituted. Specifically, look for all kit modules which depend on the module to be updated (excluding those which depend on other such kit modules, i.e. only pick the "lowest" such kits) and display those as updates. For example, if o.n.m.form ("Form Editor") is to be updated, then form.kit ("GUI Builder") would be shown as the update. "in the case that there is one and only one installed visible module which depends on the invisible module being updated" - and Tonda also suggested as a further refinement that a visible module in the same cluster be given precedence. Reassigning to the new "autoupdate/*" owner dlipin. Dmitry, do you plan to integrate this enhancement into NB 6.7 ? This proposed change is more important then ever because the NetBeans sustaining team has hardly any resources to delivering patches in IDE now. We need to make updating IDE as simple as possible, finding a visible plugin for each update has made patch process too complex IMHO. The first diff file is the API change required in order to implement this issue. The second one is the overall change - not final yet, still fixing minor issues. Created attachment 86472 [details]
API change diff
Created attachment 86473 [details]
Overall implementation
Don't forget @since. Diff to ModuleUpdateElementImpl.java is pretty useless. Get in the habit of avoiding gratuitous changes to whitespace, e.g. this elsewhere in the patch: - case CUSTOM_INSTALL:<<EOL>> + case CUSTOM_INSTALL: <<EOL>> Unit tests are certainly in order for a patch like this, which seems to involve rather complex changes to internal logic. Created attachment 86523 [details]
new version of impl, including minor fixes and new unit test. No change to api in comparison with the previous patch
core-main #483bf8626a62 Integrated into 'main-golden', will be available in build *200908242212* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/483bf8626a62 User: Dmitry Lipin <dlipin@netbeans.org> Log: Issue #141714 Updates of invisible modules not offered in Plugin Manager |