Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Plugin Development Environment (PDE) » Plug in with cyclic dependencies?
Plug in with cyclic dependencies? [message #26382] Mon, 13 October 2008 17:23 Go to next message
Glenn Boysko is currently offline Glenn BoyskoFriend
Messages: 6
Registered: July 2009
Junior Member
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 #27225 is a reply to message #26382] Fri, 17 October 2008 18:33 Go to previous messageGo to next message
Glenn Boysko is currently offline Glenn BoyskoFriend
Messages: 6
Registered: July 2009
Junior Member
Is this the right newsgroup for this type of question? Plugin development?
Re: Plug in with cyclic dependencies? [message #30605 is a reply to message #26382] Sat, 01 November 2008 18:38 Go to previous messageGo to next message
Harald Wellmann is currently offline Harald WellmannFriend
Messages: 34
Registered: July 2009
Location: Hamburg, Germany
Member
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 #30675 is a reply to message #30605] Sat, 01 November 2008 20:46 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: zx.code9.com

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 #30855 is a reply to message #30675] Mon, 03 November 2008 17:12 Go to previous message
Glenn Boysko is currently offline Glenn BoyskoFriend
Messages: 6
Registered: July 2009
Junior Member
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 #583007 is a reply to message #26382] Fri, 17 October 2008 18:33 Go to previous message
Glenn Boysko is currently offline Glenn BoyskoFriend
Messages: 6
Registered: July 2009
Junior Member
Is this the right newsgroup for this type of question? Plugin development?
Re: Plug in with cyclic dependencies? [message #584024 is a reply to message #26382] Sat, 01 November 2008 18:38 Go to previous message
Harald Wellmann is currently offline Harald WellmannFriend
Messages: 34
Registered: July 2009
Location: Hamburg, Germany
Member
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 20:46 Go to previous message
Chris Aniszczyk is currently offline Chris AniszczykFriend
Messages: 674
Registered: July 2009
Senior Member
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 17:12 Go to previous message
Glenn Boysko is currently offline Glenn BoyskoFriend
Messages: 6
Registered: July 2009
Junior Member
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
Previous Topic:Where to specify allowBinaryCycles=true?
Next Topic:Problem with implementation the swt directorydialog as a plugin
Goto Forum:
  


Current Time: Thu Mar 28 16:23:05 GMT 2024

Powered by FUDForum. Page generated in 0.01998 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top