forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <>
Subject Re: Plugin dependencies (Was: pdf plugin config locations)
Date Fri, 22 Aug 2008 07:00:51 GMT
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.
> The dispatcher plugin is already dependent upon the  
> o.a.f.p.output.inputModule, although dispatcher is in the whiteboard.  
> Would this dependency stop it from being released from whiteboard?

No, IMO no, but as Tim pointed correctly out there have been a lot of
discussion around plugin dependencies. 

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

> >>>> How should it/can it be formalised?
> >>>
> >>> Not sure what you mean?
> >>
> >> Whether it is possible to formalize the dependency, such that if  
> >> the pdf
> >> plugin is specified, forrest will automatically also include other  
> >> plugins
> >> the pdf plugin is dependent on. But if I remember past discussions
> >> correctly, this isn't possible yet.
> >
> > It is not and I believe this is the issue.  There's no way for plugin
> > A to say I require version N of plugin B, for example.  Complicating
> > matters, if you have two plugins with dependencies on differing
> > versions of the same plugin, strange things are likely to happen.  I
> > believe it's this complication (the devils in the details) that has
> > kept us from having such a capability for so long.
> Understandable, and I have no real solution to this.

A possible solution would be to use a dependency system like Ivy but the
first integration steps have been stopped.

> > I'm not saying we shouldn't change the status quo but I think it's
> > worthy of some discussion first.  Having said that, you seem to be on
> > a good roll and I don't want long discussion to slow you down either:)
> :D
> 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


> Best regards,
> Sjur
Thorsten Scherler                       
Open Source Java                      consulting, training and solutions

View raw message