> Therefore I am *proposing* a new mission for XDoclet 2: > > "XDoclet 2 will provide a well-designed, well-tested, small and stable > core > with many options for plugin development. XDoclet 2 will also provide > tools > that can package plugins. (This will be ant scripts AND maven plugins, so > people can use whatever they please). XDoclet 2 will only maintain plugins > for which there is no natural maintainer. (We'll probably maintain the > standard ejb-jar.xml and web.xml plugins, but not vendor-specific plugins > like jboss, weblogic, struts or hibernate). Tool vendors and open source > projects that wish to have XDoclet support for their product are > encouraged > to develop, maintain and distribute their own XDoclet 2 plugins. If the > tool > vendors themselves don't want to or can't do this, we encourage volunteers > to form smaller, independent projects (for example on SourceForge) where > they can maintain specific XDoclet plugins. The XDoclet 2 documentation > will > have links to all known plugins where they can be downloaded separately."
I'm all for it! What really made XDoclet a success among all these code generation tools is not the template language or the modules. The @tags are XDoclet's biggest investment, plus the community. So I think the monopolist approach of xdoclet 1.x has served well actually. It created a huge community around it, made it such a rich tool. Now we've grown and we can't bear more @tags and a more diverse community with more bugs and requests. Yes, we need to split, like MS should split :-) So there should be: - An XDoclet SDK - Some built-in and generally useful modules/tags. These tags should be very well thought and documented like a spec (not that formal actually, but you get the idea, no more hackerish style). - A community site (like intellij.net) preferably a Wiki site where you can advertise new modules, search for them or even download them dynamically like Maven (or the forthcoming Rutor project). The xdoclet2 cvs module can serve as the sdk, an xdoclet2-modules module for all the built-in modules. And I think ejb support shouldn't be in xdoclet2-modules at all! It needs a separate ejb-xdoclet project, you know because of those entire valueobject/blabla dependent subtasks. It needs a community of its own. And I personally do want to only work on the core, plus any plugin I might actually use. Regarding Hani's devil's advocacy about support for different template languages: I find it useful. Not because I hope 50% of modules would use Velocity and 50% Jelly. No, I think it's a good thing because by trying to be template language independent we would have a better design, a more testable one. WebWork is a good example. Rickard made it view independent, he used jsp before and now uses Velocity, though I guess a 90%+ majority use jsp. And that's not even important for WW too, but look how the view independent approach makes testing webwork stuff way easier than testing Struts. A little bit of abstraction is a good thing. That said although I still couldn't find enough time to take an accurate look at what Aslak has done but so far I think it's very well designed and well implemented. We have discussed different strategies for well over a year! Ara. ------------------------------------------------------- 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
