You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Ross Gardler <rg...@apache.org> on 2005/01/15 05:45:19 UTC
Using cocoon blocks as plugins
I almost have the plugin build file automatically creating plugins from
Cocoon blocks, but I have hit a problem that I could do with some input
on and since I am going to bed now I'm hoping someone will know the
answer and save me some research when I start at this again.
What I need to do is tell cocoon to run with an xconf file that is not
in the main/webapp/WEB-INF directory. This is because the xconf needs to
be dynamically created to allow plugins that require entries in the
xconf file (currently the file is created in project-tmp.
I note that the "site" target uses main/webapp/WEB-INF/cli.xconf, which
in turn references main/webapp/WEB-INF/cocoon.xconf. The "run" target
does not specify a config file since it picks it up from the webapp.
So how can I change the location of the cocoon.xconf file from within
the "site" and "run" targets (not necessary in "war" since we can simply
copy the files in to the WAR).
Ross
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.6.11 - Release Date: 12/01/2005
Re: Using cocoon blocks as plugins
Posted by Ross Gardler <rg...@apache.org>.
Nicola Ken Barozzi wrote:
> Ross Gardler wrote:
>
>> Alex Batlin wrote:
>>
>>> 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.
>
>
> Take a look at the latest changes, there is now wildcard import, it may
> be useful.
Yeah, I saw that, thanks. It will won't help in this case though since
we don't include all plugins on all runs, only those required by the
individual project. This is to allow different plugins to implement
similar functionality.
However, it could be used to solve the copyless conflict, so when I have
finished my current project I'll write up an RT on how it should be
implemented in Forrest core.
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
Re: Using cocoon blocks as plugins
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Ross Gardler wrote:
> Alex Batlin wrote:
>
>> 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.
Take a look at the latest changes, there is now wildcard import, it may
be useful.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Using cocoon blocks as plugins
Posted by Ross Gardler <rg...@apache.org>.
Alex Batlin wrote:
> 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:rgardler@apache.org]
> 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
RE: Using cocoon blocks as plugins
Posted by Alex Batlin <al...@batlin.com>.
Any luck with this? Would love to hear if you found a solution.
-----Original Message-----
From: Ross Gardler [mailto:rgardler@apache.org]
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.6.13 - Release Date: 16/01/2005
Re: Using cocoon blocks as plugins
Posted by Ross Gardler <rg...@apache.org>.
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.6.13 - Release Date: 16/01/2005
Re: Using cocoon blocks as plugins
Posted by Reinhard Poetz <re...@apache.org>.
Ross Gardler wrote:
>
>
> Reinhard Poetz wrote:
>
>> Ross Gardler wrote:
>>
>>> David Crossley wrote:
>>>
>>>> Ross Gardler wrote:
>>>>
>>>>> I almost have the plugin build file automatically creating plugins
>>>>> from Cocoon blocks, but I have hit a problem that I could do with
>>>>> some input on and since I am going to bed now I'm hoping someone
>>>>> will know the answer and save me some research when I start at this
>>>>> again.
>>>>>
>>>>> What I need to do is tell cocoon to run with an xconf file that is
>>>>> not in the main/webapp/WEB-INF directory. This is because the xconf
>>>>> needs to be dynamically created to allow plugins that require
>>>>> entries in the xconf file (currently the file is created in
>>>>> project-tmp.
>>>>>
>>>>> I note that the "site" target uses main/webapp/WEB-INF/cli.xconf,
>>>>> which in turn references main/webapp/WEB-INF/cocoon.xconf. The
>>>>> "run" target does not specify a config file since it picks it up
>>>>> from the webapp.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Projects can use their own cli.xconf file, if that helps.
>>>
>>>
>>>
>>>
>>> Oh, OK, but that would work only for "forrest site" wouldn't it?
>>> (I'll look into it)
>>>
>>> Any ideas for "forrest run"? I'm just not sure how to make the webapp
>>> look somewhere other than main/webapp/WEB-INF for cocoon.xconf (I
>>> suppose I should really be asking on the cocoon list).
>>
>>
>>
>> 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
--
Reinhard
Re: Using cocoon blocks as plugins
Posted by Ross Gardler <rg...@apache.org>.
Reinhard Poetz wrote:
> Ross Gardler wrote:
>
>> David Crossley wrote:
>>
>>> Ross Gardler wrote:
>>>
>>>> I almost have the plugin build file automatically creating plugins
>>>> from Cocoon blocks, but I have hit a problem that I could do with
>>>> some input on and since I am going to bed now I'm hoping someone
>>>> will know the answer and save me some research when I start at this
>>>> again.
>>>>
>>>> What I need to do is tell cocoon to run with an xconf file that is
>>>> not in the main/webapp/WEB-INF directory. This is because the xconf
>>>> needs to be dynamically created to allow plugins that require
>>>> entries in the xconf file (currently the file is created in
>>>> project-tmp.
>>>>
>>>> I note that the "site" target uses main/webapp/WEB-INF/cli.xconf,
>>>> which in turn references main/webapp/WEB-INF/cocoon.xconf. The "run"
>>>> target does not specify a config file since it picks it up from the
>>>> webapp.
>>>
>>>
>>>
>>>
>>> Projects can use their own cli.xconf file, if that helps.
>>
>>
>>
>> Oh, OK, but that would work only for "forrest site" wouldn't it? (I'll
>> look into it)
>>
>> Any ideas for "forrest run"? I'm just not sure how to make the webapp
>> look somewhere other than main/webapp/WEB-INF for cocoon.xconf (I
>> suppose I should really be asking on the cocoon list).
>
>
> 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.
:-(
Ross
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.6.13 - Release Date: 16/01/2005
Re: Using cocoon blocks as plugins
Posted by Reinhard Poetz <re...@apache.org>.
Ross Gardler wrote:
> David Crossley wrote:
>
>> Ross Gardler wrote:
>>
>>> I almost have the plugin build file automatically creating plugins
>>> from Cocoon blocks, but I have hit a problem that I could do with
>>> some input on and since I am going to bed now I'm hoping someone will
>>> know the answer and save me some research when I start at this again.
>>>
>>> What I need to do is tell cocoon to run with an xconf file that is
>>> not in the main/webapp/WEB-INF directory. This is because the xconf
>>> needs to be dynamically created to allow plugins that require entries
>>> in the xconf file (currently the file is created in project-tmp.
>>>
>>> I note that the "site" target uses main/webapp/WEB-INF/cli.xconf,
>>> which in turn references main/webapp/WEB-INF/cocoon.xconf. The "run"
>>> target does not specify a config file since it picks it up from the
>>> webapp.
>>
>>
>>
>> Projects can use their own cli.xconf file, if that helps.
>
>
> Oh, OK, but that would work only for "forrest site" wouldn't it? (I'll
> look into it)
>
> Any ideas for "forrest run"? I'm just not sure how to make the webapp
> look somewhere other than main/webapp/WEB-INF for cocoon.xconf (I
> suppose I should really be asking on the cocoon list).
The location of cocoon.xconf can be configured in web.xml. HTH
--
Reinhard
Re: Using cocoon blocks as plugins
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> Ross Gardler wrote:
>
>>I almost have the plugin build file automatically creating plugins from
>>Cocoon blocks, but I have hit a problem that I could do with some input
>>on and since I am going to bed now I'm hoping someone will know the
>>answer and save me some research when I start at this again.
>>
>>What I need to do is tell cocoon to run with an xconf file that is not
>>in the main/webapp/WEB-INF directory. This is because the xconf needs to
>>be dynamically created to allow plugins that require entries in the
>>xconf file (currently the file is created in project-tmp.
>>
>>I note that the "site" target uses main/webapp/WEB-INF/cli.xconf, which
>>in turn references main/webapp/WEB-INF/cocoon.xconf. The "run" target
>>does not specify a config file since it picks it up from the webapp.
>
>
> Projects can use their own cli.xconf file, if that helps.
Oh, OK, but that would work only for "forrest site" wouldn't it? (I'll
look into it)
Any ideas for "forrest run"? I'm just not sure how to make the webapp
look somewhere other than main/webapp/WEB-INF for cocoon.xconf (I
suppose I should really be asking on the cocoon list).
Ross
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.6.11 - Release Date: 12/01/2005
Re: Using cocoon blocks as plugins
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> I almost have the plugin build file automatically creating plugins from
> Cocoon blocks, but I have hit a problem that I could do with some input
> on and since I am going to bed now I'm hoping someone will know the
> answer and save me some research when I start at this again.
>
> What I need to do is tell cocoon to run with an xconf file that is not
> in the main/webapp/WEB-INF directory. This is because the xconf needs to
> be dynamically created to allow plugins that require entries in the
> xconf file (currently the file is created in project-tmp.
>
> I note that the "site" target uses main/webapp/WEB-INF/cli.xconf, which
> in turn references main/webapp/WEB-INF/cocoon.xconf. The "run" target
> does not specify a config file since it picks it up from the webapp.
Projects can use their own cli.xconf file, if that helps.
--David
> So how can I change the location of the cocoon.xconf file from within
> the "site" and "run" targets (not necessary in "war" since we can simply
> copy the files in to the WAR).
>
> Ross