Skip to content
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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

vogella
Copy link
Contributor

@vogella vogella commented Apr 22, 2022

With this change the PublishedGradleVersionsWrapper is published as
declarative OSGi service instead registering it via the activator.

For #1151

Fixes #?

Context

*/
@Component(property = { "service.ranking:Integer=1" }, service = PublishedGradleVersionsWrapper.class)
Copy link
Member

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?

Copy link
Contributor Author

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.

Copy link
Member

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.

Copy link
Contributor Author

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();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

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?

Copy link
Member

@laeubi laeubi Apr 22, 2022

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.

Copy link
Member

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.

Copy link
Contributor Author

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();
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants