-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Restarting workspace after feature installation does not take into account changes to eclipse.ini #166
Restarting workspace after feature installation does not take into account changes to eclipse.ini #166
Comments
Was also reported as https://bugs.eclipse.org/bugs/show_bug.cgi?id=551378 |
IIUC there is already some special handling to support changing the JVM and this change is to ensure other settings are done too. As an implementation idea it may be best to fully restart the eclipse process rather than reusing the existing eclipse process with special handling for what changed. That would mean that all the eclipse.ini settings would be recalculated the same as a fresh launch, and items such as the correct splash screen will be displayed on restart (in cases of updating versions of Eclipse IDE). Change to eclipse executable behaviour requires changes outside this repo as well. |
Note that Eclipse IDE WG Funded Development Effort #24 has been raised to resolve this problem. |
There is a lot of history here - thanks @stephan-herrmann for providing more of it. One main thing that is unclear to me is why restart can't/doesn't do a full cold restart. Maybe no one interested in this in the past had the knowledge necessary to change the launcher, or perhaps a new "restart" mechanism (return code) needs to be added to do a cold-restart. Answering the above will be part of what is needed to successfully resolve this issue. |
@jonahgraham not sure if it is relevant today but some things to consider regarding "cold" restart:
Of course for a single deployed instance (e.g. Eclipse IDE) some or even all of the mentioned things are irrelevant, but the launcher code itself is generic code. |
Thanks @laeubi for the extra context - someone taking on the dev effort should be taking that into consideration to makes sure non Eclipse IDE style workflows continue to work as expected. |
@robstryker or an Equinox committer - the title of this issue has |
Maybe we could start by not allowing "Restart", or by showing an error message "Restart function cannot be used safely because a configuration file was changed. The application will shut down. Please restart it from the usual launcher for the modifications to be taken into account" when restarting, in case we know the eclipse.ini has changed since startup? (comparing file modification date vs process start date should do the trick). |
That's a very constructive suggestion. It is easy to implement compared to trying to relaunch the application completely from scratch on three differ platforms... |
The message is way to complicated for a user to understand, I would make it less "technical" and simply mention that some changes require a shutdown of the application to take effect with the choice to "Only Restart now", "Shutdown Application now", "Do nothing and proceed" or similar. |
The Eclipse IDE WG Funded Development Effort #24 is to implement the complete solution - i.e. not just blocking restart if eclipse.ini is modified. If there ends up being reasons or time delays that prevent getting the full solution implemented and integrated then starting with not allowing restart as discussed in the last few comments makes sense. |
During various discussed I also saw comments about editing the *.ini manually and then restarting. Probably that doesn't work either, does it? It would certainly be very nice (and expected) that a restart properly re-reads everything including the eclipse.ini and the config.ini, regardless of whether it was p2 that made changes or the user. I'm just noting this because I'm not sure that the restart problem is actually a p2 problem rather than purely an equinox launcher problem. |
If you mean |
All, kindly check the linked PRs. |
I'm not sure if it's related, but I suspect so. It can no longer restart a debug launched RCP/IDE application. Trying to restart just terminates the application rather than starting a newly-launched debug session. On the plus side, when testing updating a 2023-12 installation to 2023-04, the splash screen on restart displayed the updated splash screen, so that really great!! 🏆 |
|
I'm on Windows. I think it's reproducible with any launch: E.g., from this from setup: It launches a process like this:
But I debugged further and it's clear that it's intended that the process exits with exit code 24 whereas formerly it was exit code 23. I.e., I debugged an older Eclipse version and saw that here too the process terminates completely but with a different exit code and of course the java process is launched directly, so no native launcher is involved. So I suspect that it is the debug framework that needs to consider the new exit code value. I'll have a look where that code might be. At this point I think there is nothing wrong with your changes but rather downstream needs to be adapted. And, as I said, the new behavior seeing the updated splash screen after an update is really great! |
@merks , I have reproduced the issue. I'll debug on my end. It should not ever exit with exit code 24 in PDE workflow. |
We might be good to revert the other changes if that's the case... |
@merks , Kindly check following PR and see if it handles all the concerns? |
Take a feature installation that has a p2.inf file as follows:
When this feature is installed via the UI, eclipse will come up with a dialog asking you to restart the IDE to apply the software update. When you select "Restart Now", the workspace will restart. The expected changes listed above will be physically added to the installation's eclipse.ini file. But when the workspace starts, these specific add-opens will not be active.
If you then go restart the workbench one more time, the changes are applied to the running VM as expected.
This would indicate a bug in the p2's software update - restart action where it fails to properly recognize or apply changes to eclipse.ini.
The text was updated successfully, but these errors were encountered: