[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jdt-ui-dev] Pre-reqs are not exported
|
The convention is that dependent plug-in classes are not reexported to
clients. This makes the plugin dependencies explicit. Jdt-ui should not be
different from other plugins in the platform.
Notice that most uses of exports are the consequence of a plugin split (see
org.eclipse.ui as an example). In these cases exporting was used to not
break existing clients of the splitted plug-in.
--erich
Randy Hudson
<hudsonr@xxxxxx.c To: jdt-ui-dev@xxxxxxxxxxx
om> cc:
Sent by: Subject: [jdt-ui-dev] Pre-reqs are not exported
jdt-ui-dev-admin@
eclipse.org
12/16/2002 01:56
AM
Please respond to
jdt-ui-dev
jdt.ui requires several plugins, but the plugins are not exported. What is
the reasoning behind not exporting these plugins to other plugins that
pre-req jdt.ui?
Much of the public API in jdt-ui requires that these other plugins be
present *AND* that they be exactly the same version. For example,
IClassPathEntry returns an IPath, which is from org.eclipse.core.runtime.
Why make other plugins prereq both jdt.ui and core.runtime? The only reason
I can think of is to optimize for the plugin class loader.
The reason I am asking is that I am writing a graphical view of the plugin
registry. Each plugin is represented as a box, and lines are used to show
the plugins required by each plugin. Plugins are positioned vertically (in
ranks) such that all required plugins appear above a given plugin. Long
lines make the diagram hard to read, so I added code to reduce redundant
imports. Then I found out that there weren't any redundant imports, so I
cheated. Without changes, a diagram of all Eclipse plugins requires about
300 lines. If I cheat and "export" all requires statements, the same
diagram only needs about 85 lines.
Randy Hudson