cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: Ant task using CocoonBean (was Re: New CLI, twice as fast :)
Date Fri, 25 Jul 2003 13:39:30 GMT

Upayavira wrote:
> On Fri, 25 Jul 2003 14:01:48 +0200, "Marc Portier" <>
> said:
> <snip/> 
>>well, the current two ways I envisioned for the ant-task to know 
>>about the xconf are as follows:
>><cocoonBean in="location-of-xconf" />
>>   <xml-conf>
>>    ${ant-props} SUBSTITUTION
>>   </xml-conf>
> Definitely the latter would be best.

the first is the easier, and both can coexist nicely in your task 
implementation (I think it just makes sense for people having an 
xconf file already, and as explained it could simulate the second 
approach by using the echo/@file trick)

<big-snip about="everything is in the xconf, yeah!" />

I read some on the wiki page now, and start to see more of the 
light even

> So, let me know how to access the contents of a task node as a DOM node,
> and you'll (in time) get your Ant task.
> How's that for a deal?

I proposed to get into the first approach because this is exactly 
where I need some time to think ;-)

but putting some effort in now: (rough cut thoughts below)

approach 1/ similar hack from the echo task:

anything that is inside your ant-task as free text will be 
reported to you by void addText(String theNestedText)

(possibly called multiple times based on the underlaying SAX 
characters() event I guess... plus, you should make sure the 
ant-properties get replaced)

so easiest is to go for stealing what the echo-task is doing:

      * Set a multiline message.
     public void addText(String msg) {
         message += getProject().replaceProperties(msg);

check the full code here:

catch: for ant to ignore the nested XML of your 'text' you will 
need to declare the <![CDATA[ ...  ]]> around the nested xconf stuff

after these addText calls your task will have a String containing 
the text (with all properties substituted)

wrap it up in a StringBufferInputStream and hand it over to a 
DOMParser to get your DOMTree

pass that to the processXConf and let your magic do its job...

approach 2/ reusable nested-xml-conf datatype

please let me think some more...

I hope in the mean time the <![CDATA[ hack is an acceptable 
solution... this becomes the ant end-result:

<cocoon verbose="true"
    <broken-links type="xml"



maybe you now see why I didn't like the ant-task-element to be 
called 'cocoon', but that is really matter of cosmetics
(and of declaring it properly with the <taskdef>)

> Regards, Upayavira

Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                        

View raw message