Re: svn commit: r164464 - in /forrest/trunk: main/targets/plugins.xml main/targets/validate.xml main/webapp/resources/schema/catalog.xcat plugins/build.xml

2005-04-24 Thread Ross Gardler
[EMAIL PROTECTED] wrote:
Author: crossley
Date: Sun Apr 24 04:06:19 2005
New Revision: 164464
URL: http://svn.apache.org/viewcvs?rev=164464view=rev
Log:
Added ability to have DTDs in plugins.
Issue: FOR-486
Cool, thanks David.
Ross


Re: Plugin dependencies (Re: view/viewHelper: contract placement)

2005-04-24 Thread Thorsten Scherler
Cheers for starting this, Ross. I was up to do it. :)

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. 

I thought about bundling plugins like a package (view):
org.apache.forrest.plugin.internal.view
org.apache.forrest.plugin.internal.view.viewHelper

Then the user only have to define a package. All dependencies have to
been resolved within a package by the included plugins.  

 We need to find a way of removing this dependency. I'm still not going 
 to get my teeth into this plugin until after 0.7 is out, so I have no 
 suggestions as to how to remove this particular dependency yet. (some 
 docs will certainly help in understanding this).
 

Could the above work? ...and how do I have to implement it?

 Of course, at some point I know I'll have to give up on this point, but 
 as I have said before, I'll hold out as long as I can.
 

:)

 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. 

 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.

 Ross

salu2
-- 
thorsten

Together we stand, divided we fall! 
Hey you (Pink Floyd)