Home » Eclipse Projects » Eclipse Platform » How to use AST/JDT and avoid ClassLoader?
| How to use AST/JDT and avoid ClassLoader? [message #31720] |
Wed, 14 May 2003 11:16  |
Eclipse User |
|
|
|
We are developing Eclipse plugins which must interact with other code
running outside of Eclipse. The current thought was to package the
necessary interface code in jars, and then include those jars in the
<required> section of the plugin.xml. Simple enough.
However, as we move forward in this project, we will want a client running
Eclipse to be able to interact with multiple environments, each of which
may have slightly different implementations of the interface code. So we
now have a runtime problem: which implementation should be used when?
The solution which immediately comes to mind essentially boils down to
instantiating/maintaining a new ClassLoader for each environment, and
maitaining internal logic in each plugin which knows which ClassLoader to
use when. But aside from the fact that this approach seems incredibly
messy and difficult to maintain, I have also found a warning against doing
such a thing at eclipse.swiki.net. This same FAQ response also suggests
that if I instead go the 'JDT and AST route', then people will happily
help me to solve my problem.
I have limited knowledge of the AST framework, but only as a document
parsing tool. I have briefly examined the source for the Eclipse
incremental compiler (since it uses an appropriate user-specified
classpath defined per plugin project), but it is far from clear to me that
I can easily use it or its framework to solve my problem.
So. Any suggestions as to the correct approach? Pointers to existing
documentation?
--dave
|
|
|
| Re: How to use AST/JDT and avoid ClassLoader? [message #32136 is a reply to message #31720] |
Wed, 14 May 2003 13:12  |
| Eclipse User |
|
|
|
Originally posted by: jed_anderson.us.ibm.com
David,
I don't see how the AST will help you. The AST is good for determining
what source looks like. It won't help much (if any) at runtime, when
you need to match implementations of interfaces.
Could you elaborate on your multiple environments? Perhaps this is a
matter of abstracting your interfaces to guard against future/past changes.
jkca
David Bailey wrote:
> We are developing Eclipse plugins which must interact with other code
> running outside of Eclipse. The current thought was to package the
> necessary interface code in jars, and then include those jars in the
> <required> section of the plugin.xml. Simple enough.
>
> However, as we move forward in this project, we will want a client running
> Eclipse to be able to interact with multiple environments, each of which
> may have slightly different implementations of the interface code. So we
> now have a runtime problem: which implementation should be used when?
>
> The solution which immediately comes to mind essentially boils down to
> instantiating/maintaining a new ClassLoader for each environment, and
> maitaining internal logic in each plugin which knows which ClassLoader to
> use when. But aside from the fact that this approach seems incredibly
> messy and difficult to maintain, I have also found a warning against doing
> such a thing at eclipse.swiki.net. This same FAQ response also suggests
> that if I instead go the 'JDT and AST route', then people will happily
> help me to solve my problem.
>
> I have limited knowledge of the AST framework, but only as a document
> parsing tool. I have briefly examined the source for the Eclipse
> incremental compiler (since it uses an appropriate user-specified
> classpath defined per plugin project), but it is far from clear to me that
> I can easily use it or its framework to solve my problem.
>
> So. Any suggestions as to the correct approach? Pointers to existing
> documentation?
>
> --dave
>
|
|
|
| Re: How to use AST/JDT and avoid ClassLoader? [message #32379 is a reply to message #32136] |
Wed, 14 May 2003 14:55 |
| Eclipse User |
|
|
|
I think it\'s more than a matter of abstracting interfaces. Suppose I
have two environments, ENV1 and ENV2. Each environment may support one or
more filesystem entities which I wish to realize as Eclipse projects.
The goal is to set things up so that an end user can load Eclipse + our
plugins on their box, and then define Eclipse projects which correspond to
the filesystem entities in one or both environments.
The plugins we are writing will need to use code provided by each of ENV1
and ENV2, as appropriate. For example, each environment will contain a
jar file \'foo.jar\' which is used by a Java runtime on the environment
machine, as well as by our Eclipse plugins.
What it boils down to, it seems to me, is that when a user performs some
action on one of their projects, the logic for the underlying plugin must:
- Determine whether the project \'belongs\' to ENV1 or ENV2,
- Execute the necessary code in the foo.jar belonging to the correct
environment.
Taking the time to define and adhere to well-known interfaces for the
implementations in foo.jar is a wonderful idea, and necessary no matter
what other actions we take. But the problem I\'m chasing is: how does the
plugin know which logic to execute at runtime?
As I said in my original post, a possible but very ugly solution is to
maintain a HashMap somewhere mapping IProjects to ClassLoaders, and
performing some voodoo to insure that the proper ClassLoader is used in
response to any end user action.
However, it\'s also true that the JDT and PDE must do something very
similar to what I\'m attempting with the incremental compile mechanism.
For a plugin project (say), the user defines the Build Path differently
for each project, and the builder knows the right classpath to use when
it\'s invoked --- even if I\'m using different versions of the same jar
file for two different plugin projects. So I\'m hoping that there might
be a slicker, more time-tested approach to achieve what I\'m shooting for.
--dave
Jed Anderson wrote:
> David,
> I don\'t see how the AST will help you. The AST is good for determining
> what source looks like. It won\'t help much (if any) at runtime, when
> you need to match implementations of interfaces.
> Could you elaborate on your multiple environments? Perhaps this is a
> matter of abstracting your interfaces to guard against future/past changes.
> jkca
> David Bailey wrote:
> > We are developing Eclipse plugins which must interact with other code
> > running outside of Eclipse. The current thought was to package the
> > necessary interface code in jars, and then include those jars in the
> > <required> section of the plugin.xml. Simple enough.
> >
> > However, as we move forward in this project, we will want a client running
> > Eclipse to be able to interact with multiple environments, each of which
> > may have slightly different implementations of the interface code. So we
> > now have a runtime problem: which implementation should be used when?
> >
> > The solution which immediately comes to mind essentially boils down to
> > instantiating/maintaining a new ClassLoader for each environment, and
> > maitaining internal logic in each plugin which knows which ClassLoader to
> > use when. But aside from the fact that this approach seems incredibly
> > messy and difficult to maintain, I have also found a warning against doing
> > such a thing at eclipse.swiki.net. This same FAQ response also suggests
> > that if I instead go the \'JDT and AST route\', then people will happily
> > help me to solve my problem.
> >
> > I have limited knowledge of the AST framework, but only as a document
> > parsing tool. I have briefly examined the source for the Eclipse
> > incremental compiler (since it uses an appropriate user-specified
> > classpath defined per plugin project), but it is far from clear to me that
> > I can easily use it or its framework to solve my problem.
> >
> > So. Any suggestions as to the correct approach? Pointers to existing
> > documentation?
> >
> > --dave
> >
|
|
|
Goto Forum:
Current Time: Mon Jun 16 01:02:07 EDT 2025
Powered by FUDForum. Page generated in 0.03503 seconds |
Home