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.
It seems that available updates of modules which are not directly visible in Plugin Manager (only part of one or more kits) are not offered to users. This is a serious problem, as 1. Module publishers unaware of this fact may push updates to a module for a long time without realizing that no one is seeing them (as I in fact have, with autoproject.java). 2. Even if you are aware of the problem, it is often the case that there is no single obvious kit module which is the logical place to increment specification versions; a module might be "part" of several kits. You could push changes to all of these, but even then it is not guaranteed that your update will be seen by all users - someone might be using a third-party module depending on the impl module yet have none of the expected kits installed. Auto Update should check all installed modules for updates and offer to install any updates it finds. How the update of an impl module is presented in the UI is a secondary concern. I would suggest that if a module is to be updated which is "hidden", and there is no module to be updated which is "visible" and which has a dependency on that module, then just display the normally "hidden" module as the update (possibly with some kind of annotation in the UI indicating that it is an implementation module that will not be shown in the Installed list later). To reproduce in a dev build: 1. Make a suite containing impl 1.0 kit 1.0 > impl 1.0 and uncheck "Show in Plugin Manager" for impl. 2. Build NBMs 3. Run fresh copy of IDE. In PM, disable existing UCs, and add updates.xml from step #2. 4. Install "kit". 5. Edit metadata of suite impl 1.1 [new] kit 1.0 > impl 1.0 [as before] 6. Create NBMs 7. Refresh in PM. No updates shown. [bug] 8. Edit metadata impl 1.1 [as before] kit 1.1 > impl 1.1 [new] 9. Create NBMs 10. Refresh in PM. "kit" shown as an update. Install, and impl 1.1 and kit 1.1 appear in module list after restart.
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