cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Upayavira">
Subject Re: Ant task using CocoonBean (was Re: New CLI, twice as fast :)
Date Fri, 25 Jul 2003 12:32:14 GMT
On Fri, 25 Jul 2003 14:01:48 +0200, "Marc Portier" <>


> well, the current two ways I envisioned for the ant-task to know 
> about the xconf are as follows:
> 1/
> <cocoonBean in="location-of-xconf" />
> 2/
> <cocoonBean>
>    <xml-conf>
>     ${ant-props} SUBSTITUTION
>    </xml-conf>
> </cocoonBean>

Definitely the latter would be best.

> in the first case the ant-task would know about the
> in the second case the ant-task would probably have a 
> String(Buffer) that holds the nested xconf data
> in both cases the task could present that as a InputStream 
> (FileINputStrea, or StringBufferInputStream) to the processXConf 
> method.
> in fact... typing this reply makes me think that the ant task 
> could very well just have access to the xconf information as an 
> already parsed DOM document in the second case... (as said before 
> this second case is still very vague in my head ATM)

Can you explain how I would get hold of the contents of the <cocoonBean>
element as a DOM document from within the ant task code? That is _all_ I
need to get this working, AFAICS.

(Actually, I'd call the node <cocoon> as the fact that it is a bean is an
implementation fact. The user just wants to run Cocoon.)

> > Yes. So line.getArgList() is simply a list of requested Cocoon URIs.
> > 
> ah, and that is not information that is present in the
> xconf file I persume?

It is present in the xconf, and in a much more sophisticated way. Look at
the cli.xconf file in the root of the Cocoon CVS. It is well commented.
Check specifically the <uris> node.

> >>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.
> I think we're close
> My basic proposition is this: the more we can put into the xconf 
> (without breaking its common sense role) the easier the ant task 
> will adapt to new features (cause it would only need to know 
> about the fact that such file is to be handed over in some way or 
> another)

Yup. Exactly what I have in mind. Just show me the DOM code :-)

> >>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.
> there was some confusion over here as well about this self 
> management, but I consider it a different issue (and I haven't 
> looked enough into it)

I'll make a choice and let people complain.

> >>>        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. 
> well, my point was in fact: do not duplicate a thing that already 
> is specified in the xconf.

No, no! It is already in the xconf, and would therefore already be in the
Ant task!
No work required!

> so if the output-location can be specified in the xconf, then I 
> don't see a reason why the ant-task should try to duplicate that 
> effort
> >>>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.
> >  
> see above: no need for any of this if it can be dumped into the 
> cli.xconf
> (I didn't realize the listener could be aware of specifics buried 
> in the cli.xconf)

Well. At present, the class reads the xconf and configures the
bean or the listener. The ant task would do the same (using shared helper


> sure enough, the forrest community would get their hands on it 
> pretty fast aswell IMHO


> (be sure to get them into the loop again when your getting somewhere)

Will do.

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?

Regards, Upayavira

View raw message