Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "PDE/Incubator/XtremeSelfHosting"

< PDE‎ | Incubator
m (PDE UI Incubator SelfHosting moved to PDE/Incubator/XtremeSelfHosting: Updating pde pages to follow new wiki guidelines)
Line 22: Line 22:
 
requirements:
 
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.
 
* "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).
+
* be minimal and simple. No external dependencies. Why? To simplify installation for unexperienced user. There is jmx, ecf, p2, but this all should rather be as simple and flexible as JUnit tests (=click to go).
 
* should be extensible. Why? to support future ideas :D
 
* should be extensible. Why? to support future ideas :D

Revision as of 08:09, 28 April 2008

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. There is jmx, ecf, p2, but this all should rather be as simple and flexible as JUnit tests (=click to go).
  • should be extensible. Why? to support future ideas :D

Back to the top