I actually like the way it's done now. The reason is that I can have my beans contain all the tags that they could require, from that I can further apply project wide generation rules from the build.xml. For example, my ejb might have view-type="both", but for whatever reason, I want to turn off remote views to check something. Right now it's a matter of removing one line in build.xml, rather than going through every bean (hundreds, in my case!) and changing what is generated.
Quoting Aslak Helles�y <[EMAIL PROTECTED]>: > This is an old topic, but I'd like to revisit it. > > The fact that people have to specify both <localinterface/>, > <localhomeinterface/> AND @ejb.bean view-type="local|both" violates the DRY > (Don't Repeat Yourself) principle. > > Although XDoclet2 is still mostly a fantasy, we should try to simplify this > when we start implementing it. My suggestion is to *REMOVE* all the > subtasks > that generate java classes from XDoclet, and control wether a java class > should be generated or not entirely on the @tag level. > > We'd still need Ant-level subtasks for generation of most XML files (files > that are generated from many classes) because we'd run into contradictions > otherwise (one class might say "do generate", and another "don't > generate"). > In short (and a bit simplified): > > * Generation of various java files: Controlled entirely by @tags > * Generation of various xml files: Controlled entirely by <subtasks/> > > What do you users think? > > Aslak > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Xdoclet-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/xdoclet-user > > ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
