David Crossley wrote: > Ross Gardler wrote: > > Thorsten Scherler wrote: > > > > >The solution David has chosen you still can define your minimum > > >configuration even if you just override one property. Besides he added a > > >nice header that you can add any given property again by looking up the > > >fresh-site file (we everything is pretty much described). > > > > You are mixing the two commits David made. One was to clear out > > unnecessary stuff from plugins etc. I'm +1 for that. The other is the > > one above, this is for the template sites. These are used by users as a > > starting point and therefore extra documentation in there will reduce > > the number of questions we get on the mailing lists. > > > > >Another way is to define a svn:ext. Meaning all template sites would > > >keep the blown away properties to play around but we as project have to > > >maintain only one (e.g. the one from fresh-site). > > > > +1 (for the seed sites only - I'm happy with the minimal stuff in > > plugins etc. that are not used by users in the same way) > > Okay, i will try to find another way to avoid the > duplication. > > What i was trying to do was to make the "seed-sample" site > the fully-documented one for all reference. > > I considered that the "basic" one should be basic, > but Tim's httpd.conf analogy is good. I will put > them back to "basic" and "business".
Done. > 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 > 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? --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. -David
