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.
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.
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.
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.
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.
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.
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?
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.
reassigne to Jirka - new owner of autoupdate
> 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.
> 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
*** Issue 43618 has been marked as a duplicate of this issue. ***
not for Promotion D -> TM = future
Chau, how is this important for us? What is a difference between our
and NB need of this? I am decreasing the priority.
Adding Chau, so she could answer the previous question.
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.
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 :-(
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
It would require changes to the launchers, of course. And it would
still not allow for updating the .exe launchers themselves (which is
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.
Autoupdate part and linux launcher changes were integrated:
Now I'm waiting for update of windows launcher.
Windows launcher part, changes:
We had an opportunity to verify this implementation works well when we were preparing NB 6.1 Patch2.