Any luck with this? Would love to hear if you found a solution.
I've got a solution that works for plugins that only need to add things to the xconf files, but it further breaks the copyless behaviour. I am still doing testing with it and need to tidy it up a little. Once I have done this I'll see what the community think about commiting it.
Even with this solution there is still a little masasging of Cocoon Blocks needed to make things work properly. Furthermore, I've found that there is lots of baggage brought along by doing a direct conversion of Cocoon Blocks. For example, the Databases block includes all the stuff needed for four different ways of accessing a database. I believe each Forrest plugin should only provide one of these methods (although there could be multiple plugins, one for each technique).
There is a further problem with blocks that require changes to web.xml. I've not yet discovered a way of including content in there (not looked too hard yet though).
Ross
-----Original Message-----
From: Ross Gardler [mailto:[EMAIL PROTECTED] Sent: 17 January 2005 14:56
To: dev@forrest.apache.org
Subject: Re: Using cocoon blocks as plugins
Reinhard Poetz wrote:
Ross Gardler wrote:
The location of cocoon.xconf can be configured in web.xml. HTH
But web.xml is itself in a fixed location too (i.e. main/webapp/WEB-INF. What I am trying to do is find a solution that will not break the copyless behaviour.
:-(
Sylvain added an include feature for cocoon.xconf some weeks ago. There you could point to whereever you want:
http://svn.apache.org/repos/asf/cocoon/trunk/src/webapp/WEB-INF/cocoon.xconf
He he, now we are going round in circles - that's exactly why I have hit this problem. Here's some background:
I have upgraded Forrest to use the new Cocoon because I want to be able to create Forrest Plugins out of Cocoon Blocks and this cocoon.xconf import is just what we need. I now have an Ant script that will import a Cocoon block as a plugin. However, plugins in Forrest are dynamically configured each time a site is built/run. This means that the cocoon.xconf, with the relevant imports is built at runtime.
The projects cocoon.xconf is currently built in the PROJECT_HOME/build/tmp It has to be in there (or at least some user writable location) because the user may not have write access to the Forrest install directory.
I was hoping there would be a command line switch that would enable me to pass an alternative location of cocoon.xconf to the servlet. I think I should move this query over to the Cocoon list, I'll do that tomorrow.
Ross
Ross
-- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.7.2 - Release Date: 21/01/2005
