[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re[2]: [jdt-ui-dev] Pre-reqs are not exported
|
Very cool. *grin* Next step: show which way the dependency goes. ;-)
> Here is a graph of the plugins I have loaded in my workspace (jdt.ui, GEF,
> and dependencies). It is not all of Eclipse. The layout algorithm isn't
> finished yet, but it does a pretty good job so far.
> There are two versions attachments. In one graph, all required plugins
> are "exported", reducing the number of edges. In the second attachment,
> *every* requirement is shown.
> (Sorry if this post is a duplicate. I think my first attempt was rejected
> due to address problems).
> "Erich Gamma" <Erich_Gamma@xxxxxxx>
> Sent by: jdt-ui-dev-admin@xxxxxxxxxxx
> 12/18/2002 08:23 AM
> Please respond to jdt-ui-dev
> To: jdt-ui-dev@xxxxxxxxxxx
> cc: jdt-ui-dev@xxxxxxxxxxx
> Subject: 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
> _______________________________________________
> jdt-ui-dev mailing list
> jdt-ui-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/jdt-ui-dev
--
"The very existence of flamethrowers proves that some time,
somewhere, someone said to themselves, 'You know, I want to set
those people over there on fire, but I'm just not close enough
to get the job done.'"
- George Carlin
Insurance-Engine.
(613) 234-2426x226
