[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jdt-ui-dev] Pre-reqs are not exported
|
>I said "tag", singular. So if I do require *one* of the same pre-reqs, I
need to require the same
>version, so I need to copy that one tag exactly (otherwise I might pick up
a different version).
Looks like we are still disconnected.
In the import element you specify the version of the pre-req plugin that is
required by your plugin. A plugin importing org.eclipse.jdt.ui can have
more specific
version requirements on other plugins than org.eclipse.jdt.ui. Therefore
the tag can be different.
Eclipse will then attempt to satisfy your version requirement.
>I agree class loading is very important. But, If everyone follows this
convention, the
>people at the bottom might end up with 100+ requires statements. I guess
the PDE
>should help out at managing this list.
Since you only have to state the direct dependencies of your plugin this
number
will not increase that drastically. Typically you will only pre-req plugins
that expose API.
>Are there any benchmarks that show startup time comparisons each way?
Failed class look-ups contribute to the start-up time so they
should be minimized (see the recent package prefxi optimization option
offered
by core).
>In my graph, I'm going to continue "promoting" plugins even though they
aren't exported.
>This makes for much easier reading, without any real loss of meaning.
well you loose explicit dependencies so you loose meaning, but I agree that
the
graph will be easier to digest. If it is an interarctive graph than you can
support to show the full dependencies for the selected node.
--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/17/2002 03:38
PM
Please respond to
jdt-ui-dev
I said "tag", singular. So if I do require *one* of the same pre-reqs, I
need to require the same version, so I need to copy that one tag exactly
(otherwise I might pick up a different version).
I agree class loading is very important. But, If everyone follows this
convention, the people at the bottom might end up with 100+ requires
statements. I guess the PDE should help out at managing this list. Are
there any benchmarks that show startup time comparisons each way?
In my graph, I'm going to continue "promoting" plugins even though they
aren't exported. This makes for much easier reading, without any real loss
of meaning. Hopefully I can post a "Map of Eclipse" pretty soon.
-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 06:07 PM Pre-reqs are not exported
Please respond to jdt-ui-dev
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
_______________________________________________
jdt-ui-dev mailing list
jdt-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/jdt-ui-dev
