Community
Participate
Working Groups
All calls to PlatformUI.getWorkbench() should be reviewed. The most relevant problem for Oomph is in org.eclipse.ui.internal.progress.ProgressManager.createChangeListener() where the done method does nothing. public void done(IJobChangeEvent event) { if (!PlatformUI.isWorkbenchRunning()) { return; } Presumably this is to prevent problems on shutdown, but when using the JobManager in Oomph's installer, there is never a workbench running. So we need to do the following to ensure that the JobInfo is cleaned up: https://bugs.eclipse.org/bugs/show_bug.cgi?id=510124#c7 That Bugzilla asks us to remove that code, but the code is necessary because of this problem. We also need to monitor the progress log. Is there API for that?
New Gerrit change created: https://git.eclipse.org/r/88333
(In reply to Ed Merks from comment #0) > All calls to PlatformUI.getWorkbench() should be reviewed. > > The most relevant problem for Oomph is in > org.eclipse.ui.internal.progress.ProgressManager.createChangeListener() > where the done method does nothing. > > > public void done(IJobChangeEvent event) { > if (!PlatformUI.isWorkbenchRunning()) { > return; > } > > Presumably this is to prevent problems on shutdown Looking at the code I don't see why it should not do what it does, also on shutdown this should not be a problem. I would try without this code. > We also need to monitor the progress log. Is there API for that? What do you mean by that?
New Gerrit change created: https://git.eclipse.org/r/88356
(In reply to Eclipse Genie from comment #1) > New Gerrit change created: https://git.eclipse.org/r/88333 Ed, if you apply this patch above, does it help or are there other cases where ProgressManager can't be used in Oomph due the calls to workbench related code? I see for example that we have multiple calls to: WorkbenchPlugin.getDefault().getPreferenceStore() and PlatformUI.getWorkbench() in few places there. (In reply to Eclipse Genie from comment #3) > New Gerrit change created: https://git.eclipse.org/r/88356 This patch goes a bit further, but also could brake some more things.
(In reply to Andrey Loskutov from comment #4) > (In reply to Eclipse Genie from comment #1) > > New Gerrit change created: https://git.eclipse.org/r/88333 > > Ed, if you apply this patch above, does it help or are there other cases > where ProgressManager can't be used in Oomph due the calls to workbench > related code? > > I see for example that we have multiple calls to: > WorkbenchPlugin.getDefault().getPreferenceStore() and > PlatformUI.getWorkbench() in few places there. > > (In reply to Eclipse Genie from comment #3) > > New Gerrit change created: https://git.eclipse.org/r/88356 > > This patch goes a bit further, but also could brake some more things. Yes, I'm not sure all these changes are good. E.g., running the background when there is no workbench was probably a good default. I travel this Friday so I really won't have time to visit these issues until mid-February at the soonest. They way I would generally try to test this is a provision an Ooomph development environment with an Oxygen target platform and see if the installer actually works... Right now, all the installers we redistribute use Neon...
Mass move. Please move to a concrete milestone if you plan to work on this item.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
