Re: [platform-core-dev] Use of Eclipse plugin framework in pure Java app

[Jeff_McAffer@xxxxxxxxxx]

see <jm> for embedded comments.

"Martin Buechi" <Martin.Buechi@xxxxxxxxxxxxxxx> Sent by: platform-core-dev-admin@xxxxxxxxxxx 03/10/2003 10:31 AM Please respond to platform-core-dev

To:        <platform-core-dev@xxxxxxxxxxx>         cc:                 Subject:        [platform-core-dev] Use of Eclipse plugin framework in pure Java applications

All,

I would like to use the Eclipse plugin framework to deploy pure Java
applications. I work on a set of closely related pure Java applications,
both non-GUI (standalone and MBeans) and Swing-based GUI (with WebStart and
InstallAnywhere installers), that I would like to build as a collection of
components. Since I really like the Eclipse plugin architecture, I would
like to use it as my component architecture. However, I do not want to use
any non-Java Eclipse code, SWT, or the main eclipse.exe.

Has anybody done this? 

<jm> all the time </jm>

Are there any dependencies in the base plugin framework on native platform
code, e.g., org.eclipse.core.resources.*, that would make it impossible to
reuse the implementation of the framework in a pure Java context?

<jm> boot, runtime and xerces are pure Java.  Resources has some natives but they are optional.  Same with update.core.
</jm>

The plugins that I believe to be required for this, namely
org.apache.xerces, org.eclipse.core.runtime, and org.eclipse.core.boot,
contain a number of internal packages. Does anyone know how safe it is to
build on these, given that there are no guarantees that they will be around
in the next version?

<jm> You need the update.core plugin as well.  The Eclipse API guarantees are pretty well detailed on the website.  If you use internal code, there are no guarantees.  You need to define "safe" for yourself and your users.  I can pretty much guarantee that they will change in 2.2.
</jm>

In order to ship an application using WebStart, all content must be in jars.
I understand that putting plugin.properties and plugin.xml into a jar and
breaking the directory structure, e.g., a single directory containing all
jars requires some change to the plugin framework. Are there any fundamental
issues with the current implementation that would make these changes very
difficult?

<jm>I suspect various parts of the infrastructure do not anticipate this structure and so there may be issues.  It would be interesting to know.
</jm>

I am considering a switch to Eclipse/SWT for my IDE-like GUI application in
the future. One feature that would be very interesting to have there would
be the ability to load plugins that I am developing directly into the host
workbench rather than a separate run-time workbench. Are there any plans to
support this or are there fundamental reasons (e.g., unresolvable reloading
issues) that this will never be done?

<jm>The Eclipse plugin registry is static from startup time.  That means you cannot add/remove plugins while Eclipse is running.  This is an workitem for 2.2 and one of the main topics of the Equinox project (http://eclipse.org/equinox)
</jm>

Jeff