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.
We have this scenario in our RCP application: 1) the user do a "Check for updates" finding a new update of module A v1.0 (this module depends also on B v1.0 and the user already has that version of B module) 2) the user does not follow the wizard to update, but cancel it, so that the catalogcache stores the information about that update. 3) in the meantime we publish a new version of module A v1.1 and we also increment the dependency of A on B v1.1. This way the user should be forced to update both A and B in order to make A v1.1 works fine. 4) the user now updates the RCP application, WITHOUT REFRESHING THE CATALOG CACHE. This because he did that in the same session or in another session without explicitly do the "Check for updates", but simple clicking on the bottom right balloon that suggests the update (this reflects the data contained in the var/cache/catalogcache file). 5) doing so the user will download only module A v1.1, and at the next restart the RCP app complains that B v1.1 is needed but only B v1.0 is found. We partly fixed this deleting the catalogcache at RCP app closing (not ideal...), but also this does not fix the problem when the user keeps the RCP open and in the meantime we publish new updates. We should somehow force to reload the catalog just before actually doing the installation of updates. Are there any workaround of this? Like disabling the catalogcache? We are doing publication of updates very often, so this is happening quite frequently... And it is very annoying for the user. Also because the module A will be disabled and if B is a new module (first time uploaded to update center) then it will be impossible to install it, since when a module is disabled there is no way to receive its updates....
> Are there any workaround of this? Like disabling the catalogcache? As a workaround you suggest/configure App to run with a switch -J-Dplugin.manager.check.interval=60 (in minutes) to minimize time when users can face this problem. > We are doing publication of updates very often, so this is happening quite > frequently... And it is very annoying for the user. Also because the module A > will be disabled and if B is a new module (first time uploaded to update > center) then it will be impossible to install it, since when a module is > disabled there is no way to receive its updates....
It seems to me a pretty dangerous defect in design, no? Moreover having the automatic update every hour seems a bit extreme... a high frequency can be annoying as well as implicitly say something about the "stability" of the RCP app to our customers' eyes... Is it somehow possible to force a reload of the update centers just before starting the wizard for updating modules? Or disabling the cache somehow?
(In reply to comment #2) > It seems to me a pretty dangerous defect in design, no? I don't think so. Anyway, a patch will be welcome. > Moreover having the automatic update every hour seems a bit extreme... a high > frequency can be annoying as well as implicitly say something about the > "stability" of the RCP app to our customers' eyes... > > Is it somehow possible to force a reload of the update centers just before > starting the wizard for updating modules? Not yet. > Or disabling the cache somehow? No.
No plan to fix it in the near future, patching process of NetBeans IDE doesn't require this change. You can choose some of one of possible workaround in your application: * add switch in etc/app.conf -J-Dplugin.manager.check.interval=60 (in minutes) * or, add switch in etc/app.conf -J-Dplugin.manager.check.interval=EVERY_STARTUP * call somewhere in your code org.netbeans.api.autoupdate.UpdateUnitProviderFactory.getDefault().refreshProviders(null, true) * to write own UI for updating your app * to improve Autoupdate UI yourself and propose it as a patch