Community
Participate
Working Groups
When installing an application (eg Transmission) that can support some URL schemes (eg magnet://), as a user, I don't need extra setting to configure this as the default application for magnet:// if no other is available. It should probably be the same for the Eclipse IDE: when some new link handler is available (usually after plugin update or installation, upon restart), the IDE should automatically try to register itself as candidate to handle new schemes in the OS, unless some other application already handles it.
@Matthias @Alexander: what do you think about this proposal?
I think that is a good idea. It should only do if no other app handles the scheme. And I am not sure if it should do that automatically or if we should ask the user.
(In reply to Matthias Becker from comment #2) > I think that is a good idea. It should only do if no other app handles the > scheme. Yes. > And I am not sure if it should do that automatically or if we should ask the > user. IMO, it's better to not ask user (other apps don't ask), unless we identify a necessary reason to do so.
How would you trigger this registration and how would you see that something is new?
(In reply to Matthias Becker from comment #4) > How would you trigger this registration and how would you see that something > is new? I'll make a proposal as a Gerrit patch some time later if there is no objection against that.
(In reply to Mickael Istria from comment #3) > IMO, it's better to not ask user (other apps don't ask), unless we identify > a necessary reason to do so. The registration is a quite complex task. On windows writing into Registry, on linux creating .desktop files and registering them and on macOS modifying the info.plist file of the own app and registering that. We don't have much experience with that (in the wild). So there may occur strange issues. So I am not sure if we really should register without asking the user...
> The registration is a quite complex task. On windows writing into Registry, > on linux creating .desktop files and registering them and on macOS modifying > the info.plist file of the own app and registering that. FWIW, registration doesn't really require a .desktop on Linux as far as I could see; I have an Eclipse IDE instance on filesystem, without a desktop file, and it got associated just well with the OS from the preference page. The desktop file might just be useful at "install-time" but in the end, it's xdg who rules the world, with or without desktop files. > We don't have much experience with that (in the wild). So there may occur > strange issues. So I am not sure if we really should register without asking > the user... Let's just put ourselves in user's shoes: do user want to be asked whether they want the IDE to work at best or is it just noise to them? I think our technical limitations and user interaction are 2 totally independent things here and we should reduce the quality of the user interaction to compensate some technical limitations.
This assumes that there is only *one* Eclipse installation on a system. I currently have dozens of installations for many different projects. Which of the installations is registered? Will different schemes be installed to link to different installations? Would it be possible to select which implementation will handle it?
(In reply to Rolf Theunissen from comment #8) > This assumes that there is only *one* Eclipse installation on a system. I > currently have dozens of installations for many different projects. > Which of the installations is registered? Will different schemes be > installed to link to different installations? Would it be possible to select > which implementation will handle it? I don't plan to work on it. For such case, once my proposal is in, it would be up to the user of multiple installations to deal manually with which one is associated (just like it is already the case now). Some improvements can happen later to facilitate this case, but to me, considering it as a hard requirement is just making development and usage much more complex for a minority of users.
New Gerrit change created: https://git.eclipse.org/r/161443
Gerrit change https://git.eclipse.org/r/161443 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=e95570cc9be9cad6e6876a3bd92b1ec1d6365f4c
(In reply to Eclipse Genie from comment #11) > Gerrit change https://git.eclipse.org/r/161443 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/ > ?id=e95570cc9be9cad6e6876a3bd92b1ec1d6365f4c I just verfied with I20200513-1800. I Opent this one: the "eclipse+command" handler was active. I re-selected it manually and restarted. It stayed inactive. Schemes handles by other installations stayed inactive all the time.
One think just came to my mind: The registration of the link handlers is bound to the installation. But this automatic registration does save the information which one it already tried to activate in the workspace. So if I switch the workspace this automatic registration again kicks in. Could this cause issues?
Please reconsider this change at least until bug 558807 is fixed, or fix bug 558807. With this change everyone gets this when starting Eclipse: WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by org.eclipse.urischeme.internal.registration.WinRegistry (file:/C:/eclipse/drops/eclipse-SDK-I20200513-1800-win32-x86_64/plugins/org.eclipse.urischeme_1.1.0.v20200513-0919.jar) to method java.util.prefs.WindowsPreferences.stringToByteArray(java.lang.String) WARNING: Please consider reporting this to the maintainers of org.eclipse.urischeme.internal.registration.WinRegistry WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release This means one can no longer launch Eclipse in a future Java release.
(In reply to Dani Megert from comment #14) > Please reconsider this change at least until bug 558807 is fixed, or fix bug > 558807. > > With this change everyone gets this when starting Eclipse: > > WARNING: An illegal reflective access operation has occurred > WARNING: Illegal reflective access by > org.eclipse.urischeme.internal.registration.WinRegistry > (file:/C:/eclipse/drops/eclipse-SDK-I20200513-1800-win32-x86_64/plugins/org. > eclipse.urischeme_1.1.0.v20200513-0919.jar) to method > java.util.prefs.WindowsPreferences.stringToByteArray(java.lang.String) > WARNING: Please consider reporting this to the maintainers of > org.eclipse.urischeme.internal.registration.WinRegistry > WARNING: Use --illegal-access=warn to enable warnings of further illegal > reflective access operations > WARNING: All illegal access operations will be denied in a future release > > This means one can no longer launch Eclipse in a future Java release. I'm not able to fix Windows issues. However, if there is no fix for bug 558807 , we can consider disabling the job on Windows. That said, the issue could still happen later, when manipulating the preference page.
I quickly checked what happens when the access is denied. Eclipse does start but immediately throws and error dialog in the face of the user and logs an error.
(In reply to Dani Megert from comment #16) > I quickly checked what happens when the access is denied. Eclipse does start > but immediately throws and error dialog in the face of the user and logs an > error. Which java version ?
So technically by reverting auto registration we will postpone the error on windows from start up to later whenever someone uses it. Disabling the functionality on windows until the underlying issues is fixed sounds good to me.
New Gerrit change created: https://git.eclipse.org/r/163209
Gerrit change https://git.eclipse.org/r/163209 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=f010bbc423589b1429901cbdf753aec710c9fcbd
In our tests based on 4.16 master we see that every Eclipse startup produces now such errors in the log. This is most likely regression from this bug, last week tests were fine. !ENTRY org.eclipse.urischeme 4 0 2020-05-19 19:41:06.424 !MESSAGE /users/jenkinsbs/.local/share/applications/_workspaces_socbm262_aloskuto_ws-e4x_opt_hp93000_soc_segments_eclipse_eclipseForTest_.desktop !STACK 0 java.nio.file.NoSuchFileException: /users/jenkinsbs/.local/share/applications/_workspaces_socbm262_aloskuto_ws-e4x_opt_hp93000_soc_segments_eclipse_eclipseForTest_.desktop at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92) at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111) at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116) at java.base/sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:219) at java.base/java.nio.file.spi.FileSystemProvider.newOutputStream(FileSystemProvider.java:478) at java.base/java.nio.file.Files.newOutputStream(Files.java:219) at java.base/java.nio.file.Files.write(Files.java:3424) at org.eclipse.urischeme.internal.registration.FileProvider.write(FileProvider.java:38) at org.eclipse.urischeme.internal.registration.RegistrationLinux.changeDesktopFile(RegistrationLinux.java:100) at org.eclipse.urischeme.internal.registration.RegistrationLinux.handleSchemes(RegistrationLinux.java:56) at org.eclipse.urischeme.AutoRegisterSchemeHandlersJob.run(AutoRegisterSchemeHandlersJob.java:67) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
I'm also not sure what this registration would do if we run multiple Eclipse based application simultaneously on same workstation. The one will win, and others not? Does it make sense, if in one something will work, but not in others? So I see comment 9 was already asked but no answer. *We have* multiple applications running in parallel, for correlation purposes etc. (In reply to Mickael Istria from comment #3) > (In reply to Matthias Becker from comment #2) > > I think that is a good idea. It should only do if no other app handles the > > scheme. > > Yes. > > > And I am not sure if it should do that automatically or if we should ask the > > user. > > IMO, it's better to not ask user (other apps don't ask), unless we identify > a necessary reason to do so. I would at least provide a preference for product integrators not to trigger this job at startup. Right now our "advisor" extends IDEWorkbenchAdvisor (because it is most convenient way), and the way how the job is scheduled right now (directly from org.eclipse.ui.internal.ide.application.IDEWorkbenchAdvisor.initialize(IWorkbenchConfigurer)) doesn't even allow to override that behavior. So top be honest, I don't think we should just throw all the concerns away and work only for the "happy case". So my proposal would be either completely disable this feature for 4.16 or allow it to be disabled via product customization (preference can be hidden from user).
(In reply to Andrey Loskutov from comment #21) > In our tests based on 4.16 master we see that every Eclipse startup produces > now such errors in the log. This is most likely regression from this bug, > last week tests were fine. > > !ENTRY org.eclipse.urischeme 4 0 2020-05-19 19:41:06.424 > !MESSAGE > /users/jenkinsbs/.local/share/applications/_workspaces_socbm262_aloskuto_ws- > e4x_opt_hp93000_soc_segments_eclipse_eclipseForTest_.desktop > !STACK 0 > java.nio.file.NoSuchFileException: > /users/jenkinsbs/.local/share/applications/_workspaces_socbm262_aloskuto_ws- > e4x_opt_hp93000_soc_segments_eclipse_eclipseForTest_.desktop Can you please open a new bug about this? It's actually not caused by the job itself, but it's a bug in URL handling. Same issue would happen by using the Link Handlers preference page. So as it's different enough and this ticket already contains a lot of content about other things, a new one would help. (In reply to Andrey Loskutov from comment #22) > I'm also not sure what this registration would do if we run multiple Eclipse > based application simultaneously on same workstation. The one will win, and > others not? Does it make sense, if in one something will work, but not in > others? So I see comment 9 was already asked but no answer. *We have* > multiple applications running in parallel, for correlation purposes etc. Currently, on Linux, the application that's registered as handler doesn't really matter as opening a URL does sent the request to dbus and the Eclipse application that handles it will be the first one to subscribe to the dbus events IIRC, so the first started one. For this reason, I think the store of application registration doesn't really change things on Linux. On other OSs, I cannot tell about the underlying details; but -on all OS- the job would only register a *single* application as URL Handler and not do anything for URL schemes that are already handled. So if you have multiple applications in parallel, the 1st one will take the default handling; other won't do anything. Then it's up to users to fix the URL handling in the preference page or OS preferences if it doesn't suit them. But this is IMO not a "worse" behavior than it used to. > (In reply to Mickael Istria from comment #3) > I would at least provide a preference for product integrators not to trigger > this job at startup. > [...] > allow it to be disabled via product customization (preference can be hidden > from user). I'll work on it right now.
(In reply to Mickael Istria from comment #23) > (In reply to Andrey Loskutov from comment #21) > > In our tests based on 4.16 master we see that every Eclipse startup produces > > now such errors in the log. This is most likely regression from this bug, > > last week tests were fine. > > > > !ENTRY org.eclipse.urischeme 4 0 2020-05-19 19:41:06.424 > > !MESSAGE > > /users/jenkinsbs/.local/share/applications/_workspaces_socbm262_aloskuto_ws- > > e4x_opt_hp93000_soc_segments_eclipse_eclipseForTest_.desktop > > !STACK 0 > > java.nio.file.NoSuchFileException: > > /users/jenkinsbs/.local/share/applications/_workspaces_socbm262_aloskuto_ws- > > e4x_opt_hp93000_soc_segments_eclipse_eclipseForTest_.desktop > > Can you please open a new bug about this? It's actually not caused by the > job itself, but it's a bug in URL handling. Same issue would happen by using > the Link Handlers preference page. Not sure I can follow, exception above complains about NoSuchFileException, the path looks OK for me (it just points to non-existing file in a non-existing /users/jenkinsbs/.local/share/applications/ directory), and it is thrown by the new job code. Where should be URL handling broken and why it is not related to this feature if it just appeared this week? > So if you have multiple applications in parallel, the 1st one will take the > default handling; other won't do anything. Then it's up to users to fix the > URL handling in the preference page or OS preferences if it doesn't suit > them. > But this is IMO not a "worse" behavior than it used to. Our users are not interested in configuration of the IDE, they want *use* it. If the feature XYZ works out of the box in first Eclipse window, they will expect it works in the second one, and if it doesn't, they will file a bug. If the feature is not active by default, we will have no inconsistency in behavior and no bug. I mean: how an average user should know all the details here and where to change what if there is no hint about "missing" feature at all? > > (In reply to Mickael Istria from comment #3) > > I would at least provide a preference for product integrators not to trigger > > this job at startup. > > [...] > > allow it to be disabled via product customization (preference can be hidden > > from user). > > I'll work on it right now. Thanks. Regarding the existing preference page: I've just discovered preference page for "Link Handlers" (I've never used it before), but it is unchecked by default (no errors in the log) and if I enable it and say "Apply and Close", it is appears unchecked again if I open the preference page again, also after restart. Is this related to this bug or it is different one? If it is not working in my installation / environment - why it is enabled, and if this is due some error - why I don't see any error log?
(In reply to Andrey Loskutov from comment #24) > Not sure I can follow, exception above complains about NoSuchFileException, > the path looks OK for me (it just points to non-existing file in a > non-existing /users/jenkinsbs/.local/share/applications/ directory), and it > is thrown by the new job code. Where should be URL handling broken and why > it is not related to this feature if it just appeared this week? > > [...] > Regarding the existing preference page: I've just discovered preference page > for "Link Handlers" (I've never used it before), but it is unchecked by > default (no errors in the log) and if I enable it and say "Apply and Close", > it is appears unchecked again if I open the preference page again, also > after restart. Is this related to this bug or it is different one? If it is > not working in my installation / environment - why it is enabled, and if > this is due some error - why I don't see any error log? I think they're a bug in the underlying code used by the job and the preference page, not a bug in the job itself, hence why I think a new ticket would be better. > > So if you have multiple applications in parallel, the 1st one will take the > > default handling; other won't do anything. Then it's up to users to fix the > > URL handling in the preference page or OS preferences if it doesn't suit > > them. > > But this is IMO not a "worse" behavior than it used to. > > Our users are not interested in configuration of the IDE, they want *use* > it. If the feature XYZ works out of the box in first Eclipse window, they > will expect it works in the second one The URL Handling is not an Eclipse specific issue, it's an OS topic, and all applications and all protocols may face the issue of multiple instances willing to register for the protocol handlers. And so far, users are still happy to use protocol handlers at OS level for mailto, http, magnet... IMO, the situation for Eclipse IDE and RCP apps isn't better nor worse than for Firefox, it's in the "state of art", and is not a problem worth removing such a feature.
New Gerrit change created: https://git.eclipse.org/r/163268
(In reply to Mickael Istria from comment #25) > (In reply to Andrey Loskutov from comment #24) > > Not sure I can follow, exception above complains about NoSuchFileException, > > the path looks OK for me (it just points to non-existing file in a > > non-existing /users/jenkinsbs/.local/share/applications/ directory), and it > > is thrown by the new job code. Where should be URL handling broken and why > > it is not related to this feature if it just appeared this week? > > > > [...] > > Regarding the existing preference page: I've just discovered preference page > > for "Link Handlers" (I've never used it before), but it is unchecked by > > default (no errors in the log) and if I enable it and say "Apply and Close", > > it is appears unchecked again if I open the preference page again, also > > after restart. Is this related to this bug or it is different one? If it is > > not working in my installation / environment - why it is enabled, and if > > this is due some error - why I don't see any error log? > > I think they're a bug in the underlying code used by the job and the > preference page, not a bug in the job itself, hence why I think a new ticket > would be better. Actually this is bug in the job code, org.eclipse.urischeme.internal.registration.FileProvider.write(String, byte[]). The directory in which the file is supposed to be written doesn't necessarily exist. So before writing a file, one should make sure all parent directories in the path are created. In our case we start tests with fresh user environment, where /users/jenkinsbs/.local/share/applications/ isn't created (yet), Eclipse is the first application trying to create some files there. > > > So if you have multiple applications in parallel, the 1st one will take the > > > default handling; other won't do anything. Then it's up to users to fix the > > > URL handling in the preference page or OS preferences if it doesn't suit > > > them. > > > But this is IMO not a "worse" behavior than it used to. > > > > Our users are not interested in configuration of the IDE, they want *use* > > it. If the feature XYZ works out of the box in first Eclipse window, they > > will expect it works in the second one > > The URL Handling is not an Eclipse specific issue, it's an OS topic, and all > applications and all protocols may face the issue of multiple instances > willing to register for the protocol handlers. And so far, users are still > happy to use protocol handlers at OS level for mailto, http, magnet... > IMO, the situation for Eclipse IDE and RCP apps isn't better nor worse than > for Firefox, it's in the "state of art", and is not a problem worth removing > such a feature. "State of the art" is if everything works consistently. Anyway, given the new preference I can disable this by default for our product and everything will be consistent again.
(In reply to Andrey Loskutov from comment #27) > Actually this is bug in the job code, > org.eclipse.urischeme.internal.registration.FileProvider.write(String, > byte[]). This is called from the job, but this code isn't specific to the job, it's the same one used by the preference page; and for this reason, I'm pretty sure that in similar situation, you should be able to reproduce the stacktrace with the preference page even with the job disabled. So it's a separate issue to me.
(In reply to Andrey Loskutov from comment #27) > Actually this is bug in the job code, > org.eclipse.urischeme.internal.registration.FileProvider.write(String, > byte[]). > > The directory in which the file is supposed to be written doesn't > necessarily exist. So before writing a file, one should make sure all parent > directories in the path are created. In our case we start tests with fresh > user environment, where /users/jenkinsbs/.local/share/applications/ isn't > created (yet), Eclipse is the first application trying to create some files > there. Please create a bug for this specific issue.
(In reply to Matthias Becker from comment #29) > (In reply to Andrey Loskutov from comment #27) > > Actually this is bug in the job code, > > org.eclipse.urischeme.internal.registration.FileProvider.write(String, > > byte[]). > > > > The directory in which the file is supposed to be written doesn't > > necessarily exist. So before writing a file, one should make sure all parent > > directories in the path are created. In our case we start tests with fresh > > user environment, where /users/jenkinsbs/.local/share/applications/ isn't > > created (yet), Eclipse is the first application trying to create some files > > there. > Please create a bug for this specific issue. See bug 563370
(In reply to Andrey Loskutov from comment #24) > Regarding the existing preference page: I've just discovered preference page > for "Link Handlers" (I've never used it before), but it is unchecked by > default (no errors in the log) and if I enable it and say "Apply and Close", > it is appears unchecked again if I open the preference page again, also > after restart. Is this related to this bug or it is different one? If it is > not working in my installation / environment - why it is enabled, and if > this is due some error - why I don't see any error log? See bug 563378.
Gerrit change https://git.eclipse.org/r/163268 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=a5a25433b03a5cd364bfb5ca81e9eeb49876c6a2
New Gerrit change created: https://git.eclipse.org/r/163294
This bug fix caused regression in Eclipse see bug 563429.
(In reply to Alexander Kurtakov from comment #17) > (In reply to Dani Megert from comment #16) > > I quickly checked what happens when the access is denied. Eclipse does start > > but immediately throws and error dialog in the face of the user and logs an > > error. > > Which java version ? Java 9 and beyond where modules got introduced.
(In reply to Eclipse Genie from comment #20) > Gerrit change https://git.eclipse.org/r/163209 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=f010bbc423589b1429901cbdf753aec710c9fcbd > This fix is not complete, see bug 563876.
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/163294 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=28f99818152e28fedffcf0daa61f62ac8e234f13
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/166929
I noticed the following in a JDT UI tycho-surefire runtime test run : (Note the AutoRegisterSchemeHandlersJob at line 48) !ENTRY org.eclipse.ui 4 0 2020-07-28 18:29:04.363 !MESSAGE Unhandled event loop exception !STACK 0 java.lang.NullPointerException at org.eclipse.urischeme.internal.registration.RegistrationLinux.<init>(RegistrationLinux.java:42) at org.eclipse.urischeme.IOperatingSystemRegistration.getInstance(IOperatingSystemRegistration.java:39) at org.eclipse.urischeme.AutoRegisterSchemeHandlersJob.<init>(AutoRegisterSchemeHandlersJob.java:48) at org.eclipse.ui.internal.ide.application.IDEWorkbenchAdvisor.initialize(IDEWorkbenchAdvisor.java:224) at org.eclipse.ui.application.WorkbenchAdvisor.internalBasicInitialize(WorkbenchAdvisor.java:171) at org.eclipse.ui.internal.Workbench$18.runWithException(Workbench.java:1649) at org.eclipse.ui.internal.StartupThreading$StartupRunnable.run(StartupThreading.java:36) at org.eclipse.swt.widgets.Synchronizer.syncExec(Synchronizer.java:236) at org.eclipse.ui.internal.UISynchronizer.syncExec(UISynchronizer.java:133) at org.eclipse.swt.widgets.Display.syncExec(Display.java:5815) at org.eclipse.ui.internal.StartupThreading.runWithoutExceptions(StartupThreading.java:94) at org.eclipse.ui.internal.Workbench.init(Workbench.java:1645) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2792) at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:645) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:556) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:153) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:150) at org.eclipse.tycho.surefire.osgibooter.UITestApplication.runApplication(UITestApplication.java:31) at org.eclipse.tycho.surefire.osgibooter.AbstractUITestApplication.run(AbstractUITestApplication.java:120) at org.eclipse.tycho.surefire.osgibooter.UITestApplication.start(UITestApplication.java:37) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:203) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:401) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:255) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:657) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:594) at org.eclipse.equinox.launcher.Main.run(Main.java:1465) at org.eclipse.equinox.launcher.Main.main(Main.java:1438) Is this related to the change ?
see also https://bugs.eclipse.org/bugs/show_bug.cgi?id=565119 this basically breaks all our tycho tests as the test app does not start
(In reply to Christian Dietrich from comment #40) > see also https://bugs.eclipse.org/bugs/show_bug.cgi?id=565119 > > this basically breaks all our tycho tests as the test app does not start Beside this, the preferences doesn't respect product customization.
OK, closing this again, because I haven't realized that the last Gerrits were made for already closed bug. @Matthias, Mickael: please for all new work create new bugs, do not reuse closed, otherwise we have patches for issues introduced in 4.17 but they are logged to a bug fixed in 4.16.
*** Bug 549580 has been marked as a duplicate of this bug. ***
