Community
Participate
Working Groups
Currently, the plugin registry view can show available services, along with each service's registering plugin. In support of ECF's implementation of RFC 119 (distributed OSGi)...see bug #249240, it would be great to show in the plugin registry view (via some custom icon or decorator?) 1) local services that are published for remote access...i.e. those that are registered with the service property 'osgi.remote.interfaces' set to '*' or some String[] of interfaces. 2) Remote services (proxies). According to RFC 119, all such remote services will have the 'osgi.remote' property set and can so be identified. Tim Diekman has identified some icons representing service hosts and proxies...perhaps these could be used in some form in the PDE registry view. Alternatively, for 1 (service host), perhaps it would be nice to have the interface icon that is currently used decorated with a hand offering the interface (just an idea). For 2 (service client), perhaps the service can have something that conveys receiving the proxy.
Jacek ;d?
it sounds pretty cool. So we're just waiting for someone to contribute some cool remote icons :-)
Created attachment 130524 [details] patch Attaching a draft patch, that will make Services with "osgi.remote" property to use icons/obj16/service_registration_obj.gif (which doesn't exist yet :-))
how about a little 'R' decoration? http://www.iconlet.com/search?n=remote
Created attachment 134264 [details] Service: Proxy Icon
Created attachment 134265 [details] Service: Host Icon
Changing Version tag to something more believable. Note that this is not a statement about when the enhancement request will be addressed (the Target Milestone field is used for that); the Version tag should be set to the version of Eclipse you were using when you saw the need for the enhancement.
Created attachment 243137 [details] Icon for remote service proxy Icon to represent OSGi Remote Service imported proxy for a remote service. This icon was created to represent proxies and uses/reuses the symbol used in the RS/RSA specifications.
Created attachment 243138 [details] patch for showing remote service proxy icon in RegistryBrowserLabelProvider Patch to show remote service proxy icon in RegistryBrowserLabelProvider when appropriate...i.e. when the underlying OSGi service is a remote service proxy.
Since this bug was opened in 2009 much has happened WRT the standardization of OSGi Remote Services...formerly known as 'distributed osgi'/rfc119. First, two chapters have been added to the OSGi enterprise specification: Remote Services (chapter 100), and Remote Service Admin (chapter 122). See these chapters for reference http://www.osgi.org/Download/Release5 These two chapters define how to use remote services, and further define a management agent (RSA) for remote services. Also, since 4.3, ECF has fully implemented these two new specifications (enterprise R6 is now being worked on/finished). Here's a reference for ECF's implementation, tutorials, examples, reference documentation, etc: https://wiki.eclipse.org/ECF#OSGi_Remote_Services As well...two pertinent facts: I (Scott) am now on the OSGi Enterprise Experts Group (EEG)...which is defining the R6 specification...and ECF's impl of RS/RSA is under consideration as the reference implementation for RS/RSA in the R6 spec. One area that ECF committers/contributors are turning to for future work (2014-2015) is better tooling...for declaring, creating, implementing, registering, discovering, testing, debugging, versioning, managing Remote Services. There are a lot of tooling possibilities here...e.g. integration/extension of JDT, as well as PDE and/or bndtools. One immediate possibility is to modify the PDE plugin registry view to show remote service proxies with an appropriate icon. This is what attachment 243137 [details] (icon) and attachment 243148 [details] (code patch) do. These patches, however, represent only a small part of what we/ECF is looking to do WRT tooling for remote services. For example, it would be very easy...given the RSA specification and associated classes (i.e. org.osgi.service.remoteserviceadmin.* classes) to provide much more information about remote service hosts and/or proxies to users...very useful for people creating, implementing, testing, debugging and managing remote services. And these tools can/could be made to depend only on standardized classes (i.e. org.osgi classes), but potentially allow some extensibility (e.g. adapters) to allow ECF to expose extra features that ECF's implementation now exposes...e.g. non-blocking/Asynchronous Remote Services: https://wiki.eclipse.org/ECF/Asynchronous_Remote_Services The point of this long posting is to ask more generally (PDE people): whether there is any ability to help out on the tooling work described above. This is something that ECF committers/contributors will be involved in...but if previous work (like the plugin registry) is to be extended/taken advantage of, it would be helpful to do this work cooperatively...i.e. with the support of the PDE team. This would be especially helpful for the knowledge of the existing PDE UI code.
(In reply to Scott Lewis from comment #10) > The point of this long posting is to ask more generally (PDE people): > whether there is any ability to help out on the tooling work described > above. This is something that ECF committers/contributors will be involved > in...but if previous work (like the plugin registry) is to be extended/taken > advantage of, it would be helpful to do this work cooperatively...i.e. with > the support of the PDE team. This would be especially helpful for the > knowledge of the existing PDE UI code. The amount of resources in PDE is quite low. So while it would be great to have improvements around the plug-in registry view, I don't think there will be available committer time to do anything other than review contributions.
(In reply to Curtis Windatt from comment #11) > (In reply to Scott Lewis from comment #10) > > The point of this long posting is to ask more generally (PDE people): > > whether there is any ability to help out on the tooling work described > > above. This is something that ECF committers/contributors will be involved > > in...but if previous work (like the plugin registry) is to be extended/taken > > advantage of, it would be helpful to do this work cooperatively...i.e. with > > the support of the PDE team. This would be especially helpful for the > > knowledge of the existing PDE UI code. > > The amount of resources in PDE is quite low. Yeah...sadly I'm not surprised. If you think resources are low in PDE, try ECF...or for that matter nearly any other EF project that has existed for more than 1 year. >So while it would be great to > have improvements around the plug-in registry view, I don't think there will > be available committer time to do anything other than review contributions. Given this, it seems like a better strategy for us may be to look elsewhere (e.g. bndtools) for collaborative efforts wrt remote services tooling.
(In reply to Curtis Windatt from comment #11) > > The amount of resources in PDE is quite low. So while it would be great to > have improvements around the plug-in registry view, I don't think there will > be available committer time to do anything other than review contributions. I agree Curtis. I will transfer this into a review. Thanks for the hint ;)
> > I agree Curtis. I will transfer this into a review. Thanks for the hint ;) Please take a look at: https://git.eclipse.org/r/38545
(In reply to Wim Jongman from comment #14) > > > > I agree Curtis. I will transfer this into a review. Thanks for the hint ;) > > Please take a look at: > > https://git.eclipse.org/r/38545 Any chance we can get this back on track for 4.5
(In reply to Wim Jongman from comment #15) > Any chance we can get this back on track for 4.5 The changes are well contained and worth considering for 4.5. However, I'm not certain if Vikas will have time to complete the review.
Vikas is there anything I can do to help you make this happen?
(In reply to Wim Jongman from comment #17) > Vikas is there anything I can do to help you make this happen? There are blocking issues for M5 right now. Still worth considering for 4.5, just no time this milestone.
(In reply to Curtis Windatt from comment #18) > (In reply to Wim Jongman from comment #17) > > Vikas is there anything I can do to help you make this happen? > > There are blocking issues for M5 right now. Do you mean related to this enhancement specifically?...or just in general?
(In reply to Curtis Windatt from comment #18) > (In reply to Wim Jongman from comment #17) > > Vikas is there anything I can do to help you make this happen? > > There are blocking issues for M5 right now. Still worth considering for > 4.5, just no time this milestone. Can you please put this on the radar again?
Sure.. I will review and commit this week.
Created attachment 251636 [details] Fake remote service project The attached zip contains a project with a service component that contains the service property that triggers the icon change.
The patch looks fine. I had changed the license year and committed. But I had to revert because of 2 reasons 1) I forgot to change author to Scott Lewis. 2) I dont see a tick mark for CLA for Scott. Scott, can you please sign the CLA agreement?
(In reply to Vikas Chandra from comment #23) > The patch looks fine. I had changed the license year and committed. But I > had to revert because of 2 reasons > > 1) I forgot to change author to Scott Lewis. > 2) I dont see a tick mark for CLA for Scott. > > > Scott, can you please sign the CLA agreement? I don't find any 'Accept' button at the end of this page https://www.eclipse.org/legal/CLA.php and when I go to this page: https://projects.eclipse.org/user/cla/sign I get a 403 Access denied error even though am logged in. I've sent an email to emo about this, but currently I can't see a way to sign/accept the CLA agreement. Also: There is no need for putting my author information in the source.
>>Also: There is no need for putting my author information in the source. It is not author information in source but author information in pde.ui git repository. It is mandatory to put the author name. For CLA issue, I think we will wait for it to resolved. If I find any information, I will update on this bug.
(In reply to Vikas Chandra from comment #25) > >>Also: There is no need for putting my author information in the source. > > It is not author information in source but author information in pde.ui git > repository. It is mandatory to put the author name. Whatever you gotta do. > > > For CLA issue, I think we will wait for it to resolved. If I find any > information, I will update on this bug. I've accepted the CLA form on the page you pointed me to in email. Please try your IP dance again.
Committed http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=111b06bd9c13dc46d49273ccf58a435e33d21efd after changing license year update Thanks Scott and sorry for the delay.
(In reply to Vikas Chandra from comment #27) > Committed > http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/ > ?id=111b06bd9c13dc46d49273ccf58a435e33d21efd > > after changing license year update > > Thanks Scott and sorry for the delay. Vikas what did you implement? The Gerrit change still seems open?
I had committed the patch ( attached with this bug) to show remote service proxy icon in registry view. Did you mean this gerrit patch? https://git.eclipse.org/r/38545 I have a look at this today.
Isnt this gerrit patch same as " patch for showing remote service proxy icon in RegistryBrowserLabelProvider " which is already committed?
(In reply to Vikas Chandra from comment #30) > Isnt this gerrit patch same as " patch for showing remote service proxy icon > in RegistryBrowserLabelProvider " which is already committed? Yes it is the same. I will abandon it. Curtis asked to transform it into a review.
>>I will abandon it. This looks fine. You can probably verify the fix in latest build.
(In reply to Vikas Chandra from comment #32) > >>I will abandon it. > > This looks fine. You can probably verify the fix in latest build. I've verified that things are present in latest build. Thanks. I have one more request. It would be very useful for ECF Remote Services tooling (Mars theme bug 464609) for the PDE RegistryBrowser to allow our perspective/views to be able to set the RegistryBrowser to 'services' groupBy. As things are now, the RegistryBrowser defaults to presenting the runtime plugins. It would be very nice for our users if, when used for the ECF Remote Services tooling (i.e. in our new Remote Service Tooling perspective bug 461000), that the RegistryBrowser could be switched to group by Services rather than Plugins. To do this, we would need to use a new API on the RegistryBrowser class : org.eclipse.pde.internal.runtime.registry.RegistryBrowser public int showGroupBy(int newGroupBy) { int previousGroupBy = getGroupBy(); if (fTreeViewer != null && !fTreeViewer.getControl().isDisposed()) { fMemento.putInteger(GROUP_BY, newGroupBy); fRefreshAction.run(); } return previousGroupBy; } This would allow our tooling to programmatically set the RegistryBrowser to display/groupBy OSGi services (rather than plugins). Would it be possible to get this addition (or something like it) into Mars? If so I will open a new bug, but before doing so I wanted to check with Vikas about timing feasibility.
I am not sure if we can do that since we have an API freeze post M6. ( if such a change is done, it has to be approved). However you can log a bug to track this issue and I can check if we can do something about that for Mars.
(In reply to Vikas Chandra from comment #34) > I am not sure if we can do that since we have an API freeze post M6. ( if > such a change is done, it has to be approved). However you can log a bug to > track this issue and I can check if we can do something about that for Mars. Hi Vikas, I've opened bug 464315. Please see that bug. I've argued there that since the RegistryBrowser class itself is internal/not API that adding a public method for Mars would be worth doing. Please do everything you can to make this happen for Mars, and let me know what else can be done. IMHO Remote Services Tooling actually represents a significant enhancement to PDE, and makes it much more useful for an emerging trend in both IoT and web services development (i.e. the use of ECF's OSGi Remote Services/RSA impl for standardized/open network services).
verified in Version: Mars (4.5) Build id: N20150424-2000
Closing since this contribution is now verified in Mars.
