-
Notifications
You must be signed in to change notification settings - Fork 172
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
Moving PublishedGradleVersionsWrapper to a declarative OSGi service #1152
base: master
Are you sure you want to change the base?
Conversation
*/ | ||
@Component(property = { "service.ranking:Integer=1" }, service = PublishedGradleVersionsWrapper.class) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you really need a non default service rank here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you really need a non default service rank here?
If you look at the activator it also sets this ranking so I just replicated it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a final class, it is very unlikley that there are more than one service and even if they seem to be totaly eqivialent so this is most probably obsolete.
Service ranking is only important if there are multiple service of the same type and you need to have some kind of ordering of them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a final class, it is very unlikley that there are more than one service and even if they seem to be totaly eqivialent so this is most probably obsolete.
Service ranking is only important if there are multiple service of the same type and you need to have some kind of ordering of them.
Agree, but changing logic AND implementation is IMHO a bad way. So leaving the priority in should allow @donat to review this easier. And next step could be to remove with a follow-up commit.
@@ -263,7 +262,9 @@ public static Logger logger() { | |||
} | |||
|
|||
public static PublishedGradleVersionsWrapper publishedGradleVersions() { | |||
return (PublishedGradleVersionsWrapper) getInstance().publishedGradleVersionsServiceTracker.getService(); | |||
BundleContext bundleContext = FrameworkUtil.getBundle(CorePlugin.class).getBundleContext(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You should really use a servicetracker here see for example here how to handle such legacy cases:
https://github.com/eclipse-m2e/m2e-core/blob/25d6833f9cf78e0c423155c9d8381f0db8eaa9d0/org.eclipse.m2e.core/src/org/eclipse/m2e/core/internal/MavenPluginActivator.java#L114
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How is the tracker closed in your example?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All services are automatically freed when the bundle stops, you can of course clear them manually if you like also see for a more complete example:
https://github.com/eclipse-platform/eclipse.platform.runtime/pull/28/files
In the current code you do not check for null and you increment the use-count on each call.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Your decisions of course, I usually try to avoid migrating useless/outdated stuff as one has to test this twice then or no one feels to change this later on.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, I update the PR with your suggestion.
With this change the PublishedGradleVersionsWrapper is published as declarative OSGi service instead registering it via the activator. For eclipse#1151
@@ -309,4 +310,20 @@ public static ToolingApiOperationManager operationManager() { | |||
public static ExtensionManager extensionManager() { | |||
return getInstance().extensionManager; | |||
} | |||
|
|||
private static <T> T getService(Class<T> service) { | |||
BundleContext context = plugin.getBundle().getBundleContext(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you might want to check if the plugin !=null
7e55112
to
7040f04
Compare
With this change the PublishedGradleVersionsWrapper is published as
declarative OSGi service instead registering it via the activator.
For #1151
Fixes #?
Context