cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Upayavira">
Subject Ant task using CocoonBean (was Re: New CLI, twice as fast :)
Date Fri, 25 Jul 2003 10:41:40 GMT
[Moving from Forrest-dev to cocoon-dev, a discussion between myself, Marc
Portier with input from Nicola Ken]


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

Yup, doesn't look too hard.
> > 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?

It is much like the Ant listeners, the way that the bean reports back to
the caller, e.g. saying that a page has been successfully generated.

> also something that could be factored out/reused by the ant task?

Possibly. I've got a CLIListener. We could replace it with a

> >         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 
> data)

It wouldn't be hard. But why would you want to do this? Can you explain?

> > 
> >         cocoon.addTargets(line.getArgList(), destDir);
> > 
> line is holding the command-line I presume?

Yes. So line.getArgList() is simply a list of requested Cocoon URIs.

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

If I understand what you're saying here - I'd reuse the xconf code, but
would ignore the command-line parameters, so actually I wouldn't use this
cocoon.addTargets() method like this.

> 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

Definitely. It is just a question of finding a common way to interpret
XML configuration, as uses DOM, whilst Ant uses its own methods
(and Cocoon uses Configure objects...)
> 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)

I would by far prefer to do it that way if we can find a way.
> 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)

That'd be great. At the moment, the xconf is a CLI xconf. Someone said
that it shouldn't be a part of the bean itself. But we can make it a
helper class, or a factory, that takes in configuration options and
returns a configured bean.

> >         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

It is already specified in the cli.xconf, so it could be specified in the
ant task. 

> > 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 :-)

Fair enough.
> > 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="..">
>    <xml-config>
>      <cocoon>... xconf inline / abusing ${ant-props} ...</cocoon>
>    </xml-config>
> </cocoon-bean>
> 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?

I think that that is the biggie. I can't see now how to share the xconf
code. If we can work that out, I could knock up the ant task pretty
quickly (especially if you're prepared to test it!).
> >>> - 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)

Exactly. As is currently the case!

Regards, Upayavira

View raw message