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.

Bug 141714 - Updates of invisible modules not offered in Plugin Manager
Summary: Updates of invisible modules not offered in Plugin Manager
Alias: None
Product: platform
Classification: Unclassified
Component: Plugin Manager (show other bugs)
Version: 6.x
Hardware: All All
: P1 blocker (vote)
Assignee: dlipin
Depends on: 170812
  Show dependency tree
Reported: 2008-07-25 19:23 UTC by Jesse Glick
Modified: 2009-08-25 02:43 UTC (History)
7 users (show)

See Also:
Exception Reporter:

API change diff (3.22 KB, patch)
2009-08-19 16:49 UTC, dlipin
Details | Diff
Overall implementation (72.01 KB, patch)
2009-08-19 16:49 UTC, dlipin
Details | Diff
new version of impl, including minor fixes and new unit test. No change to api in comparison with the previous patch (90.56 KB, patch)
2009-08-21 11:42 UTC, dlipin
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2008-07-25 19:23:48 UTC
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

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.
Comment 1 Jesse Glick 2008-07-25 19:26:26 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.
Comment 2 Jiri Rechtacek 2008-07-29 11:28:15 UTC
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
* 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
Comment 3 Jesse Glick 2008-07-29 23:37:28 UTC
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.
Comment 4 Jesse Glick 2008-09-15 12:36:53 UTC
"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.
Comment 5 Antonin Nebuzelsky 2008-11-14 15:33:05 UTC
Reassigning to the new "autoupdate/*" owner dlipin.
Comment 6 Marian Mirilovic 2009-02-23 11:06:00 UTC
Dmitry, do you plan to integrate this enhancement into NB 6.7 ?
Comment 7 Jiri Rechtacek 2009-02-23 14:38:20 UTC
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.
Comment 8 dlipin 2009-08-19 16:47:42 UTC
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.
Comment 9 dlipin 2009-08-19 16:49:07 UTC
Created attachment 86472 [details]
API change diff
Comment 10 dlipin 2009-08-19 16:49:36 UTC
Created attachment 86473 [details]
Overall implementation
Comment 11 Jesse Glick 2009-08-19 17:01:26 UTC
Don't forget @since.

Diff to 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.
Comment 12 dlipin 2009-08-21 11:42:06 UTC
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
Comment 13 dlipin 2009-08-24 11:20:18 UTC
core-main #483bf8626a62
Comment 14 Quality Engineering 2009-08-25 02:43:56 UTC
Integrated into 'main-golden', will be available in build *200908242212* on (upload may still be in progress)
User: Dmitry Lipin <>
Log: Issue #141714 Updates of invisible modules not offered in Plugin Manager