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 <[EMAIL PROTECTED]> 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 future. salu2 > > Best regards, > Sjur > -- Thorsten Scherler thorsten.at.apache.org Open Source Java consulting, training and solutions
