| Best Practices: Re-export Plugin Dependencies? [message #301802] |
Wed, 05 April 2006 21:28  |
Eclipse User |
|
|
|
Originally posted by: mark_melvin.amis.com
Hi All,
I was wondering what the best practices for re-exporting plugin
dependencies would be. I have been house-cleaning and found that one of
my core plugins re-exported a whole pile of org.eclipse.* dependencies.
I thought this was a bad thing so I decided to remove the re-export,
and it broke tons of other plugins. After a mind-numbing afternoon of
fixing these I am starting to wonder which is better?
Is it recommended to avoid re-exporting dependencies in general, or is
it recommended to do it? On the downside it kind of hides the
dependency tree, creating *magical and invisible* links between
plug-ins, but on the other hand it avoids you re-declaring dependencies
- which is tedious.
Is there anything I am missing here?
Thanks,
Mark.
|
|
|
| Re: Best Practices: Re-export Plugin Dependencies? [message #301819 is a reply to message #301802] |
Thu, 06 April 2006 11:43  |
|
you say tomAto, you say tomato :-)
To be honest, I wouldn't say one is a best practice over the other
(although I have a preference).
Option 1: If you use it, depend on it directly. By specifying your
dependencies, you also know where to look if an API contract changes.
This is the preferred method in large projects. The downside is if you
change a lower level, you have to update all the dependencies.
Option 2: You set up your core plugin to re-export stuff. Basically
you're saying "I offer a service, come only to me". On the plus side
you can protect clients against lower level changes. But all clients
will then look to you for ALL API contracts, both yours and re-exported,
and this can be a project maintenance nightmare.
I prefer Option 1. If your client code uses it, depend on it. In
essense, you should know what your client code is doing and understand
what the client code needs to function.
When this is the case from day one, then there's no (rather painful)
large changes like you had to do, it's always small incremental changes
and the client code is aware of what it needs to function.
Later,
PW
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions
|
|
|
| Re: Best Practices: Re-export Plugin Dependencies? [message #301828 is a reply to message #301802] |
Thu, 06 April 2006 13:15 |
| Eclipse User |
|
|
|
Originally posted by: eclipse.bettsockentraeger.de
I'd definitly go the road only reexport what your plugin contributes and
let other plugins import the dependecies for needed imports.
This will lead to cleaner seperation of plugins and put the burden of
managing changes on the dependent plugins make maintainance a whole lot
easier.
This will make it also easier to find errors due to dependency issues.
Just my 2cts :)
Stefan
Mark Melvin wrote:
> Hi All,
>
> I was wondering what the best practices for re-exporting plugin
> dependencies would be. I have been house-cleaning and found that one of
> my core plugins re-exported a whole pile of org.eclipse.* dependencies.
> I thought this was a bad thing so I decided to remove the re-export,
> and it broke tons of other plugins. After a mind-numbing afternoon of
> fixing these I am starting to wonder which is better?
> Is it recommended to avoid re-exporting dependencies in general, or is
> it recommended to do it? On the downside it kind of hides the
> dependency tree, creating *magical and invisible* links between
> plug-ins, but on the other hand it avoids you re-declaring dependencies
> - which is tedious.
>
> Is there anything I am missing here?
>
> Thanks,
> Mark.
|
|
|
| Re: Best Practices: Re-export Plugin Dependencies? [message #301837 is a reply to message #301819] |
Thu, 06 April 2006 14:18 |
| Eclipse User |
|
|
|
Originally posted by: mark_melvin.amis.com
Thanks for the reply, Paul. I tend to agree, and don't know what I was
thinking a couple years ago when I started. ;-) Option 1 just "feels
better" so I think my refactoring will be worth it.
Thanks again,
Mark.
Paul Webster wrote:
> you say tomAto, you say tomato :-)
>
> To be honest, I wouldn't say one is a best practice over the other
> (although I have a preference).
>
> Option 1: If you use it, depend on it directly. By specifying your
> dependencies, you also know where to look if an API contract changes.
> This is the preferred method in large projects. The downside is if you
> change a lower level, you have to update all the dependencies.
>
> Option 2: You set up your core plugin to re-export stuff. Basically
> you're saying "I offer a service, come only to me". On the plus side
> you can protect clients against lower level changes. But all clients
> will then look to you for ALL API contracts, both yours and re-exported,
> and this can be a project maintenance nightmare.
>
> I prefer Option 1. If your client code uses it, depend on it. In
> essense, you should know what your client code is doing and understand
> what the client code needs to function.
>
> When this is the case from day one, then there's no (rather painful)
> large changes like you had to do, it's always small incremental changes
> and the client code is aware of what it needs to function.
>
> Later,
> PW
|
|
|
| Re: Best Practices: Re-export Plugin Dependencies? [message #301838 is a reply to message #301828] |
Thu, 06 April 2006 14:23 |
| Eclipse User |
|
|
|
Originally posted by: mark_melvin.amis.com
I think I agree. Thanks for the pocket-change. It is appreciated!
Mark.
Stefan Langer wrote:
> I'd definitly go the road only reexport what your plugin contributes and
> let other plugins import the dependecies for needed imports.
> This will lead to cleaner seperation of plugins and put the burden of
> managing changes on the dependent plugins make maintainance a whole lot
> easier.
> This will make it also easier to find errors due to dependency issues.
>
> Just my 2cts :)
>
> Stefan
>
> Mark Melvin wrote:
>> Hi All,
>>
>> I was wondering what the best practices for re-exporting plugin
>> dependencies would be. I have been house-cleaning and found that one
>> of my core plugins re-exported a whole pile of org.eclipse.*
>> dependencies. I thought this was a bad thing so I decided to remove
>> the re-export, and it broke tons of other plugins. After a
>> mind-numbing afternoon of fixing these I am starting to wonder which
>> is better?
>> Is it recommended to avoid re-exporting dependencies in general, or is
>> it recommended to do it? On the downside it kind of hides the
>> dependency tree, creating *magical and invisible* links between
>> plug-ins, but on the other hand it avoids you re-declaring
>> dependencies - which is tedious.
>>
>> Is there anything I am missing here?
>>
>> Thanks,
>> Mark.
|
|
|
| Re: Best Practices: Re-export Plugin Dependencies? [message #301840 is a reply to message #301819] |
Thu, 06 April 2006 14:42 |
| Eclipse User |
|
|
|
Originally posted by: richkulp.us.NO_SPAM.ibm.com
The only problem with option 1 is that if the base plugin requires a new
API breaking version of the reexported plugin then it becomes confusing
for the second plugin. It doesn't know it needs a new version of the
plugin. Of course the base plugin needs to also change its version to be
breaking API version so that the downstream plugin knows there is a
required change somewhere.
If it did option 2 the base plugin needs to just declare a breaking API
version. Then the second plugin would not be resolved until it is
recompiled with the new base plugin.
Either way it can be a nightmare. :-)
--
Thanks,
Rich Kulp
|
|
|
Powered by
FUDForum. Page generated in 0.03759 seconds
] 
Search
Help
Register
Login
Home
