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 2006/01/03 01:55:04 UTC
[proposal] Distributing themes
I propose that themes be distributed as plugins rather than having them
all in the themer plugin. Why?
Because it allows us to break down themes to core and non-core themes.
That is, once the common theme goes into core users will only need to
add, for example, the Coat theme to their project and off they go. These
themes can then be managed/released independently of core (as per plugins).
There is nothing to stop a user defining more than one theme in order to
get other contracts, but I suspect most themes will just be CSS and fv
files, whilst contracts will be provided by core and plugins (e.g. the
feeder plugin would provide the feeder contract).
A second advantage is that the theme can then provide local docs that
demonstrate the unique features of the theme. We can then create a page
listing all themes, with thumbnail screenshots and links to the demo
site using that theme, just like the plugins list we have.
What about naming conventions?
Although the loading mechanism used is the same as plugins, it doesn't
really make sense to call them plugins, so I propose the following
naming convention:
org.apache.forrest.theme.THEME_NAME
WDOT?
Ross
Re: [proposal] Distributing themes
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> Ross Gardler wrote:
>
>>David Crossley wrote:
>>
>>>Ross Gardler wrote:
>>>
>>>>David Crossley wrote:
>>>>
>>>>
>>>>>It is also creating a maintenance problem for the
>>>>>Forrest project. Synchronising and updating those is hell.
>>>>
>>>>Can you expand on the problems?
>>>
>>>If we make a change to the forrest.properties e.g.
>>>add a new parameter. The main example is at
>>>main/fresh-site/forrest.properties but the changes
>>>need to be replicated to every plugin. Same with
>>>skinconf.xml
>>
>>Put the new config in default.forrest.properties (or
>>default.forrest.properties.xml if we adopt the new system). You only
>>need to add it to other themes/plugins/sites if you want to use
>>something other than the default.
>>
>>Since it is a new property and therefore the theme/plugin/site knows
>>nothing about what it does it is highly unlikely it will want anything
>>other than the default.
>
>
> Yes i realize that we can do that. However at the moment
> the pluginTemplate and all current plugins have full
> copies of all the full configuration stuff. We need to
> rationalise that prior to 0.8 release.
I'm proposing using the plugin download mechanism for themese, not using
the plugin template for themes.
Sorry, I wasn't clear enough. I would imagine a different template for
themes.
Ross
Re: [proposal] Distributing themes
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> David Crossley wrote:
> >Ross Gardler wrote:
> >>David Crossley wrote:
> >>
> >>>It is also creating a maintenance problem for the
> >>>Forrest project. Synchronising and updating those is hell.
> >>
> >>Can you expand on the problems?
> >
> >If we make a change to the forrest.properties e.g.
> >add a new parameter. The main example is at
> >main/fresh-site/forrest.properties but the changes
> >need to be replicated to every plugin. Same with
> >skinconf.xml
>
> Put the new config in default.forrest.properties (or
> default.forrest.properties.xml if we adopt the new system). You only
> need to add it to other themes/plugins/sites if you want to use
> something other than the default.
>
> Since it is a new property and therefore the theme/plugin/site knows
> nothing about what it does it is highly unlikely it will want anything
> other than the default.
Yes i realize that we can do that. However at the moment
the pluginTemplate and all current plugins have full
copies of all the full configuration stuff. We need to
rationalise that prior to 0.8 release.
Probably the hardest thing to keep synchronised is the
skinconf.xml in each plugin. Many of them have not been
properly configured (especially whiteboard ones). Perhaps
the pluginTemplate needs a skinconf.xml that is ready
to go for Apache Forrest hosted plugins. At the moment
it is generic and needs to edited for each plugin.
Added as: http://issues.apache.org/jira/browse/FOR-776
-David
Re: [proposal] Distributing themes
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> Ross Gardler wrote:
>
>>David Crossley wrote:
>>
>>>Ross Gardler wrote:
>>>
>>>
>>>>I propose that themes be distributed as plugins rather than having them
>>>>all in the themer plugin. ...
>>>
>>>The reasoning sounds fine. I won't comment further until
>>>we hear Thorsten's view.
>>>
>>>The problem with the plugin approach is that there
>>>is too much extra weight of configuration files, e.g.
>>>skinconf.xml forrest.properties and other templates
>>>and default config, just to show one doc.
>>>
>>>That is probably an orthoganal issue. We need to
>>>solve it for plugins too.
>>
>>Agreed.
>>
>>I've been thinking for some time that there is no good reason for
>>distributing the docs with the plugins. They are available online and
>>should be made available as a separate download (we can use the same
>>framework). This is particularly important for plugins like the photo
>>album, which has some large images in the docs.
>>
>>
>>>It is also creating a maintenance problem for the
>>>Forrest project. Synchronising and updating those is hell.
>>
>>Can you expand on the problems?
>
>
> If we make a change to the forrest.properties e.g.
> add a new parameter. The main example is at
> main/fresh-site/forrest.properties but the changes
> need to be replicated to every plugin. Same with
> skinconf.xml
Put the new config in default.forrest.properties (or
default.forrest.properties.xml if we adopt the new system). You only
need to add it to other themes/plugins/sites if you want to use
something other than the default.
Since it is a new property and therefore the theme/plugin/site knows
nothing about what it does it is highly unlikely it will want anything
other than the default.
>>I know we recently had issues with versioned plugins, but that was the
>>first time we had done a versioned release. I think the code is right
>>now. There should be no real problem anymore (needs more thorough testing).
>
>
> I haven't tested that stuff yet, e.g. do we still
> have a problem with the 0.7 downloading of say the
> projectInfo plugin.
No (but need more thoroguh testing).
Ross
Re: [proposal] Distributing themes
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> David Crossley wrote:
> >Ross Gardler wrote:
> >
> >>I propose that themes be distributed as plugins rather than having them
> >>all in the themer plugin. ...
> >
> >The reasoning sounds fine. I won't comment further until
> >we hear Thorsten's view.
> >
> >The problem with the plugin approach is that there
> >is too much extra weight of configuration files, e.g.
> >skinconf.xml forrest.properties and other templates
> >and default config, just to show one doc.
> >
> >That is probably an orthoganal issue. We need to
> >solve it for plugins too.
>
> Agreed.
>
> I've been thinking for some time that there is no good reason for
> distributing the docs with the plugins. They are available online and
> should be made available as a separate download (we can use the same
> framework). This is particularly important for plugins like the photo
> album, which has some large images in the docs.
>
> >It is also creating a maintenance problem for the
> >Forrest project. Synchronising and updating those is hell.
>
> Can you expand on the problems?
If we make a change to the forrest.properties e.g.
add a new parameter. The main example is at
main/fresh-site/forrest.properties but the changes
need to be replicated to every plugin. Same with
skinconf.xml
> I know we recently had issues with versioned plugins, but that was the
> first time we had done a versioned release. I think the code is right
> now. There should be no real problem anymore (needs more thorough testing).
I haven't tested that stuff yet, e.g. do we still
have a problem with the 0.7 downloading of say the
projectInfo plugin.
-David
Re: [proposal] Distributing themes
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> Ross Gardler wrote:
>
>>I propose that themes be distributed as plugins rather than having them
>>all in the themer plugin. ...
>
>
> The reasoning sounds fine. I won't comment further until
> we hear Thorsten's view.
>
> The problem with the plugin approach is that there
> is too much extra weight of configuration files, e.g.
> skinconf.xml forrest.properties and other templates
> and default config, just to show one doc.
>
> That is probably an orthoganal issue. We need to
> solve it for plugins too.
Agreed.
I've been thinking for some time that there is no good reason for
distributing the docs with the plugins. They are available online and
should be made available as a separate download (we can use the same
framework). This is particularly important for plugins like the photo
album, which has some large images in the docs.
> It is also creating a maintenance problem for the
> Forrest project. Synchronising and updating those is hell.
Can you expand on the problems?
I know we recently had issues with versioned plugins, but that was the
first time we had done a versioned release. I think the code is right
now. There should be no real problem anymore (needs more thorough testing).
Ross
Re: theme package template (was Re: [proposal] Distributing themes)
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> El mié, 04-01-2006 a las 10:33 +0000, Ross Gardler escribió:
>
>>Thorsten Scherler wrote:
>>
...
>>Your suggestion of adding docs to the themer directory plugin does not
>>work since this means all themes have to be hosted here at Forrest.
>
>
> Why?
>
> The documentation/samples is/could be in the *themes* package. Like:
> org.apache.forrest.themes.X/x/samples/...
>
> ...and of course in the contracts - the main documentation location for
> a theme!
We have crossed wires there. I thought you were suggesting that the docs
go in org.apache.forrest.plugins.output.themer
IO see above, you are actually saying the asme as me - cool ;-)
>>We
>>need a mechanism that allows local sites to use their own themes, and
>>hopefully publish them as well.
>
>
> Yeah, IMO we should extend the http://localhost:8888/ls.contracts.html
> to include all available contracts. The documentation about a theme
> should be mainly in the contracts - self explaining and standalone!!!
Don't forget a theme is also the way a page looks (i.e. the CSS and the
configuration of the contracts in a page layout).
I know we can argue that this is completely configurable and not
binding. But the reality is that very few users will actually change
much of the default stuff - look at how few have changed the default skin.
I think the realty of the average user is that they will go to some page
that looks like [1] and click on a picture that looks nice to download a
theme. As they learn Forrest they may start tweaking *.css and *.fv
files, but the "sale point" is [1]
Another really cool "sale point" is [2]
> Besides this documentation every theme could provide additional
> information, but all this could be done with the above root or directly
> in contracts.
I'm not sure what you mean by this, but it seems to be an implementation
detail, so we'll come back to it later.
>>>BTW actually I changed the convention because a theme does not only have
>>>to provide just *one* theme, but it can provide as many themes as it
>>>wishes. It is a package of themes.
>>
>>+1
>>
>
>
> :)
>
> Ok we have an overall agreement besides the documentation part. Nice.
> How can I set up the basic infrastructure for this new type of plugin?
Leave that with me - it'll probably be quicker for me to do it than to
expalain it, I know you will watch the commits. Probably get to it early
next week, I'll start with the Coat.
[1] http://www.alentus.com/hosted-applications/dnntour/WebsiteChangeSkin.asp
[2] http://www.alexking.org/software/wordpress/theme_browser.php
Re: theme package template (was Re: [proposal] Distributing themes)
Posted by Thorsten Scherler <th...@apache.org>.
El mié, 04-01-2006 a las 10:33 +0000, Ross Gardler escribió:
> Thorsten Scherler wrote:
> > El mar, 03-01-2006 a las 14:14 +0000, Ross Gardler escribió:
> >
> >>Thorsten Scherler wrote:
> >>
> >>>El mar, 03-01-2006 a las 13:25 +1100, David Crossley escribió:
> >>>
> >>>
> >>>>Ross Gardler wrote:
> >>>>
> >>>>
> >>>>>I propose that themes be distributed as plugins rather than having them
> >>>>>all in the themer plugin. ...
> >>>>
> >>...
> >>
> >>
> >>>Resuming all above, I am with you that we need a system to package
> >>>themes and make them downloadable but disagree about the overhead to do
> >>>it with a plugin.
> >>
> >>What overhead? Specifics please.
> >>
> >
> >
> > You would just need
> > forrest/trunk/whiteboard/plugins/org.apache.forrest.theme.Coat/src/documentation/resources/themes/coat/* forrest/trunk/whiteboard/plugins/org.apache.forrest.theme.Coat/src/documentation/resources/themes/coat.fv
> >
> > everything else is overhead.
>
> Sure, everything else is optional in the plugin installation process, or
> can easily be made optional, it's just a modification of the ant script.
>
> However, don't forget the docs stuff. I want to see decent docs for
> themes too.
>
> Your suggestion of adding docs to the themer directory plugin does not
> work since this means all themes have to be hosted here at Forrest.
Why?
The documentation/samples is/could be in the *themes* package. Like:
org.apache.forrest.themes.X/x/samples/...
...and of course in the contracts - the main documentation location for
a theme!
> We
> need a mechanism that allows local sites to use their own themes, and
> hopefully publish them as well.
Yeah, IMO we should extend the http://localhost:8888/ls.contracts.html
to include all available contracts. The documentation about a theme
should be mainly in the contracts - self explaining and standalone!!!
Besides this documentation every theme could provide additional
information, but all this could be done with the above root or directly
in contracts.
>
> >>Note that I already addressed the point about docs, which should be
> >>removed from the download and packaged separately. This is easily done
> >>by adding an <exclude...> pattern to the ant script.
> >>
> >>Note that things like input.xmap, locationmap.xml etc. are only used if
> >>they are present.
> >>
> >
> >
> > Yeah, this sentence made me think whether we want to allow themes to
> > provide a sitemap.xmap?
>
> I don't think so, as you say a theme is *.fv and *.css files.
and contracts.
> If a theme
> needs to do processing of the data then it is really an output plugin
> isn't it? However, keeping the download mechanism the same gives us
> flexibility should a use case for arise.
>
agree
> >>>I agree as well on the naming convention, so how can we use the old
> >>>fashion skin download mechanism for themes?
> >>
> >>The plugin download mechanism *is* the original skin download mechanism
> >>(with versioning added).
> >>
> >
> >
> > Yeah, but the problem with using it directly as plugin is that the list
> > of required plugins is growing to the unreadable.
>
> We don't have to list it as a plugin. Different naming convention,
> different descriptor file, different index page, same download mechanism.
>
ok, that sounds good, because the easiest thing would be that all themes
get extracted to *one* dir like build/themes/... This way it would be
very easy to have the documentation of all installed plugins in the
project, including the contract documentation.
> > Anyway I am fine with using plugins directly but with another template
> > like you suggested in your other reply to David.
> >
> > My suggestion for a theme template would be:
> >
> > org.apache.forrest.theme.X/sitemap.xmap (optional -> I am not even sure
> > whether we should allow that)
> > org.apache.forrest.theme.X/themes/x.fv
> > org.apache.forrest.theme.X/themes/x/*
> >
> > or
> >
> > org.apache.forrest.themes.X/x.fv
> > org.apache.forrest.themes.X/x/*
> >
> > That is optimized with nearly no overhead.
> >
> > BTW actually I changed the convention because a theme does not only have
> > to provide just *one* theme, but it can provide as many themes as it
> > wishes. It is a package of themes.
>
> +1
>
:)
Ok we have an overall agreement besides the documentation part. Nice.
How can I set up the basic infrastructure for this new type of plugin?
> Ross
>
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: theme package template (was Re: [proposal] Distributing themes)
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> El mar, 03-01-2006 a las 14:14 +0000, Ross Gardler escribió:
>
>>Thorsten Scherler wrote:
>>
>>>El mar, 03-01-2006 a las 13:25 +1100, David Crossley escribió:
>>>
>>>
>>>>Ross Gardler wrote:
>>>>
>>>>
>>>>>I propose that themes be distributed as plugins rather than having them
>>>>>all in the themer plugin. ...
>>>>
>>...
>>
>>
>>>Resuming all above, I am with you that we need a system to package
>>>themes and make them downloadable but disagree about the overhead to do
>>>it with a plugin.
>>
>>What overhead? Specifics please.
>>
>
>
> You would just need
> forrest/trunk/whiteboard/plugins/org.apache.forrest.theme.Coat/src/documentation/resources/themes/coat/* forrest/trunk/whiteboard/plugins/org.apache.forrest.theme.Coat/src/documentation/resources/themes/coat.fv
>
> everything else is overhead.
Sure, everything else is optional in the plugin installation process, or
can easily be made optional, it's just a modification of the ant script.
However, don't forget the docs stuff. I want to see decent docs for
themes too.
Your suggestion of adding docs to the themer directory plugin does not
work since this means all themes have to be hosted here at Forrest. We
need a mechanism that allows local sites to use their own themes, and
hopefully publish them as well.
>>Note that I already addressed the point about docs, which should be
>>removed from the download and packaged separately. This is easily done
>>by adding an <exclude...> pattern to the ant script.
>>
>>Note that things like input.xmap, locationmap.xml etc. are only used if
>>they are present.
>>
>
>
> Yeah, this sentence made me think whether we want to allow themes to
> provide a sitemap.xmap?
I don't think so, as you say a theme is *.fv and *.css files. If a theme
needs to do processing of the data then it is really an output plugin
isn't it? However, keeping the download mechanism the same gives us
flexibility should a use case for arise.
>>>I agree as well on the naming convention, so how can we use the old
>>>fashion skin download mechanism for themes?
>>
>>The plugin download mechanism *is* the original skin download mechanism
>>(with versioning added).
>>
>
>
> Yeah, but the problem with using it directly as plugin is that the list
> of required plugins is growing to the unreadable.
We don't have to list it as a plugin. Different naming convention,
different descriptor file, different index page, same download mechanism.
> Anyway I am fine with using plugins directly but with another template
> like you suggested in your other reply to David.
>
> My suggestion for a theme template would be:
>
> org.apache.forrest.theme.X/sitemap.xmap (optional -> I am not even sure
> whether we should allow that)
> org.apache.forrest.theme.X/themes/x.fv
> org.apache.forrest.theme.X/themes/x/*
>
> or
>
> org.apache.forrest.themes.X/x.fv
> org.apache.forrest.themes.X/x/*
>
> That is optimized with nearly no overhead.
>
> BTW actually I changed the convention because a theme does not only have
> to provide just *one* theme, but it can provide as many themes as it
> wishes. It is a package of themes.
+1
Ross
theme package template (was Re: [proposal] Distributing themes)
Posted by Thorsten Scherler <th...@apache.org>.
El mar, 03-01-2006 a las 14:14 +0000, Ross Gardler escribió:
> Thorsten Scherler wrote:
> > El mar, 03-01-2006 a las 13:25 +1100, David Crossley escribió:
> >
> >>Ross Gardler wrote:
> >>
> >>>I propose that themes be distributed as plugins rather than having them
> >>>all in the themer plugin. ...
> >>
>
> ...
>
> > Resuming all above, I am with you that we need a system to package
> > themes and make them downloadable but disagree about the overhead to do
> > it with a plugin.
>
> What overhead? Specifics please.
>
You would just need
forrest/trunk/whiteboard/plugins/org.apache.forrest.theme.Coat/src/documentation/resources/themes/coat/* forrest/trunk/whiteboard/plugins/org.apache.forrest.theme.Coat/src/documentation/resources/themes/coat.fv
everything else is overhead.
> Note that I already addressed the point about docs, which should be
> removed from the download and packaged separately. This is easily done
> by adding an <exclude...> pattern to the ant script.
>
> Note that things like input.xmap, locationmap.xml etc. are only used if
> they are present.
>
Yeah, this sentence made me think whether we want to allow themes to
provide a sitemap.xmap?
> > I agree as well on the naming convention, so how can we use the old
> > fashion skin download mechanism for themes?
>
> The plugin download mechanism *is* the original skin download mechanism
> (with versioning added).
>
Yeah, but the problem with using it directly as plugin is that the list
of required plugins is growing to the unreadable.
Anyway I am fine with using plugins directly but with another template
like you suggested in your other reply to David.
My suggestion for a theme template would be:
org.apache.forrest.theme.X/sitemap.xmap (optional -> I am not even sure
whether we should allow that)
org.apache.forrest.theme.X/themes/x.fv
org.apache.forrest.theme.X/themes/x/*
or
org.apache.forrest.themes.X/x.fv
org.apache.forrest.themes.X/x/*
That is optimized with nearly no overhead.
BTW actually I changed the convention because a theme does not only have
to provide just *one* theme, but it can provide as many themes as it
wishes. It is a package of themes.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: [proposal] Distributing themes
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> El mar, 03-01-2006 a las 13:25 +1100, David Crossley escribió:
>
>>Ross Gardler wrote:
>>
>>>I propose that themes be distributed as plugins rather than having them
>>>all in the themer plugin. ...
>>
...
> Resuming all above, I am with you that we need a system to package
> themes and make them downloadable but disagree about the overhead to do
> it with a plugin.
What overhead? Specifics please.
Note that I already addressed the point about docs, which should be
removed from the download and packaged separately. This is easily done
by adding an <exclude...> pattern to the ant script.
Note that things like input.xmap, locationmap.xml etc. are only used if
they are present.
> I agree as well on the naming convention, so how can we use the old
> fashion skin download mechanism for themes?
The plugin download mechanism *is* the original skin download mechanism
(with versioning added).
Ross
Re: [proposal] Distributing themes
Posted by Thorsten Scherler <th...@apache.org>.
El mar, 03-01-2006 a las 13:25 +1100, David Crossley escribió:
> Ross Gardler wrote:
> > I propose that themes be distributed as plugins rather than having them
> > all in the themer plugin. ...
>
> The reasoning sounds fine. I won't comment further until
> we hear Thorsten's view.
>
> The problem with the plugin approach is that there
> is too much extra weight of configuration files, e.g.
> skinconf.xml forrest.properties and other templates
> and default config, just to show one doc.
>
> That is probably an orthoganal issue. We need to
> solve it for plugins too.
>
> It is also creating a maintenance problem for the
> Forrest project. Synchronising and updating those is hell.
>
Yeah that is the main point. We actually would keep a lot of stuff that
is not needed for the theme. IMO extra samples and related resources
should be integrated differently.
Like I wrote as answer on the initial theme commit the theme could be
kept like a skin. Actually theming is working nearly the same as skins
in this regards. The idea is to use the skin download mechanism to
request the theme (if not installed on the system) from a theme
repository. One can specify more then one repository (including file
system) to search for the requested skin.
This description is based on what we have, but it has the problem of the
heavy use of ant and forrest.properties. I did not adopt the new
configuration system till now that is the reason why you can ATM specify
*one* project specific themer in the forrest.properties:
+##########################################
+# *advanced configuration* - you can specify which plugins you want
+# use internal.
+#project.themer=
${forrest.home}/build/plugins/org.apache.forrest.plugin.output.themer
With this property it is possible to override the default themer and use
a custom themer and its themes. That needs to be more specific and
rewritten under the thought of a repository.
I thought about to move this property to the forrest.properties.xml and
rename it to themer-rep. I would prefer to have a clean separation
between plugins and themes.
Another problem is with the proposal and the current above mentioned
project.themer that each theme would have to be a themer itself where it
would be sufficient to only provide theme specific contracts and
modifications (.../resources/themes/*). I expect that a theme will
generally use 90% of the common theme and only provide 10% extra
contracts/css/... The idea is that common theme is the core and all
other themes extend/modify the behavior of this theme.
Anyway, back to the sample thought of Ross
"A second advantage is that the theme can then provide local docs that
demonstrate the unique features of the theme."
in /resources/themes/coat/ we can add a dir called samples or
documentation where we store this stuff if somebody needs it, but it
should be optional.
.../resources/themes/coat/documentation/*
Resuming all above, I am with you that we need a system to package
themes and make them downloadable but disagree about the overhead to do
it with a plugin.
I agree as well on the naming convention, so how can we use the old
fashion skin download mechanism for themes?
Basically it is the same:
- contact theme-server
- search theme
- if found download theme.zip and extracted it to the build theme rep
(e.g.
$FORREST_HOME/build/plugins/org.apache.forrest.plugin.output.themer/resources/themes)
- if not contact next theme-server if exists
WDYT?
> At one stage, Reinhard did some nice experiments at Cocoon
> with centralised config for various projects. Probably still
> in cocoon-trunk.
>
> -David
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: [proposal] Distributing themes
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> I propose that themes be distributed as plugins rather than having them
> all in the themer plugin. ...
The reasoning sounds fine. I won't comment further until
we hear Thorsten's view.
The problem with the plugin approach is that there
is too much extra weight of configuration files, e.g.
skinconf.xml forrest.properties and other templates
and default config, just to show one doc.
That is probably an orthoganal issue. We need to
solve it for plugins too.
It is also creating a maintenance problem for the
Forrest project. Synchronising and updating those is hell.
At one stage, Reinhard did some nice experiments at Cocoon
with centralised config for various projects. Probably still
in cocoon-trunk.
-David