Home » Eclipse Projects » Plugin Development Environment (PDE) » Plug in with cyclic dependencies?
| Plug in with cyclic dependencies? [message #26382] |
Mon, 13 October 2008 13:23  |
Eclipse User |
|
|
|
Hello:
I have a graphical editor plugin that relies on another plugin. This other
plugin, is a pure data, API plugin. This all works fine.
Let's call the editor plugin, "A". Let's call the pure Data API plugin,
"B".
Now, I would like plugin "A" to expose a package that may be needed in
plugin "B". Plugin "B" uses a JAXP-compliant XML Parser. When the "B"
plugin is being used with plugin "A" (plugin "B" can be used without
plugin "A"), I would like plugin "A" to expose it's own JAXP-compliant
parser. In effect, it means that it would expose a
META-INF/services/javax.xml.parsers.DocumentBuilderFactory file which
contains the name of a class to invoke. This class would be exposed by A
so that it could be invoked by B.
Unfortunately, I am not able to expose this new class/package.
I am adding to plugin "A" the new package which exports. However, when I
am inside in plugin "B", calls to Class.forName() are failing for the
class exposed by "A".
Is this possible? I would not like to have to require the class exposed in
plugin "A" to be required in "B". Like I said, I would like "B" to work
independently of "A".
Thanks in advance,
Glenn
|
|
| | | |
| Re: Plug in with cyclic dependencies? [message #30855 is a reply to message #30675] |
Mon, 03 November 2008 12:12  |
| Eclipse User |
|
|
|
Chris Aniszczyk wrote:
> Harald Wellmann wrote:
>> Cyclic dependencies are always a bad idea and can be avoided by careful
>> design...
>> It's bad enough when you have to deal with them in third party software,
>> in your own software, you had better try to avoid them.
>>
>> Class.forName() is another bad idea when you are working in an OSGi
>> environment (like Eclipse). Using the OSGi service registry or Eclipse
>> extension points is the recommended way.
>>
>> OSGi can handle dependency cycles, but Eclipse PDE cannot, in most
>> cases. When A depends on B and you want B to use a class in A, you can
>> resort to Eclipse buddy policies to make A visible to B, resulting in a
>> kind of controlled cycle.
> PDE Build can handle binary cycles as of 3.4, PDE UI as of 3.5M3
> http://code9.com/2008/10/28/tip-pde-build-and-binary-cycles/
Thanks for the comments on this thread. To be clear, I don't see an error
message about cycles in the classpath during execution. Perhaps I am
overlooking it.
To explain further, I have a data plugin that reads XML files and returns
an API on top of them. The plugin uses JAXP to determine which XML Parser
to use to parse the XML. I didn't write the JAXP code and it clearly is
not dependent on an Eclipse OSGi runtime environment.
The second plugin I have is a GUI that uses the data API. It uses the data
API to present a visual representation.
This all works perfectly well.
I wanted to further augment the Editor Plugin to expose its own
DocumentBuilderFactory class (which is what the JAXP code looks for). So
that when the Editor Plugin is used with the Data Plugin, it gets a
different XML Parser (one that supports line numbers).
So just for Harald and Chris, would you expect the scenario I describe
above to work or to fail? Should the data plugin find the class exposed by
the Editor plugin? I found through debugging (and calls to Class.forName)
that while inside the data plugin, it could not see any classes in the
Editor plugin.
Is it possible to configure my plugins in a way so that the Editor plugin
could expose classes which can be found by the data plugin (which uses
JAXP and Class.forName)?
Thanks!
Glenn
|
|
| |
| Re: Plug in with cyclic dependencies? [message #584024 is a reply to message #26382] |
Sat, 01 November 2008 14:38 |
| Eclipse User |
|
|
|
Cyclic dependencies are always a bad idea and can be avoided by careful
design...
It's bad enough when you have to deal with them in third party software,
in your own software, you had better try to avoid them.
Class.forName() is another bad idea when you are working in an OSGi
environment (like Eclipse). Using the OSGi service registry or Eclipse
extension points is the recommended way.
OSGi can handle dependency cycles, but Eclipse PDE cannot, in most cases.
When A depends on B and you want B to use a class in A, you can resort to
Eclipse buddy policies to make A visible to B, resulting in a kind of
controlled cycle.
Hope that helps,
Harald
|
|
|
| Re: Plug in with cyclic dependencies? [message #584066 is a reply to message #30605] |
Sat, 01 November 2008 16:46 |
| Eclipse User |
|
|
|
Harald Wellmann wrote:
> Cyclic dependencies are always a bad idea and can be avoided by careful
> design...
> It's bad enough when you have to deal with them in third party software,
> in your own software, you had better try to avoid them.
>
> Class.forName() is another bad idea when you are working in an OSGi
> environment (like Eclipse). Using the OSGi service registry or Eclipse
> extension points is the recommended way.
>
> OSGi can handle dependency cycles, but Eclipse PDE cannot, in most
> cases. When A depends on B and you want B to use a class in A, you can
> resort to Eclipse buddy policies to make A visible to B, resulting in a
> kind of controlled cycle.
PDE Build can handle binary cycles as of 3.4, PDE UI as of 3.5M3
http://code9.com/2008/10/28/tip-pde-build-and-binary-cycles/
Cheers,
~ Chris
|
|
|
| Re: Plug in with cyclic dependencies? [message #584148 is a reply to message #30675] |
Mon, 03 November 2008 12:12 |
| Eclipse User |
|
|
|
Chris Aniszczyk wrote:
> Harald Wellmann wrote:
>> Cyclic dependencies are always a bad idea and can be avoided by careful
>> design...
>> It's bad enough when you have to deal with them in third party software,
>> in your own software, you had better try to avoid them.
>>
>> Class.forName() is another bad idea when you are working in an OSGi
>> environment (like Eclipse). Using the OSGi service registry or Eclipse
>> extension points is the recommended way.
>>
>> OSGi can handle dependency cycles, but Eclipse PDE cannot, in most
>> cases. When A depends on B and you want B to use a class in A, you can
>> resort to Eclipse buddy policies to make A visible to B, resulting in a
>> kind of controlled cycle.
> PDE Build can handle binary cycles as of 3.4, PDE UI as of 3.5M3
> http://code9.com/2008/10/28/tip-pde-build-and-binary-cycles/
Thanks for the comments on this thread. To be clear, I don't see an error
message about cycles in the classpath during execution. Perhaps I am
overlooking it.
To explain further, I have a data plugin that reads XML files and returns
an API on top of them. The plugin uses JAXP to determine which XML Parser
to use to parse the XML. I didn't write the JAXP code and it clearly is
not dependent on an Eclipse OSGi runtime environment.
The second plugin I have is a GUI that uses the data API. It uses the data
API to present a visual representation.
This all works perfectly well.
I wanted to further augment the Editor Plugin to expose its own
DocumentBuilderFactory class (which is what the JAXP code looks for). So
that when the Editor Plugin is used with the Data Plugin, it gets a
different XML Parser (one that supports line numbers).
So just for Harald and Chris, would you expect the scenario I describe
above to work or to fail? Should the data plugin find the class exposed by
the Editor plugin? I found through debugging (and calls to Class.forName)
that while inside the data plugin, it could not see any classes in the
Editor plugin.
Is it possible to configure my plugins in a way so that the Editor plugin
could expose classes which can be found by the data plugin (which uses
JAXP and Class.forName)?
Thanks!
Glenn
|
|
|
Goto Forum:
Current Time: Fri Oct 31 12:45:08 EDT 2025
Powered by FUDForum. Page generated in 0.23962 seconds |
Home