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. However, even with a simpler architecture and a simpler way to implement/fix/understand plugins and XDoclet in general, we'll probably still have to face the problem that there is more code to maintain than we can cope with. 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 know this is a bold mission. Ant has tried it and failed. Maven has tried it and failed. Still, I believe that if the XDoclet communicates this mission clearly enough, and at the same time makes plugin development ultra easy, we can achieve this mission. We're putting a lot of effort into the documentation of XDoclet 2. The way XDoclet is now, it's like a dinosaur. The dinos died because their brain was too little to handle the huge body. Now is the time to make XDoclet evolve into something more darwinistic. Something that has a fair chance of surviving and keeping fit. It doesn't need a bigger brain (more developers), but it needs serious fat sucking (less code/plugins to maintain). If we can achieve this goal, we have a bigger chance to achieve better over-all quality. We'll be able to distribute the work more evenly, and people can concentrate on specific parts. I for example will concentrate on the XDoclet core and *maybe* some plugins somewhere else. People interested in for example JBoss (and therefore various JBoss XDoclet plugins) will concentrate only on the JBoss plugins. This will hopefully be done by some the JBoss developers. I doubt BEA will maintain plugins for XDoclet, so WebLogic plugins should be maintained in a separate project hosted somewhere else than XDoclet. xdoclet-bea.sf.net perhaps? A nice possible side-effect of this "outsourcing" is that it would be easier for people to know where to ask questions. We get a lot of questions a la "I got this yikes error from JBoss. Please Help!" on this list that aren't really related to XDoclet. If people use JBoss with the JBoss XDoclet plugins and experience problems, they have one place where they can ask, whether it's related to the JBoss XDoclet plugin or JBoss (often users don't know): Namely the JBoss forums. There is a bigger chance that more people will be able to answer. IMO there is too much different things being discussed here, and the noise/signal ratio is pretty high for everybody, since noone uses all XDoclet modules/plugins. > > 2) It simplifies the build process. (It's already too complicated). > > I'm sure that if it all becomes one codebase, it'd certainly be quite > easy to have a not so complex build process. It's not an impossible > task anyway. > See above essay. > > 3) It avoids dealing with one potentially very big jar. Well, 2 MB > > isn't > > actually gigantesque, but it's big. > > > Sure, except that it's starting to feel like jakarta commons, where > they're all one big incestuous family and if you want to use any of the > newer commons jars, you have to bring in 4 other jars. It's hugely > irritating. The equivalent in xdoclet is that to use jboss module, you > have to have web module (even if you don't use any web features), and > jmx. If you want to use weblogic (again, no web stuff), you need web > module. The modular approach works if there are no cross-module > dependencies. As things stand, if someone wants to deploy ejbs to > jboss, they need 6 jars (xjavadoc, xdoclet, jboss, jmx, web, and ejb), > which to me doesn't feel very modular. > In XDoclet 2 we're planning on fragmenting the plugins by artifact (or at least encouraging people to do so), and not by vendor as it is now. This means there will be one plugin for e.g. jboss.xml and one for jboss-web.xml. They will depend respectively on the ejb and web plugins that we maintain in the XDoclet codebase, but not both. No more spahetti dependencies if you will, it will be a true tree dependency graph. There will be many plugin jars, but you'll probably only need a few of them. It would be great to hear what you (the users) think of all this. To those of you who dissent with the above mission: How do we cope with the dinosaur syndrome? (We have 126 open issues in JIRA today, and it ain't decreasing). 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
