forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sjur Moshagen <>
Subject Re: output.inputModule Plugin dependency (was: Plugin dependencies)
Date Mon, 01 Sep 2008 10:40:04 GMT
Ross Gardler wrote:
> Thorsten Scherler wrote:
>> On Fri, 2008-08-22 at 08:26 +0300, Sjur Moshagen wrote:
>>> What it looks like to me, is that the o.a.f.p.output.inputModule  
>>> is  turning into core functionality of Forrest (and necessarily so  
>>> if we  do away with skinconfig), cf the comments from Thorsten  
>>> earlier in  this thread.
>> IMO this observation is correct.
> +1

I have seen no other comments on this, thus I take it that we agree  
that this is core functionality. -> end of this point of the discussion.

>>> 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.
> 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.
> 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.
> 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.

> We accepted plugin dependencies for dispatcher whilst it was in  
> whiteboard, however, we have always rejected them in the past for  
> very good reasons. Those reasons are in the archives and are not  
> limited to version issues.
> Unless I've misunderstood the problem with moving the inpuModule  
> code into either core or a cocoon block then I'm -1 on using a  
> solution that contradicts a previous design decision.


> However, whilst this -1 is resolved I thin it is clear that Sjur  
> should proceed with the work using the inputModule - we'll agree a  
> way to get it into the next release in parallel with that work.

Ok, thanks, I'll try to continue this week:) (last week was too busy  
for me)

Best regards,

View raw message