David Crossley wrote:
David Crossley wrote:
Ross Gardler wrote:
Thorsten Scherler wrote:
...
I reckon that "benchmark" can be minimal. I also want
to keep the "v3" minimal. The "v2" i have not touched
because i presume that it will be entirely removed prior
to the 0.8 release.
WDYT
Sounds fine to me.
To link the history of the discussion for the archives:
http://thread.gmane.org/gmane.text.xml.forrest.devel/18638
http://issues.apache.org/jira/browse/FOR-776
As mentioned there, Reinhard did some experimentation
at Cocoon-2.2 (pre Daisy docs) that used svn:externals
to maintain the forrest.properties and skinconf.xml etc.
I will investigate and report back. I get the feeling
that it only operates at directory level.
Here is a summary of his technique. There are two aspects:
- including copy of common configuration files via svn:externals
- using xml entities to manage common sections of xml files
Standard configuration files are at
http://svn.apache.org/repos/asf/cocoon/site/src/forrest-configuration
There are various things here such as sitemap.xmap
and stylesheets which we would not need for our situation.
Using 'svn:externals' this directory is created wherever it
is needed, e.g. under
http://svn.apache.org/repos/asf/cocoon/trunk/src/documentation/src
So the tree is ...
documentation
|-- forrest.properties
|-- src (this second src directory was a forrest config mistake)
|-- content
|-- forrest-configuration <---------
|-- skinconf.xml
The forrest.properties refers to resources in the
forrest-configuration directory.
The skinconf.xml declares some of its own stuff,
and includes other skinconf.xml files by using
xml entities. Clever.
:-)
--oOo--
So we could use this technique for managing the config
files of our plugins. At the moment the only ones
that i can think of is skinconf.xml and maybe the
CatalogManager.properties file. Later we might need
to include others.
What do you reckon?
Sounds like a great idea.
--oOo--
The other thing that we discussed (need to find the thread)
was to streamline these "seed" sites so that we can
generate various seed sites, e.g. one that strips
out the Apache licensing info.
I reckon leave this until stage two.
Actually, the infrastructure is already in place in the ant scripts. I
built it for the business template which asks a series of questions and
uses ants filtering to insert the responses into the relevant file.
Note, it is also possible to run an automated business seed, where no
questions are asked and default responses are used.
It's just a case of reusing things, no need for discussion (unless you
can think of a better way of course).
Ross
