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.
Accepted.
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,
Sjur
