On Tuesday, December 4, 2001, at 04:59 PM, Andrew Stevens wrote:
> A wise old hermit known only as Ben Johnson <[EMAIL PROTECTED]> > once > said: > >> But >> I'd really like to see data objects turned off by default. >> xdoclet.ejb.tags.DataObjectTagsHandler, around line 200 > > Why not just omit the <dataobject> subtask? I was going to feel real silly if your suggestion worked, because it almost makes too much sense. :) I took out the subtask and things broke. Since it sounds like Dmitri is close to checking in optional subtasks, I'll save the specific reproduction for another email (if it's still needed) and instead wax philosophical. I think using ant subtask presence for configuration choices is a *really* bad idea. That is, as Dmitri hints at using isSubTaskDefined for decisions about template output, it flies in the face of the design of both ant and xdoclet. First, the way I see ant, it's a build manager with powerful features that enable developers to automate tasks in efficient ways that suit their needs. Everything is disconnected, and ant writers join things together through "depends" attributes and antcall nodes. 2 people should be able to write completely different collections of ant targets in build.xml and still end up with the same result. Next, the beauty of xdoclet is that in combines all your configuration into one place. There's no longer the danger of your deploy descriptors getting out of sync with bean names. One Bean.java file can drive the whole thing. The danger in adding or omitting specific subtasks in the ejbdoclet ant task is that now the design of your application depends on this secondary configuration file called build.xml. It breaks the one file beauty of xdoclet. The ant design should allow a person to specify two different ejbdoclet tasks, one that generates all the .java as a precursor to compilation, and another that generates ejb-jar.xml as a precursor to jarring. (This is perhaps a contrived example, since both ejbdoclet tasks are based on javadoc and inherently expensive to execute, making it logical to combine them into one task.) Optional subtasks are still important, imo, since they support the ant incremental build philosophy. But enabling optional features such as data-objects should definitely be driven by the .java, not build.xml just my $.02. thanks for listening. -benJ _______________________________________________ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
