Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
PDE/Incubator/XtremeSelfHosting
< PDE | Incubator
Revision as of 13:50, 14 April 2008 by Zx.us.ibm.com (Talk | contribs) (PDE UI Incubator SelfHosting moved to PDE/Incubator/XtremeSelfHosting: Updating pde pages to follow new wiki guidelines)
Note This is W o R k I n P r O g R e S s S
It all started with "install bundles in running Eclipse", but from others comments (e.g. in bug198189), seems problem is more general.
Aim: Better integrate host-instance cooperation in self-hosting Benefits: Developer will have a better control over and insight into his running Eclipse/Equinox/OSGi instance
specifically with this new work developer will be able to:
- remotely observe and manage instance bundles
- install bundles in target instance from host workspace
- follow instance logs in his work environment (aka host)
- inspect services (the same as in bug Bug 217738, but remote)
- seamless integration with PDE launch. So user will launch his Eclipse Application as usual, but this time views in his host Eclipse will be monitoring the target instance. Next step into better introspection :D
expected products:
- new bundle (something like org.eclipse.pde.runtime.probe), that will be installed on monitored instance.
- serious modifications to org.eclipse.pde.ui.runtime (enable remote connection)
- small modifications to org.eclipse.ui.views.log
- small modifications to org.eclipse.pde.ui
requirements:
- "probe" should work with any targets (Eclipse >=3.2/Equinox/OSGi). Why? Lot of my collegues still use and support 3.2 based tools.
- be minimal and simple. No external dependencies. Why? To simplify installation for unexperienced user. As you pointed some time ago - there is jmx, ecf, p2, but this all should rather be as simple and flexible as JUnit tests (they're sent over tcp).
- should be extensible. Why? to support future ideas :D