forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <>
Subject Re: output.inputModule Plugin dependency (was: Plugin dependencies)
Date Mon, 01 Sep 2008 11:19:23 GMT
On Mon, 2008-09-01 at 13:40 +0300, Sjur Moshagen wrote:
> Ross Gardler wrote:
> > Thorsten Scherler wrote:
> >>...
> >>> Either we accept this fact, but leave the functionality as a   
> >>> (required) plugin, or we move the functionality of the   
> >>> o.a.f.p.output.inputModule into the Forrest core. Then we would  
> >>> have  no dependency anymore, since core is allways there.
> >> The problem I have to drop this functionality as plugin and move it
> >> directly into the core is that  cannot build it anymore by itself and
> >> use the resulting jar. However I agree that this plugin represents  
> >> core
> >> functionality (that is why I called it infrastructure code).
> >
> > I don't get it? Why is this a problem? Forrest needs the code to go  
> > into core. If it builds as a plugin it will build as part of the core.

Yeah! Best solution would be to define it as core plugin and build it
when forrest get build. 

> >
> > If you mean that you, as an individual, need to use the code  
> > independently of Forrest then I don't think that is a problem for us  
> > as a community.

No that is not the problem. 

> >
> > On the other hand, if you are saying that this code is useful to  
> > many other projects as a standalone peice of code then it should be  
> > a project (or more likely a Cocoon block) in its own right. Forrest  
> > can then include the block (or jar) from there.

Actually many of our plugins can be used in cocoon directly. Having the
code in a plugin allows everyone to go the "ant local-deploy" route and
use the jar. 

> >
> > I'm +1 for the code going into core if it resolves the plugin  
> > dependencies in dispatcher and the new PDF work quickly and easily.
> >
> > One day we will need a plugin dependency mechanism (as we always  
> > say), but I don't think this is it.
> Thorsten has not commented upon this, which means that his problems  
> with the plugin code going into core is still unclarified.
> I agree with Ross that the easiest solution would be to just move the  
> code to core.

Yeah, it is just one generator. It is fine with me to move this class
directly to the core, best solution IMO is to leave it in the plugin
structure but build it by default with the core. Meaning we can drop the
dependency in the required plugin section. 

However ATM I cannot look into the needed changes for that. I am fine
with either move the class directly to the core or generate the jar once
and add it to the lib dir. In both cases we need the one match that the
plugin offers in the main sitemap.

Thorsten Scherler                       
Open Source Java                      consulting, training and solutions

View raw message