forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: skinconf.xml , single configuration point?
Date Thu, 21 Nov 2002 08:21:48 GMT

Jeff Turner wrote:
> 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 .ant.properties,
> Maven projects use project.properties
> The rest of Jakarta uses build.properties
> many projects (xerces, excalibur) use default.properties.
> 
> 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}/forrest.properties" />
> ... any other possibilities

Mine was an example of my use case.
If we make it *confugurable*, we can make projects use what they want.

<documentation type="forrest" conf="properties.xml"/>

or

<documentation type="forrest" conf="forrest.xml"/>

or

<documentation type="forrest" conf="project.properties"/>

or

<documentation type="forrest" conf="forrest.properties"/>

or

...

>>>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
> ground.
 >
> Secondly, what exactly is duplicated?  Skinconf has:
> 
>   <project-name>Forrest</project-name>
> 
> 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">

  <xsl:value-of="."/>

> Module.xml also lists credits:
> 
> <credits>
>   <credit>
>     This software includes software developed by the Krysalis Project
>     (http://www.krysalis.org/).
>   </credit>
>   <credit>
>     This product includes software developed by CollabNet (http://www.Collab.Net/).
>   </credit>
> </credits>
> 
> Skinconf lists roughly the same information, but *in a format useful for
> skins*:
> 
> <credits>
>     <credit>
>       <name>Built with Cocoon</name>
>       <url>http://xml.apache.org/cocoon/</url>
>       <image>images/built-with-cocoon.gif</image>
>       <width>88</width>
>       <height>31</height>
>     </credit>
>     <credit>
>       <name>Krysalis Centipede</name>
>       <url>http://www.krysalis.org/centipede/</url>
>       <image>images/centipede-logo-small.gif</image>
>       <width>138</width>
>       <height>31</height>
>     </credit>
> </credits>

url should be added to module.xml.
Width and height should not be there anyway, and not really needed.
As for the image, it can be in skinconf with a reference to the proper 
module.xml credit, or be in module.xml itself.

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

Module.xml DTD is not fixed.
I have just added, to make automatic announcements, the fullname="" 
attribute for example.

The fact that some project metadata is not present yet doesn't mean it 
shouldn't be there.

Gump makes cool cross-project dependency pages. IMHO it would be cool if 
they were skinned by Forrest and have the additional project info added.

>>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 
>>forrest.properties -> forrestconf.xml, but with the differences that the 
>>locations are all configurable
> 
> Location of what, forrestconf.xml?

Of forrestconf and skinconf.

>>, no data overlap between files
> 
> when almost none existed..
> 
>>and the files can be merged.
> 
> ..to what gain?

Have a single properties file.
One place to look at, one place to manage.

>>Well, this is basically it, I'm too tired now.
> 
> +0 to anything that doesn't break backwards-compat.

Ok, point taken.

Actually, the proposed mechanism can be made not to break backwards 
compatibility, and even with the new method, it can be configured to 
work exactly as the old one.

I'll fix up the implementation and show you.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


Mime
View raw message