| Hi All,
Actually, I'm fairly certain that both the UI machinery and the plugin model classes really do pertain only to the meta-tooling, and not to the runtime per se.
More specifically, the part of the runtime that needs to identify and instantiate implementations of the various IMP extension points doesn't use the PDE (as far as I know, or at least, shouldn't need to).
As a result, we should be able to move the code and its dependencies to the meta-tooling plugin project, and leave the runtime PDE-free.
I've submitted a bug for this: Bug 284277. and added those who've participated in this conversation to the CC list (except Laurent, whose e-mail address was unknown to bugzilla). On Jul 21, 2009, at 8:39 AM, Stan Sutton wrote:
Hello Laurent,
Yes, you would think that the PDE would e required only to build the IDE plug-ins, not to run them. Actually, our dependency on the PDE is not large, either in terms of what we require or how we use it, but some of it may be hard to avoid.
The dependency arises in relation to filters and content providers relating to IMP UI support for dialogs. There are two main directions of this dependency. One is a reliance on org.eclipse.pde.internal.ui.elements.DefaultContentProvider as the base class for some of our content providers. This is a trivial class that we can easily replace with one of our own (and we should do so in order to remove a dependency on an "internal" element).
The other part of the dependency is more substantial. This is a dependency on the following:
import org.eclipse.pde.core.plugin.IPluginBase;
import org.eclipse.pde.core.plugin.IPluginModel;
import org.eclipse.pde.core.plugin.IPluginModelBase;
import org.eclipse.pde.internal.core.PDECore;
import org.eclipse.pde.internal.core.PluginModelManager;
The PDE is used to support filters and dialogs that focus on project that contribute to an IDE. The project that contribute to an IDE will contain extensions for language services, and these extensions are registered in the plugin model for the project, so this seems like an architecturally principled approach to the problem. In order to drop our dependence on PDE core, we would probably have to maintain some sort of separate registry of IDE-related projects and/or implement our own ad hoc searches of the plug-in related data. Neither of those is very appealing, but if the cost of the dependency on PDE is high, maybe we should investigate it.
That said, at the moment I'm at a loss as to why we have this functionality in the IDE runtime--that is, why the runtime needs to support dialogs that will focus on IDE-related projects. Can someone please remind me of a use case for this?
Thanks,
Stan
Stan Sutton, Ph. D.
IBM T. J. Watson Research Center
19 Skyline Drive, Hawthorne, NY 10532 USA
telephone: 1-914-784-7316, FAX: 1-914-784-7455, T/L 863
e-mail: suttons@xxxxxxxxxx, Stan Sutton/Watson/IBM@IBMUS
Hello,
I tried to install the X10 plugin on an Eclipse Galileo (Eclipse For Java Developers), but I had a problem : it seems that "IMP Runtime" depends on the PDE (org.eclipse.pde.ui) ?
I thought the PDE was only required to build Eclipse plugins, not to execute them ? Isn't this dependency too "big" ? For example, all classical Eclipse users may well just have installed a raw "Eclipse for Java Developers" or "Eclipse for JavaEE Developers", and not have PDE installed by default ?
Am I guessing something wrong ? Is IMP Runtime intimately coupled with org.eclipse.pde.ui, or is there a chance this dependency will disappear in future releases ?
Thanks in advance,
-- Cheers, - Bob ------------------------------------------------- Robert M. Fuhrer Research Staff Member Programming Technologies Dept. IBM T.J. Watson Research Center
|
