forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <>
Subject Re: skinconf.xml , single configuration point?
Date Thu, 21 Nov 2002 04:25:04 GMT
On Wed, Nov 20, 2002 at 05:22:59PM +0100, Nicola Ken Barozzi wrote:
> >>* 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.  
> But it enables me to use a single file for forrest and Ant.
> I already have a properties.xml file for example, and I just want to 
> append forrest attributes. Wherever I put it, it's referenceable, and 
> can be both a separate forrestconf.xml or the properties.xml that keeps 
> other properties too.

Okay.. so,

Centipede projects use properties.xml
Avalon projects use,
Maven projects use
The rest of Jakarta uses
many projects (xerces, excalibur) use

There is obviously no standard that Forrest is not conforming to.
Choosing _any_ of these is going to annoy someone.

Does it have to be either/or?  Why not have:

<xmlproperty file="${project.home}/properties.xml"/>
<property file="${project.home}/" />
... any other possibilities

> >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?
> module.xml is a place that keeps references to all project 
> configurations, and keeps some inside.
> It keeps location of resulting jars, javadocs, and for Centipede source 
> dirs, test dirs, docs dirs, etc.
> Since we must tell Forrest where to find the properties if (see above) 
> we want to be able to det the location in any place, module.xml is the 
> only safe place, since it also contains project metadata that now 
> duplicates skinconf stuff and that has to be there.
> Clear? ;-P  <tired/>
> >>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.
> Kill forrest properties

Hmm.. :P

> kill redundancy in skinconf and module

Let's look a bit harder at this so-called redundancy..

Firstly, I don't think any Apache projects other than Forrest and Cocoon
use module.xml as a source of project metadata in project builds.  So the
projects potentially experiencing this 'redundancy' are thin on the

Secondly, what exactly is duplicated?  Skinconf has:


module.xml has:

  <project name="apache-forrest">

Not the same thing.  One name is for display in a skin, another is a CVS
module name for Gump.  And besides, module.xml has multiple <project>
blocks.  How would a skin XSLT know not to use:

  <project name="apache-forrest-forrestbar">

Module.xml also lists credits:

    This software includes software developed by the Krysalis Project
    This product includes software developed by CollabNet (http://www.Collab.Net/).

Skinconf lists roughly the same information, but *in a format useful for

      <name>Built with Cocoon</name>
      <name>Krysalis Centipede</name>

So again, unless module.xml is going to be polluted with skin-specific
stuff like <image>, <width> and <height>, this info can't be isolated in

> have a single file that keeps all forrest stuff.
> Example:
>  module.xml ( project metadata
>              +link to properties
>              +link to skinconf)
>  **properties.xml  (Ant build properties, non Forrest)
>  **forrestconf.xml (Ant build properties, Forrest)
>  **skinconf.xml
> All these three can be in the same file, or all separated, or mixed.
> For the default layout I'd probably separate them all for build 
> simplicity, and this basically recreates the current situation with 
> -> forrestconf.xml, but with the differences that the 
> locations are all configurable

Location of what, forrestconf.xml?

> , no data overlap between files

when almost none existed..

> and the files can be merged. what gain?

> Well, this is basically it, I'm too tired now.

+0 to anything that doesn't break backwards-compat.


View raw message