On Tue, 4 Dec 2001 [EMAIL PROTECTED] wrote: Firstly, I'll only reply briefly, as I think Ara will have a bit to say here, and he's been driving things, so probably more appropriate for his input...
> 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 as Ara will say... there's a difference between "smart defaults" and "optional subtasks". The smart defaults are that (for example, as I've suggested) your entity beans will get/set Data methods, if you have the dataobject subtask defined. You can of course override this default by putting the appropriate tag in your bean. If otoh, you dont have dataobject defined, then set/get data are off by default. in that case, you can explicity turn it on, but putting the appropriate comment in your bean. I think I've pretty well captured what Ara's trying been saying there... but that'll be confirmed in a while when Ara responds I guess (o: on the other side of the coin... you would prefer that it was off by default, and that people who wanted it had to put something in every bean, then that kinda makes a lot more work for everyone else... hence the smart defaults :) I'm more than willing to hear options/arguments here... and acknowledge that it does make obvious the bind between subtask and task, but the bind is already there, just hidden a bit... does that make sense? cheesr dim _______________________________________________ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
