[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jdt-ui-dev] Pre-reqs are not exported
|
nice words & nice try <g>
>Do you agree that by not re-exporting plugins, you are requiring
downstream
>plugins to copy *exactly* your <requires> tag?
Not really, a downstream plugin can more precisely state its dependencies.
For example a plugin that requires org.eclipse.jdt.ui
doesn't have to require org.eclipse.jdt.debug.ui plugin.
See org.eclipse.jdt.junit as example, it doesn't
require access to the org.eclipse.compare classes and
hence org.eclipse.compare isn't listed as a pre-req plugin.
By precisely stating your dependencies the class look-up
for your plugin will be more efficient since
less plugin class loaders will have to be consulted when looking-up a
class.
--erich
Randy Hudson
<hudsonr@xxxxxx.c To: jdt-ui-dev@xxxxxxxxxxx
om> cc:
Sent by: Subject: Re: [jdt-ui-dev] Pre-reqs are not exported
jdt-ui-dev-admin@
eclipse.org
12/16/2002 03:42
PM
Please respond to
jdt-ui-dev
I still don't see the harm in exporting. I know all of Eclipse is
consistent, I just decided to ask JDT for the reason because you guys are
so smart :-)
Do you agree that by not re-exporting plugins, you are requiring downstream
plugins to copy *exactly* your <requires> tag? If they don't copy it
exactly, there is a risk of the downstream plugin picking up a different
version of the pre-req than the one JDT-UI picks up, which would cause a
link error (2 different versions of the same class) at runtime. So, if I
have to copy your tag exactly .... ?
Randy
"Erich Gamma"
<Erich_Gamma@xxxxxxx> To:
Sent by: jdt-ui-dev@xxxxxxxxxxx
jdt-ui-dev-admin@xxxxxxxxxxx cc:
jdt-ui-dev@xxxxxxxxxxx
Subject: Re: [jdt-ui-dev]
12/16/2002 04:03 AM Pre-reqs are not exported
Please respond to jdt-ui-dev
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
_______________________________________________
jdt-ui-dev mailing list
jdt-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/jdt-ui-dev
