Thorsten Scherler wrote:
On Sat, 2005-04-23 at 11:38 +0100, Ross Gardler wrote:
Thorsten Scherler wrote:
...
We have to start a howTo about the forrest dispatcher view
implementation
(view/viewHelper plugins) because now we have docu in both plugins but
to start with views you need *both* plugins installed.
Then this is a plugin dependency. There should be no plugin dependencies. They will cause a maintenance nightmare for both Forrest and its users.
Yes, I agree.
...
When the time comes for me to give in then we need to define a way of automatically handling those dependencies, it cannot be left to the user to maintain those dependencies. If they want to use a plugin, they should only need to specify one parameter in their properties file.
Yeah a package like in java: import org.apache.forrest.plugin.internal.view.*
...but what about e.g. the businessHelper plugin? That could not been
included in a package.
That's a problem. See below for a solution ...
If this is the first case that really *has* to have a dependency between plugins then we should look at implementing something like features in Eclipse. Features define collections of plugins that are required to provide a certain feature set. The dependencies between plugins are managed within the feature definition so the user simply defines the feature they want and Eclipse (Forrest for us of course) installs all relevant plugins.
That sounds cool.
It works just fine for Eclipse and they have far more plugins of a more varied nature than we are dealing with. So it *should* work for us too.
However, I'd rather look at the design of the existing plugins to see if it really is necessary to have these dependencies (I have a feeling they will be necessary, but you never know what a new pair of eyes might see). Lets return after the 0.7 release, in the meantime you may as well proceed as you are since these plugins are in the whiteboard.
Ross
