You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Nicola Ken Barozzi <ni...@apache.org> on 2002/11/20 14:37:24 UTC
skinconf.xml , single configuration point?
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.
This way we have only one configuration file.
We still need though a place to say where we have *that* file though, so
the options are:
1) move skinconf.xml to top dir instead of forrest.properties
2) keep the double possibility, so forrest.properties takes precedence
and can set the location of skinconf.xml
3) the user sets it via the Ant invocation
4) the file is searched for automatically and the location cached in
the user's home dir.
I'd say (2), so that users with the src/documentation layout can remove
forrest.properties alltogether.
Thoughts?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: skinconf.xml , single configuration point?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
David Crossley wrote:
> Nicola Ken Barozzi wrote:
>
[...] <got-me-thinking/>
>>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.
>
>
> Hang on. What "implementation" are you going to "fix"?
Oops, maybe it's not proper English ;-)
For me "fix up" == build up, ie make a prototype.
> Not Forrest i hope. This configuration issue is not
> yet resolved.
In fact it isn't, I agree. And I think you both have strong points, that
I'm starting to understand better.
Sorry for being so PITA, but for my usage of Forrest does need me to
resolve what I percieve as an issue. I will "fix up" ;-) (joke on me)
something, and see what you think of that concrete possibility instead
of discussing it further. I think I got your concerns and we need to
continue with live examples (not in current CVS space, of course, it's a
proposal).
Thanks for the help :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: skinconf.xml , single configuration point?
Posted by David Crossley <cr...@indexgeo.com.au>.
Nicola Ken Barozzi wrote:
> Jeff Turner wrote:
> > Nicola Ken Barozzi wrote:
<snip/>
> > 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.
Needs to be in both, unless you have some clever way
of associating elements with the same name "credit"
from two separate files.
Anyway, we recently had a proposal to change those
<credit> elements in skinconf.xml to be a generic
<logo> element, which makes sense.
> Width and height should not be there anyway, and not really needed.
They are most definitely needed. All images should have
height and width. Surely you have seen a browser wait for
ever, because it cannot render the table, because it is
waiting for the image download to calculate the size,
because the image has enormous volume or is missing ...
Press the stop button - page displays. They are needed.
Now if Cocoon had an image generator that could detect
the image size at build time, then we would be happy.
> 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.
I agree.
> Module.xml DTD is not fixed.
> I have just added, to make automatic announcements, the fullname=""
> attribute for example.
What DTD? I cannot find it in Forrest. If there was, then we
would be using it for validation.
> 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.
Separate files for each concern sounds good. In XML format
is good too, because then we can at least partially validate
the contents. Yes, the names and locations of these separate
files should be defined in a top-level configuration.
> >>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.
The single file will mix concerns, and will
become unwieldy and complex.
> >>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.
Hang on. What "implementation" are you going to "fix"?
Not Forrest i hope. This configuration issue is not
yet resolved.
--David
Re: skinconf.xml , single configuration point?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
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)
---------------------------------------------------------------------
Re: skinconf.xml , single configuration point?
Posted by Jeff Turner <je...@apache.org>.
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
> >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">
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>
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.
> 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?
> , no data overlap between files
when almost none existed..
> and the files can be merged.
..to what gain?
> Well, this is basically it, I'm too tired now.
+0 to anything that doesn't break backwards-compat.
--Jeff
Re: skinconf.xml , single configuration point?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
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 forrest.properties.
>>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.
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, no data overlap between files and the
files can be merged.
Well, this is basically it, I'm too tired now.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: skinconf.xml , single configuration point?
Posted by Jeff Turner <je...@apache.org>.
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
Re: skinconf.xml , single configuration point?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
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 ?
>>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...
> - 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.
> 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 about this then:
* For project metadata like group, vendor, etc, we use module.xml
* 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
Does this sound better?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: skinconf.xml , single configuration point?
Posted by Jeff Turner <je...@apache.org>.
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?
> This way we have only one configuration file.
Then how about:
- merging forrest.properties into properties.xml
- 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..
Advantage: we don't duplicate the <project-name/> in skinconf.xml with
<project name="..."/> in module.xml
Disadvantage: we force module.xml on projects that may not want it
--Jeff
> We still need though a place to say where we have *that* file though, so
> the options are:
> 1) move skinconf.xml to top dir instead of forrest.properties
> 2) keep the double possibility, so forrest.properties takes precedence
> and can set the location of skinconf.xml
> 3) the user sets it via the Ant invocation
> 4) the file is searched for automatically and the location cached in
> the user's home dir.
>
> I'd say (2), so that users with the src/documentation layout can remove
> forrest.properties alltogether.
>
> Thoughts?
>
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>