[Moving from Forrest-dev to cocoon-dev, a discussion between myself, Marc Portier with input from Nicola Ken]
Marc, > Nicola just dropped the link in the thread > http://ant.apache.org/manual/develop.html 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 SimpleOutputStreamBeanListener. > > 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?) Yup. > 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 Main.java 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
