| Best Practices: Re-export Plugin Dependencies? [message #301802] |
Wed, 05 April 2006 17: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 07:43  |
| Eclipse User |
|
|
|
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 #301837 is a reply to message #301819] |
Thu, 06 April 2006 10: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 #301840 is a reply to message #301819] |
Thu, 06 April 2006 10: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.02877 seconds
Home