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:||Inability to update updater.jar|
|Severity:||blocker||CC:||cnguyencasj, jchalupa, jrechtacek, jtulach, krajeswaran, markdey, mmirilovic, non_migrated_user, ttran|
|Issue Type:||DEFECT||Exception Reporter:|
|Bug Depends on:|
|Bug Blocks:||37010, 37119, 48955|
Description Unknown 2003-11-10 23:35:28 UTC
As per http://www.netbeans.org/issues/show_bug.cgi?id=37010: -------------------------------------- Comments From Petr Hrebejk: Updating the updater.jar is not (supported).Maybe it worked by accident but it never was feature of the AU toupdate the updater.jar and will not be. -------------------------------------- This inability to update updater.jar seems to be a serious issue. This means that if any bug is found in updater, then fixes for those bugs can only be made available to users in the next release.
Comment 1 Petr Hrebejk 2003-11-11 09:42:01 UTC
This means that you require the updater.jar to update itself. Please feel free to give advices how to make sure that this works in all cases.
Comment 2 Antonin Nebuzelsky 2003-11-11 10:49:57 UTC
Hrebejk, sorry, but this is NOT an enhancement. This is a regression. It used to work for several releases. I am changing this back to "defect", so that we don't lose track of it. Please, don't close or change to enhancement important bugs which prevent Support from delivering patches.
Comment 3 Petr Hrebejk 2003-11-11 10:56:29 UTC
No this is not regression at all. I already said that this never was a feature of the AU and I'm not planing to make it a feature. (IE it's rather a wontfix enhancement for me). If it worked for you it worked by accident.
Comment 4 Jan Chalupa 2003-11-12 13:43:06 UTC
Changing back to DEFECT. It used to work in the past, now it doesn't. Hrebejk, you say it worked by accident, but I haven't seen any explanation why it doesn't work now and what are the technical reasons why it can't be supported. Until then, I consider it a DEFECT and a REGRESSION.
Comment 5 _ ttran 2003-11-12 14:39:58 UTC
No, updater.jar cannot update itself, at least on Windows. When it's running the file is locked by JVM, one cannot rewrite it. It may work on Unix, but definitely not Windows even in the past unless they changed something in the JVM This is a similar situation to runide.exe, one cannot update it. What is the bug which forced us to update the updater.jar? Even if it is a serious bug, it's already too late. We are in chicken-and-egg, Catch-22 situation. Autoupdate facility just have to work.
Comment 6 Petr Hrebejk 2003-11-12 14:47:37 UTC
Yes that was one reason for why it never was supported,. Another reason is that it does not seem smart to update something you are just loading classes and resouces from. Are you sure it worked are you sure that it did not copy the updater.jar into user dir where it is not used? Anyway may I ask how an never supported feture can turn into regression?
Comment 7 Antonin Nebuzelsky 2003-11-12 15:36:01 UTC
To Trung's question: > What is the bug which forced us to update the updater.jar? We don't need to fix a bug in updater.jar now, but we did it in the past. See the bug #29875. This fix was delivered to the users of Sierra ME because the bug prevented them from downloading an ME update. The post-install hook was not executed by the Updater if userdir path contained spaces. This was fixed and delivered via autoupdate.nbm (where updater.jar was included - thus noone could have assumed updating updater.jar is not supported). And AFAIK it worked fine. On Windows.
Comment 8 Marian Mirilovic 2003-12-01 10:49:08 UTC
reassigne to Jirka - new owner of autoupdate
Comment 9 Unknown 2003-12-22 17:33:31 UTC
> This means that you require the updater.jar to update itself. > this never was a feature of the AU.If it worked it worked by accident. Is the above limitation documented? Else shouldn't this issue be considered a bug/regression in so much as it used to work? Also, the severity of this issue really depends on how stable updater.jar is and how likely will there be a need to release fixes for it. QA can adjust the priority of this issue depending on the stability of updater.
Comment 10 Jan Chalupa 2004-01-07 16:11:42 UTC
> Is the above limitation documented? Else shouldn't this issue be > considered a bug/regression in so much as it used to work? This is actually an outstanding issue that was pointed out long time ago (see issue #24361). Even though it reportedly worked in the past, there is no guarantee it would work in general. Functionality provided by updater.jar is relatively simple and stable, and the inability to update it via AU is not an urgent issue at this point. However, it is likely that this feature will be required in the future and so it's desirable to have it implemented in the next (post-3.6) release.
Comment 11 Jaroslav Tulach 2004-06-25 08:21:00 UTC
*** Issue 43618 has been marked as a duplicate of this issue. ***
Comment 12 _ ttran 2004-06-25 08:42:13 UTC
not for Promotion D -> TM = future
Comment 13 Peter Zavadsky 2005-01-26 22:26:15 UTC
Chau, how is this important for us? What is a difference between our and NB need of this? I am decreasing the priority.
Comment 14 Peter Zavadsky 2005-01-27 21:44:09 UTC
Adding Chau, so she could answer the previous question.
Comment 15 Ch Nguyen 2005-01-27 22:07:19 UTC
I understand that this is a difficult issue to fix. Unfortunately, we are increasingly depending on the autoupdate functionality to deliver the update bits for our product and there are a few missing features in autoupdate we need that will in turn require the updater to update itself. What if the format of the NBMs change, etc? So it would be very important to have updater to update itself (including on Windows) as a critical need. Having said that, I don't have any problem if you defer the enhancement until "future" releases. But I would like us to keep the same priority P3 if possible. Thanks.
Comment 16 Jiri Rechtacek 2005-01-31 10:28:42 UTC
What about a extra functionality of AutoUpdate client (not the Updater)? The client will check any extra catalog or any extra section in the common catalog, if there is a updater of Updater will start new task: install new updater.jar in some specific folder (other then originaly updater.jar placement) and the launcher will check this folder before run IDE and do upgrade of updater.jar. Not easy or outright way to do the task to update updater.jar :-(
Comment 17 Jan Chalupa 2005-01-31 14:52:56 UTC
Re Jiri's proposal: Might work. However, unlike the usual autoupdate scenarios, the user would be required to explicitly exit the IDE and restart it for the changes to take effect. Instead of restarting the IDE automatically, it could just exit and instruct the user to restart manually. It would require changes to the launchers, of course. And it would still not allow for updating the .exe launchers themselves (which is another requirement).
Comment 18 Unknown 2005-01-31 18:02:08 UTC
The ability to update updater.jar itself may not really be required, provided other requirements are met by providing appropriate features. For instance, refer to the issue 48955: updater splash cannot be updated since it is part of updater.jar. To solve this, the spalsh gif can be moved out of updater.jar in which case it can be updated independently. Other such requirements can be collected from other users like cnguyencasj and implemented. I think, as long as updater.jar is maintained as simply a very small core that merely copies files and delegates everything else, it will not matter if it can be updated by itself.
Comment 19 Jiri Rechtacek 2008-01-29 11:52:14 UTC
Autoupdate part and linux launcher changes were integrated: http://hg.netbeans.org/main/rev/ca876906f0be http://hg.netbeans.org/main/rev/7d00288bc6a3 http://hg.netbeans.org/main/rev/052996bac140 Now I'm waiting for update of windows launcher.
Comment 20 t_h 2008-02-04 09:34:55 UTC
Windows launcher part, changes: http://hg.netbeans.org/main/rev/413e0e0704e7
Comment 21 rbalada 2008-09-02 15:51:49 UTC
Marking VERIFIED. We had an opportunity to verify this implementation works well when we were preparing NB 6.1 Patch2.