Use OSGi service for UI startup handler#798
Conversation
Bundle activators should do as little work as possible. Therefore move the registration of the window listener out of the bundle activation and instead have OSGi call back when the application has started. That's later, that improves startup performance and that should avoid race conditions on the workbench access.
|
for reviewers: the only interesting thing is line 47 of the new event handler class. everything else is either moved code from the activator class, or generated stuff from the eclipse declarative service support. |
|
|
||
| package net.sf.eclipsecs.ui; | ||
|
|
||
| import org.osgi.service.component.annotations.Component; |
There was a problem hiding this comment.
@Bananeweizen My Eclipse is telling me that this import cannot be resolved. Any ideas?
There was a problem hiding this comment.
That package is part of the org.eclipse.osgi.services bundle, which in turn is part of our target platform. The most probable reason for you not seeing it would be that you develop against the running IDE application, not against the target platform. Enable Preferences > Plugin Development > Show current target platform in status bar, so you can always easily see what you are developing against. Then open the *.target file and hit "Set as active target platform".
There was a problem hiding this comment.
I have the correct target platform.
The only way I have found to solve this is to add org.osgi.service.component.annotations to the Import-Package section of net.sf.eclipsecs.ui/META-INF/MANIFEST.MF.
--- a/net.sf.eclipsecs.ui/META-INF/MANIFEST.MF
+++ b/net.sf.eclipsecs.ui/META-INF/MANIFEST.MF
@@ -68,6 +68,7 @@ Import-Package: org.apache.commons.lang3;version="3.12.0",
org.eclipse.ui.texteditor,
org.eclipse.ui.views.markers,
org.osgi.framework,
+ org.osgi.service.component.annotations,
org.osgi.service.event;version="[1.4.0,2.0.0)",
org.osgi.service.prefs
Automatic-Module-Name: net.sf.eclipsecs.ui
Should I commit this?
There was a problem hiding this comment.
That would be okay, since it's not wrong. You could try #831 first, where I explicitly added another bundle to the target platform. I noticed that the relevant package is exported by multiple different bundles in different versions. And maybe that's somehow related to the error that you see:
2 participants
Bundle activators should do as little work as possible. Therefore move the registration of the window listener out of the bundle activation and instead have OSGi call back when the application has started. That's later, that improves startup performance and that should avoid race conditions on the workbench display access.
Fixes #781