forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <je...@apache.org>
Subject Re: skinconf.xml , single configuration point?
Date Wed, 20 Nov 2002 15:14:32 GMT
On Wed, Nov 20, 2002 at 03:21:37PM +0100, Nicola Ken Barozzi wrote:
> 
> Jeff Turner wrote:
> >On Wed, Nov 20, 2002 at 02:37:24PM +0100, Nicola Ken Barozzi wrote:
> >
> >>To reduce the number of files needed for forrest, I would propose to 
> >>move all forrest.properties under skinconf.xml, and that file be used in 
> >>Ant via XmlProperty.
> >
> >
> >They don't configure the skin, should why should they be in skinconf?
> 
> skinconf -> forrestconf ?

forrestconf -> "configuring forrest"?  There's different classes of
things to configure:

 - Project metadata (name, copyright, credits etc)
 - Project structural metadata (where key files live)
 - Forrest runtime behaviour (which files to validate, log verbosity, etc)

Currently the first lives in skinconf.xml, the second are 'project.*'
properties, and the third are 'forrest.*' properties.

> >>This way we have only one configuration file.
> >
> >
> >Then how about:
> > - merging forrest.properties into properties.xml
> 
> This I thought about before, but only this basically just moves the 
> problem from a properties file to another...

Yes..

> > - merging skinconf.xml into module.xml
> >
> >Merging skinconf.xml and module.xml was always the plan, since they both
> >contain generic project metadata.
> >
> >I don't reeeally see much benefit in merging skinconf and module though..
> 
> Actually I don't either, because the skinconf is (IMV based on Centipede 
> experience) both about metadata and build-properties, like the includes 
> and excludes.

Noo.. skinconf is the minimum of project metadata useful for configuring
the skins.  Why would structural metadata (includes and excludes) be of
interest to skin stylesheets?

> >Advantage: we don't duplicate the <project-name/> in skinconf.xml with
> ><project name="..."/> in module.xml
> 
> This is good...
> 
> >Disadvantage: we force module.xml on projects that may not want it
> 
> Actually it's not such a bad thing.
> Maven can generate it automatically, and this could help Mavenized 
> projects to easily:
> 
>  1) use Forrest also standalone
>  2) be ready for Gump

How do you picture skinconf and module.xml merging?  Would they
physically be one file, or as suggested once, would module.xml have a
href to skinconf.xml, as a sort of external extension of module.xml?

Making them one file might not be a good idea.. there's stuff like
<enable-search/> which is clearly Forrest skin-specific (and could never
be generated by Maven).

If they are separate files (module.xml linking to skinconf.xml), then
nothing significant changes from the situation today.

> How about this then:
>  * For project metadata like group, vendor, etc, we use module.xml

Depends on how it's done (see question above).

>  * For Forrest properties, we put a reference in module.xml to the xml
>    file that contains them, and in our case it can be properties.xml
>    by default

I don't really see the benefit.. just makes it less obvious where Forrest
stuff is kept.  Besides, module.xml doesn't currently link to
properties.xml.. why should Forrest properties cause it to?  What
software cares if module.xml links to the Forrest properties?

> Does this sound better?

Dunno what you're trying to achieve ;P  I'm a boring person who likes to
keep the status quo unless there's a compelling reason to change.


--Jeff

Mime
View raw message