Very good call. I can't really judge if Aslak's plan for XDoclet2 will work, but can imagine that it would be like this:
The Core XDoclet guys like Aslak, Ara, Marcus etc. could concentrate on the core XDoclet stuff, do it well (incl. docs), and keep up with feature requests and bug fixing. So the XDoclet foundation stuff, could evolve fast and provide a strong foundation for modules/plugins to build on. Other developers that are interested in using specific plugins (be it for an appserver, an O/R mapper or whatever) could concentrate on those. Maybe or possibly the total number of modules/plugins available would decrease over time, as only those plugins would be maintained or kept available which really are in hot demand: "survival of the fittest" - biological rules applied to software ;) Considering this, it's foreseeable that the majority of the "important" plugins (for example for JBoss) will continue to live and prosper (for JBoss4 the JBoss folks are planning close XDoclet integration, I believe), while others - possibly for Pramati or Sybase to name a few - might die. But that wouldn't be so bad, since as it is now - as Aslak said - there are a lot of modules now that have no active maintainers. And what worth are modules/plugins that are not up-to-date with the products (like appservers) they're meant to be used for, anyways. Some thoughts why I said the above... When we started using XDoclet in a project, it was the post XDoclet 1.1.2 and pre XDoclet 1.2 beta era, we started off using a CVS version of XDoclet 1.2. Since our project requirements are very special in some cases, we had to do a lot of customization. Using merge points and the like was not enough so decided it was the easiest way for us to define our own templates for the XDoclet tasks we use by altering the original versions from XDoclet and also extending/writing some tag handlers. This all works really well and is nice in a way. Of course it would have been nicer, though, if using a cleaner template language (such as Velocity) would be supported. Now the templates are kind of a maintenance nightmare where only me and possibly another person on the team can totally understand what's going on there. We tried upgrading to an XDoclet 1.2 beta version but failed, since apparently some taghandler code has changed too much from the CVS version we use and isn't compatible with our extensions anymore. I assume it will be close to impossible to upgrade to XDoclet2 without major rewrites our templates and such. BTW a question for the core XDoclet guys: Are you planning a migration path/program/tool etc. for migrating projects based on the XDoclet 1.2 standard stuff/templates to XDoclet2? Greets, Bernie -----Urspr�ngliche Nachricht----- Von: Aslak Hellesoy [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 12. Februar 2003 13:05 An: [EMAIL PROTECTED] Betreff: [Xdoclet-user] New Misssion [Was: Packaging XDoclet in One Jar?] This is a rather important mail about dinosaurs, so please read it carefully and send your feedback. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Hani > Suleiman > Sent: 12. februar 2003 02:07 > To: [EMAIL PROTECTED] > Subject: Re: [Xdoclet-user] Packaging XDoclet in One Jar? > > > Just to play the devil's advocate... > > On Tuesday, February 11, 2003, at 07:35 PM, Aslak Hellesoy wrote: > > > 1) It makes it easier for us to encourage people to build and maintain > > plugins outside the XDoclet codebase. > > Does this exist anywhere? As far as I know all plugins are in the > xdoclet codebase. > They're all in XDoclet's codebase today, which is a problem. -Not from a technical point of view, but from a maintenance point of view. The XDoclet team is facing severe challenges when it comes to maintaining all the modules. There are 17 committers on XDoclet, but a large majority of them only do occasional work. That's normal. People lose interest, move on to other projects, etc. Today, there are a lot of modules that don't have any active maintainers anymore. Very few users seem to be able to fix bugs themselves and upload patches, and the number of bugs, questions and feature requests increases faster than we're able to fix them. See this: http://tinyurl.com/5p4d There are basically two reasons for this lack of contributions from the user community: 1) People are lazy. 2) People don't know how to fix things themselves. While we can't do much about (1), we can do something about (2): Making XDoclet's overall architecture easier to understand, so that more people will be able to submit bugfixes and patches. This is one of the most important goals in XDoclet 2. People will be able to write plugins in velocity, jelly, freemarker, webmacro and there will be some very neat tool aids to ease the development and packaging of XDoclet 2 plugins. Sort of an XDoclet Plugin Development Kit. ... This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. ------------------------------------------------------- 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
