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 <[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.
Correct.
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
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.
Ross
