You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Cyriaque Dupoirieux <Cy...@pcotech.fr> on 2006/01/05 16:14:10 UTC
Re: svn commit: r366100 - in /forrest/trunk/main: fresh-site/forrest.properties
template-sites/basic/forrest.properties template-sites/benchmark/forrest.properties
template-sites/business/forrest.properties template-sites/v3/forrest.properti
Tim Williams a écrit :
>On 1/5/06, Ross Gardler <rg...@apache.org> wrote:
>
>
>>crossley@apache.org wrote:
>>
>>
>>>Author: crossley
>>>Date: Wed Jan 4 23:01:23 2006
>>>New Revision: 366100
>>>
>>>URL: http://svn.apache.org/viewcvs?rev=366100&view=rev
>>>Log:
>>>Use minimal forrest.properties files.
>>>
>>>Modified:
>>> forrest/trunk/main/fresh-site/forrest.properties
>>> forrest/trunk/main/template-sites/basic/forrest.properties
>>> forrest/trunk/main/template-sites/benchmark/forrest.properties
>>> forrest/trunk/main/template-sites/business/forrest.properties
>>> forrest/trunk/main/template-sites/v3/forrest.properties
>>>
>>>
>>>
>>I'm not sure this is a good idea. Many users discover how to change
>>things in Forrest by reading this document from their seeded site.
>>
>>If we are going to go for a minimal version like this (which certainly
>>looks less scary) we need a doc to detail the changes that are possible,
>>and we need the minimal file to point to that doc.
>>
>>Ross
>>
>>
>
>I prefer having the beefier properties file vs minimal pointing to a
>detailed doc. I liken our properties file to httpd.conf where I would
>be lost if they didn't have all of the directives in there commented
>out and well-described. I also suspect this will lead new folks to
>making changes to webapp\default-forrest.properties because that's
>where they happen to see the keys they want to change. At least those
>of us who follow the LBPA (learn by poking around) method.
>
>--tim
>
>
>
I also agree, It's a little bit like commented java or xsl sources is
better than separated long design document...
(But separated doc is also needed ;-) )
Salutations,
Cyriaque,
Re: maintain forrest.properties skinconf.xml etc. (Was: svn commit: r366100)
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> David Crossley wrote:
> >David Crossley wrote:
> >>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.
I changed my mind. For the common skinconf stuff,
use a centralised xml entity. It is neat. (svn r367219)
There is too much overhead with the abovementioned
svn:externals technique to use it just for this
common skinconf stuff. Pehaps later for other common
config.
-David
Re: maintain forrest.properties skinconf.xml etc. (Was: svn commit:
r366100)
Posted by Ross Gardler <rg...@apache.org>.
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
Re: maintain forrest.properties skinconf.xml etc. (Was: svn commit: r366100)
Posted by David Crossley <cr...@apache.org>.
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
maintain forrest.properties skinconf.xml etc. (Was: svn commit: r366100)
Posted by David Crossley <cr...@apache.org>.
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".
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.
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.
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.
-David
Re: svn commit: r366100 - in /forrest/trunk/main: fresh-site/forrest.properties
template-sites/basic/forrest.properties template-sites/benchmark/forrest.properties
template-sites/business/forrest.properties template-sites/v3/forrest.properti
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> El jue, 05-01-2006 a las 16:14 +0100, Cyriaque Dupoirieux escribió:
>
>>Tim Williams a écrit :
>>
>>
>>>On 1/5/06, Ross Gardler <rg...@apache.org> wrote:
>>>
>>>
>>>
>>>>crossley@apache.org wrote:
>>>>
>>>>
>>>>
>>>>>Author: crossley
>>>>>Date: Wed Jan 4 23:01:23 2006
>>>>>New Revision: 366100
>>>>>
>>>>>URL: http://svn.apache.org/viewcvs?rev=366100&view=rev
>>>>>Log:
>>>>>Use minimal forrest.properties files.
>>>>>
>>>>>Modified:
>>>>> forrest/trunk/main/fresh-site/forrest.properties
>>>>> forrest/trunk/main/template-sites/basic/forrest.properties
>>>>> forrest/trunk/main/template-sites/benchmark/forrest.properties
>>>>> forrest/trunk/main/template-sites/business/forrest.properties
>>>>> forrest/trunk/main/template-sites/v3/forrest.properties
...
> 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)
Ross
Re: svn commit: r366100 - in /forrest/trunk/main:
fresh-site/forrest.properties template-sites/basic/forrest.properties
template-sites/benchmark/forrest.properties
template-sites/business/forrest.properties
template-sites/v3/forrest.properti
Posted by Thorsten Scherler <th...@apache.org>.
El jue, 05-01-2006 a las 16:14 +0100, Cyriaque Dupoirieux escribió:
> Tim Williams a écrit :
>
> >On 1/5/06, Ross Gardler <rg...@apache.org> wrote:
> >
> >
> >>crossley@apache.org wrote:
> >>
> >>
> >>>Author: crossley
> >>>Date: Wed Jan 4 23:01:23 2006
> >>>New Revision: 366100
> >>>
> >>>URL: http://svn.apache.org/viewcvs?rev=366100&view=rev
> >>>Log:
> >>>Use minimal forrest.properties files.
> >>>
> >>>Modified:
> >>> forrest/trunk/main/fresh-site/forrest.properties
> >>> forrest/trunk/main/template-sites/basic/forrest.properties
> >>> forrest/trunk/main/template-sites/benchmark/forrest.properties
> >>> forrest/trunk/main/template-sites/business/forrest.properties
> >>> forrest/trunk/main/template-sites/v3/forrest.properties
> >>>
> >>>
> >>>
> >>I'm not sure this is a good idea. Many users discover how to change
> >>things in Forrest by reading this document from their seeded site.
> >>
> >>If we are going to go for a minimal version like this (which certainly
> >>looks less scary) we need a doc to detail the changes that are possible,
> >>and we need the minimal file to point to that doc.
> >>
> >>Ross
> >>
> >>
> >
> >I prefer having the beefier properties file vs minimal pointing to a
> >detailed doc. I liken our properties file to httpd.conf where I would
> >be lost if they didn't have all of the directives in there commented
> >out and well-described. I also suspect this will lead new folks to
> >making changes to webapp\default-forrest.properties because that's
> >where they happen to see the keys they want to change. At least those
> >of us who follow the LBPA (learn by poking around) method.
> >
> >--tim
> >
> >
> >
> I also agree, It's a little bit like commented java or xsl sources is
> better than separated long design document...
> (But separated doc is also needed ;-) )
>
> Salutations,
> Cyriaque,
You are all right but I see why David has done this. Right now we have
to keep x template-sites forrest.properties (under some other files) in
sync. That is overkill in the near future.
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).
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).
I am unsure which way is better but for e.g. the basic seed David commit
is definitely the way to go. ;-)
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)