forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: New CLI, twice as fast :)
Date Fri, 25 Jul 2003 10:00:31 GMT

Upayavira wrote:
> On Fri, 25 Jul 2003 09:23:54 +0200, "Marc Portier" <>
> said:
>>>>wouldn't it make the most sense to have a cocoon-cli ant task 
>>>>directly? (rather then hooking up through the java task?)
>>>Yes it does.
> Definitely.
>>>>writing such custom ant task (and combined datatypes) should not be 
>>>>that difficult and I'ld like to assist. (I also think the cocoon bean 
>>>>could largely benefit)
> If you know how to code Ant tasks, it shouldn't be hard. If you code the
> ant task, I'll try to keep it up to date with any changes to the bean. 

Nicola just dropped the link in the thread is basically all you 
need to get going...

> The interface to the bean is pretty simple. What you would want to do is
> refactor the o.a.c.Main class into an Ant task. Everything you need is
> either in processXConf() or in main(). The main code you'll need is as
> simple as:
>         CLIListener listener = new Main.CLIListener();

what does this listener do?
also something that could be factored out/reused by the ant task?

>         CocoonBean cocoon = new CocoonBean();
>         cocoon.addListener(listener);
>         if (line.hasOption(XCONF_OPT)) {
>             // destDir from command line overrides one in xconf file
>             destDir = Main.processXConf(cocoon,
>             line.getOptionValue(XCONF_OPT), destDir);
>         }

I assume this processXConf is where the xconf file is consumed? 
(i.e. interpreted and used to configure the cocoon-bean?)

for the ant task it would be nice if we could hand over an 
inputstream or stringbuffer that holds the xconf text, would an 
overloaded version of processXConf() be feasible?

(1st argument the bean, 2nd argument an inputstream on the xconf 

>         cocoon.addTargets(line.getArgList(), destDir);

line is holding the command-line I presume?

while this makes perfect sense for cli usage I would not include 
such a overriding arguments/options notion inside the ant-task

in fact since the processXConf is already there to do the 
interpretation of the xconf I see no reason to duplicate the 
effort inside ant-configuration-interpretation

my point is that each feature you add to the xconf (by changing 
bean and processXConf) should automatically be available to the 
ant-task (it should just pass through the xconf, not try to 
understand any of it IMHO)

this will also make sure that people will only need to do one 
thing: understand how to write cocoon-bean xconf (not a different 
knowledge to configure the ant-task)

>         cocoon.initialize();
>         cocoon.process();
>         cocoon.dispose();
>         listener.outputBrokenLinks();

ah, starting to understand why this is for...
this could opt for an additional configuration element on the ant 
task: location where to dump this

> You'd need to implement some method to get the values out of the ant task
> definition (replacing the processXConf() function, and to add your own

I'ld rather reuse a modified version then replace based on my 
above argumentation ?

> BeanListener implementation (simply to decide what to do with output).

got that now I think, again I hope for re-use: if I could 
instantiate such listener and call outputBrokenLinks() with the 
outputstream it needs to send to then your main could call it 
with System.out or whatever as an argument, and we'ld all be 
happy :-)

> If it is possible to share the processXConf() between the CLI and the Ant
> task, then maybe we can factor it out into a CocoonBeanBuilder class.

yes please.

> So, yes, I'd happily help to get this going - especially if someone
> provided me/us with a skeleton for the ant task (which I've never done).

really no big deal,
check the 'Example' on the link mentioned before and you're over 
half way: it should be a snap to do something like
<cocoon in="path-to-xconf" out="path-to-brokenlinks-output" />
and then abuse the <echo> task as I mentioned previously for the 
time being (given my current workload you'ld probably get into 
this before I do, don't hesitate to ask questions though)

hmpf, I see they are still mentioning the <taskdef> approach.
Nicola, wasn't there going to be a different way to define custom 
tasks or am I completely on the wrong track here?

now, the bigger challenge I see is supporting the inline xml file 
for the configuration (without getting into CDATA sections like 
the echo task is doing)

<cocoon-bean out="..">
     <cocoon>... xconf inline / abusing ${ant-props} ...</cocoon>

in fact I think a lot of potential ant tasks could benefit from 
such a nested-xml-config-ant-datatype since more and more 
existing tools are requiring an XML config and inlining it with 
the ant build makes sense when you wrap it up in an ant task and 
want to use the ant-property-substitution

hm, have to think some more...
other suggestions meanwhile?

>>> - there is an Ant task in the Cocoon scratchpad
>>ah, didn't know... probably not based on the new cocoon-bean 
>>stuff I presume?
> No it doesn't. In some ways the code there is probably better than that
> in the bean, but to my mind it makes sense to create an Ant wrapper to
> the bean and then develop the bean, than to have multiple instances of
> crawlers, etc. (I think there are at least three crawlers in the Cocoon
> CVS. Quite unnecessary).

same vision here (developing new features on the bean should not 
even influence the ant task)

> Regards, Upayavira

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

View raw message