Community
Participate
Working Groups
Awesome Plug-in Registry view should be able to serve it's delicious content not only for currently running Eclipse instance, but also for e.g. Target runtime configured in Target Platform preference, or even an self-hosted Eclipse.:) This will enable easy extension points, plugins and services browsing and make Eclipse much more transparent!
There should be many ways to connect to an instance btw One option is to use the JMX stuff in the Equinox incubator to connect to an instance...
yea, JMX or ECF stuff as well. so model should make no assumptions about connection layer
Created attachment 121793 [details] first shot First shot at remote contents in Plug-in registry view. With this patch, Plug-in registry connects to Eclipse instance over socket, gets data in xml-like format, keeps responsive to OSGi events. It should be fairly easy to implement other protocols (JMX, ECF) by implementing RegistryBackend interface. Chris: how about a small switch in Eclipse Application launch configuration, that would enable main Eclipse instance to show Plug-in registry contents for self-hosted instance? Sounds good? Other way to use this new feature would be a "Connect" option in registry view, however I'm not sure about exposing it.
Created attachment 125779 [details] patch updated. it's not ready yet for commit. Updated unit tests to be sure that remote and local models are exactly the same. Next step: make some exemplary use of Registry View remote connect.
we can look at using remote osgi in ECF to enable this ;)
FWIW, the work that I've done in this area has/was based upon the ECF remote services API...which, in turn, we are using to implement the osgi RFC 119 spec (remote osgi as zx says). So I guess what I'm saying is that ECF could provide a transport-independent remoting solution either way you wish to do it...either using the ECF remote services API directly or using the new distributed osgi remoting spec (which is, in fact, implemented via the ECF remote services API). Also...since I have already done a fair amount with both the PDE registry view and with showing data from a remote framework, I might be able to help out with some other aspects of things here...for example, there are some changes to the current PDE registry view that I would suggest to support easily replacing a local model with remote model...e.g. to avoid making blocking remote calls with UI thread.
yes Scott, ecf is on our radar. However first approach is to have a solution that will easily fit into SDK, ie. to allow viewing selfhosted Eclipse instances in the view with no extra dependencies. For this purpose we looked at JUnit, how it communicates with child JVMs and chosen plain socket API. At the same time we plan to have an easily extensible mechanism to allow other communication protocols to allow clients with whatever interfaces they have (ECF r-osgi, ECF other protocols, JMX). For that purpose plug-in registry already has (for 3.5) a quite simple factory mechanism that should not limit any protocol impls - it's asynchronious and does not impose other requirements. Wojciech in his GSOC project is going to revise this model and implement some cool protocols, so for sure he'll be happy to hear your suggestions. btw. what work did you do with registry view? We'd love to improve the view to be more consumable :-)
(In reply to comment #7) > yes Scott, ecf is on our radar. However first approach is to have a solution > that will easily fit into SDK, ie. to allow viewing selfhosted Eclipse > instances in the view with no extra dependencies. For this purpose we looked at > JUnit, how it communicates with child JVMs and chosen plain socket API. But, as you know this is completely one-off...that is, no alternative transports can be easily introduced. I understand the desire to have minimal dependencies, but the SDK already has a dependency on part of ECF. > At the same time we plan to have an easily extensible mechanism to allow other > communication protocols to allow clients with whatever interfaces they have > (ECF r-osgi, ECF other protocols, JMX). But such an extensible mechanism/API is approaching ECF's implementation of OSGi remote services... > For that purpose plug-in registry already has (for 3.5) a quite simple factory > mechanism that should not limit any protocol impls - it's asynchronious and > does not impose other requirements. Wojciech in his GSOC project is going to > revise this model and implement some cool protocols, so for sure he'll be happy > to hear your suggestions. > > btw. what work did you do with registry view? We'd love to improve the view to > be more consumable :-) I used the PDE registry view to show a remote framework's bundles/services/extension points...i.e. all the usual contents for the registry view...but from a remote framework. With remote it's desirable to have some notion of refresh (as listeners to changes in a remote framework's changes isn't very decoupled) and so I introduced that...as well as some other things.
Changing Version tag to something more believable.
I added some new information to gsoc project wiki http://wiki.eclipse.org/OSGi_Remote_Management_Tool about Socket communication.
(In reply to comment #10) > I added some new information to gsoc project wiki > http://wiki.eclipse.org/OSGi_Remote_Management_Tool about Socket communication. > I believe it's a mistake to create a new/custom socket protocol for this project...as inevitably people will want or require something that allows substitute transports to be used. Further, with the ECF RFC119 impl and remote services this can/could be addressed in a completely generic way with less work and more inter-project collaboration.
(In reply to comment #11) > > http://wiki.eclipse.org/OSGi_Remote_Management_Tool about Socket communication. > > > > I believe it's a mistake to create a new/custom socket protocol for this > project...as inevitably people will want or require something that allows > substitute transports to be used. Scott, wiki update was mainly to sort out our knowledge on current plug-in registry view internals and the patch here. We were heading for sockets since it's already implemented a lot and was easier to Wojciech to learn. But it's not the only - basically I'd love to have all of them implemented. I've added section with various protocol impls to wiki: http://wiki.eclipse.org/OSGi_Remote_Management_Tool#Possible_protocol_implementations Could you update it, specially sections about ECF? Thanks
Created attachment 137179 [details] updated patch -to compile cleanly in head, -improving unit tests to simplify other protocols impl. As a next step would be good to split sockets impl and tests to two separate patches/bugs.
fyi, I have copied org.eclipse.pde.runtime from HEAD to pde-incubator/osgimonitoring/plugins/org.eclipse.pde.runtime
There're two demos of first implementation of monitoring and managing remote applications using plugin registry view. First shows how to connect with remote applicaiton (or local in other JVM): http://www.szymonnowacki.pl/wojtek/connect.htm The second one shows how to use self-hosting mode in plugin registry view: http://www.szymonnowacki.pl/wojtek/selfhosting.htm
Marked last two attachment obsolete - due to recent Wojciech works in dependent bugs.
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. If you have further information on the current state of the bug, please add it. 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.
This bug was marked as stalebug a while ago. Marking as worksforme. If this report is still relevant for the current release, please reopen and remove the stalebug whiteboard tag.
This bug has been marked as stalebug a while ago without any further interaction. If this report is still relevant for the current release, please reopen and remove the stalebug whiteboard flag.
