forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: Plugin dependencies (Was: pdf plugin config locations)
Date Fri, 22 Aug 2008 21:21:44 GMT
Thorsten Scherler wrote:
> On Fri, 2008-08-22 at 08:26 +0300, Sjur Moshagen wrote:
>> Den 21. aug. 2008 kl. 13.09 skrev Tim Williams:
>>> On Thu, Aug 21, 2008 at 4:01 AM, Sjur Moshagen <> wrote:
>>>> Den 21. aug. 2008 kl. 10.06 skrev Thorsten Scherler:
>>>>>> Is this dependency acceptable?
>>>>> IMO yes, since the plugin is very small and thought a infrastructure
>>>>> code. Like you describe the alternative to implement it in the  
>>>>> sitemap
>>>>> is cumbersome to maintain.
>>>> Are there other opinions? Do we need a vote before we tie ourselves  
>>>> to this
>>>> dependency?
>>> In the past I think we've consistently decided against having
>>> dependent plugins until we have a facility built in that will manage
>>> them properly.  I reckon this is due to version incompatibility
>>> problems between plugins, etc.


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


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

>> I have now done the basic work for skins-based sites, but I will have  
>> to do the same for dispatcher-based sites as well (otherwise the pdf  
>> plugin would be broken in dispatcher), which means there is still some  
>> time to discuss this before I commit. If we decide against the  
>> dependency, my changes will still work, but forwarding the user  
>> settings to the xsl stylesheet will be much more clumsier and hard to  
>> maintain.
> IMO the dependency to the inputModule is totally acceptable, more since
> I doubt that there will be multiple version of this plugin in the
> future.

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.


View raw message