cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart Roebuck <>
Subject Re: WHATSNEW file - was: Re: Missing cocoon.xconf compiler parameter
Date Wed, 13 Mar 2002 00:14:28 GMT

On Tuesday, March 12, 2002, at 08:27 pm, Vadim Gritsenko wrote:

>> From: Stuart Roebuck (Telewest) []
>> Thanks Vadim,
>> Up until now I've happily gotten away with merging changes to the
>> src/webapp/cocoon.xconf into my own when updating my Cocoon version -
>> it's clear that I should have used the build version of the document
>> which isn't the same thing any more!
> And this "any more" is here for a quite a while now:
> Wed Jan 16 10:39:22 2002 UTC (7 weeks, 6 days ago) by cziegeler:
>   Added new XConfTool which dynamically adds
>   blocks to the cocoon.xconf. This is similar
>   to the sitemap tool, but less sophisticated...for now
> :)

but until a few days ago it still worked as long as you weren't using 
some of the optional code.  Now the cocoon.xconf file in src/ is invalid 
for all uses by default.

>> This reminds me - how about having a plaintext "WHATSNEW" file at the
>> CVS root to which everyone appends changes (in reverse date order -
> with
>> clearly titled break lines for releases), listing any changes to
> Cocoon
>> that impact on the configuration, plus anything else that may be of
>> general interest like 'implemented XXX which speeds up Cocoon by a
>> factor of 100'.
> This is called "changes.xml". Sample record:
>   <action dev="CZ" type="update">
>     Restructured build system. A new ant task (SitemapToolTask) adds
> entries
>     of optional components to the sitemap. Warnings for not available
>     optional components are printed out.
>   </action>
> (I must confess: for second version of XConfTool I did not wrote entry
> to changes.xml, I only sent [ANNOUNCEMENT] email)

Yes, I confess I'd forgotten about the changes.xml file.  It isn't very 
accessible, so I tend to do a cvs2cl on the CVS repository to get the 
same information with the benefit of it being comprehensive, listing all 
source files affected, and providing date information.

I think a human readable (please - no debate on the human readability of 
XML!) file focusing on providing slightly more extensive explanations of 
changes which impact on configuration would be a very valuable part of 
the documentation issues of moving Cocoon into the mainstream.  In fact, 
you could save a bit of work by throwing out changes.xml - and 
generating it automatically with cvs2cl (I think it can output XML - but 
I've never tried it), then using the spare time to keep WHATSNEW up to 
date! ;)

>> It would be *extremely* helpful if someone maintaining a Cocoon
>> configuration could work on the basis that an update of Cocoon would
>> work with their existing .xconf and .xmap files unless explicitly
>> indicated in the WHATSNEW file.
>> I don't think this would be hard to maintain, and it would make it
>> easier to construct release notes to encourage interest in the latest
>> and greatest releases.  The Ant project does it quite well.
> Isn't current Cocoon's release notes are constructed from the
> changes.xml?
> Vadim

            Public Key - 1024D/88DD65AF 2001-11-23 Stuart Roebuck (Adolos)
      Key fingerprint = 89D9 E405 F8B1 9B22 0FA2  F2C1 9E57 5AB1 88DD 65AF
Stuart Roebuck                        
Systems Architect                             Java, XML, MacOS X, XP, 
ADOLOS                                           <>

To unsubscribe, e-mail:
For additional commands, email:

View raw message