forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: skinconf.xml , single configuration point?
Date Wed, 20 Nov 2002 16:22:59 GMT

Jeff Turner wrote:
> 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:


>>>- 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?

Errr, I mean here skinconf=generic term for forrest configuration.
Basically what you have already said (you add a third).

>>>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.

Gee, it's getting confusing 8-)

I want to kill

>>How about this then:
>> * For project metadata like group, vendor, etc, we use module.xml
> Depends on how it's done (see question above).

See answer below ;-)

>> * 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.

> 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, kill redundancy in skinconf and module, have a 
single file that keeps all forrest stuff.


  module.xml ( project metadata
              +link to properties
              +link to skinconf)

  **properties.xml  (Ant build properties, non Forrest)
  **forrestconf.xml (Ant build properties, Forrest)

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, no data overlap between files and the 
files can be merged.

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

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message