You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by "Stuart Roebuck (Telewest)" <st...@mac.com> on 2002/03/12 21:13:54 UTC
WHATSNEW file - was: Re: Missing cocoon.xconf compiler parameter
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!
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'.
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.
Stuart.
On Tuesday, March 12, 2002, at 06:41 pm, Vadim Gritsenko wrote:
>> From: Stuart Roebuck [mailto:stuart.roebuck@adolos.co.uk]
>>
>> What is the xconf tool?
>
> From build.xml:
> ---------
> <!-- A task to change the xconf. It is used to add optional
> components -->
> <taskdef name="xconf-tool" classname="XConfToolTask"
> classpath="${tools.dir}/anttasks"/>
>
> <!-- Invoke the XConfTool to add optional entries -->
> <xconf-tool directory="${build.src}"
> extension="xmap"
> configuration="${build.war}/sitemap.xmap"/>
>
> <xconf-tool directory="${build.src}"
> extension="xpipe"
> configuration="${build.war}/sitemap.xmap"/>
>
> <xconf-tool directory="${build.src}"
> extension="xconf"
> configuration="${build.war}/cocoon.xconf"/>
> ---------
>
> From pizza.xconf:
> ---------
> <?xml version="1.0"?>
>
> <xconf xpath="cocoon/programming-languages/java-language"
> unless="parameter[@name='compiler']">
> <!-- Compiler parameter specifies which class to use to compile
> Java.
> Possible variants are:
> Javac. Requires javac.jar (included with JDK as
> lib/toools.jar).
> Pizza. Requires pizza.jar (included with Cocoon
> distribution).
> Jikes. Requires IBM jikes compiler to be present in the
> PATH -->
> <parameter name="compiler"
> value="org.apache.cocoon.components.language.programming.java.Pizza"/>
> </xconf>
> ---------
>
> 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 stuart.roebuck@adolos.com
Systems Architect Java, XML, MacOS X, XP,
etc.
ADOLOS <http://www.adolos.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: WHATSNEW file - was: Re: Missing cocoon.xconf compiler parameter
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Stuart Roebuck" <st...@mac.com>
> 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! ;)
:-)
I'm cross-posting this to forrest-dev because we are deciding right now on
this point.
I would suggest you to subscribe there, so you can follow the discussion.
We need many different point of view, and I see you have valuable
argumentations.
Come on guys, get on Forrest and help build the new xml.apache site with
Cocoon! :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: WHATSNEW file - was: Re: Missing cocoon.xconf compiler parameter
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Stuart Roebuck" <st...@mac.com>
> 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! ;)
:-)
I'm cross-posting this to forrest-dev because we are deciding right now on
this point.
I would suggest you to subscribe there, so you can follow the discussion.
We need many different point of view, and I see you have valuable
argumentations.
Come on guys, get on Forrest and help build the new xml.apache site with
Cocoon! :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: WHATSNEW file - was: Re: Missing cocoon.xconf compiler parameter
Posted by Stuart Roebuck <st...@mac.com>.
On Tuesday, March 12, 2002, at 08:27 pm, Vadim Gritsenko wrote:
>> From: Stuart Roebuck (Telewest) [mailto:stuartroebuck@mac.com]
>>
>> 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 stuart.roebuck@adolos.com
Systems Architect Java, XML, MacOS X, XP,
etc.
ADOLOS <http://www.adolos.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: WHATSNEW file - was: Re: Missing cocoon.xconf compiler parameter
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
> Vadim Gritsenko wrote:
>
> <snip>
> Isn't current Cocoon's release notes are constructed from the
> changes.xml?
>
Yes.
Some weeks ago we had this discussion about adding attributes to the
changes.xml to indicate which change is worth mentioning in a "what's
new section." AFAIK this decision was delayed until forrest is usable.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: WHATSNEW file - was: Re: Missing cocoon.xconf compiler parameter
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Stuart Roebuck (Telewest) [mailto:stuartroebuck@mac.com]
>
> 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
:)
> 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)
> 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
> Stuart.
>
> On Tuesday, March 12, 2002, at 06:41 pm, Vadim Gritsenko wrote:
>
> >> From: Stuart Roebuck [mailto:stuart.roebuck@adolos.co.uk]
> >>
> >> What is the xconf tool?
> >
> > From build.xml:
> > ---------
> > <!-- A task to change the xconf. It is used to add optional
> > components -->
> > <taskdef name="xconf-tool" classname="XConfToolTask"
> > classpath="${tools.dir}/anttasks"/>
> >
> > <!-- Invoke the XConfTool to add optional entries -->
> > <xconf-tool directory="${build.src}"
> > extension="xmap"
> > configuration="${build.war}/sitemap.xmap"/>
> >
> > <xconf-tool directory="${build.src}"
> > extension="xpipe"
> > configuration="${build.war}/sitemap.xmap"/>
> >
> > <xconf-tool directory="${build.src}"
> > extension="xconf"
> > configuration="${build.war}/cocoon.xconf"/>
> > ---------
> >
> > From pizza.xconf:
> > ---------
> > <?xml version="1.0"?>
> >
> > <xconf xpath="cocoon/programming-languages/java-language"
> > unless="parameter[@name='compiler']">
> > <!-- Compiler parameter specifies which class to use to
compile
> > Java.
> > Possible variants are:
> > Javac. Requires javac.jar (included with JDK as
> > lib/toools.jar).
> > Pizza. Requires pizza.jar (included with Cocoon
> > distribution).
> > Jikes. Requires IBM jikes compiler to be present in the
> > PATH -->
> > <parameter name="compiler"
> >
value="org.apache.cocoon.components.language.programming.java.Pizza"/>
> > </xconf>
> > ---------
> >
> > 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
stuart.roebuck@adolos.com
> Systems Architect Java, XML, MacOS X, XP,
> etc.
> ADOLOS
<http://www.adolos.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org