XDoclet is a miserable failure!
There are many people out there, myself included, that use xdoclet on a day to day basis. It certainly is a rather useful tool, and makes EJB development vaguely tolerable. However, I’m starting to think that XDoclet, at the time of writing, is a horrific trainwreck with many wounded and dying lying around.
Of course, it depends on what scales one measures success. In terms of adoption, xdoclet certainly wins out. There are thousands of users. However, the picture is a little bit less rosy if we consider pretty much any other scale.
For example, the mailing list (user) is fairly stagnant. A few questions a day, with developers on the whole going to great lengths to remain as silent and invisible as possible. Of the 26 developers, maybe 2 or 3 can be considered remotely active and contribute in a meaningful manner.
This problem is highlighted amply in the jira issue tracker for xdoclet. There are 255 outstanding issues. A bunch of these haven’t been assigned to anyone because nobody wants to touch them. Many are plain unfixable, as the person who wrote the code has gone onto bigger and better things and the codebase is such a horrific mess that it is no longer humanly possible to make sense of it.
The issue of developer exodus is a pretty big one in the xdoclet world. A trigger happy commit access granting policy resulted in a ton of developers, with almost none pulling their weight. The usual case is that developer X gets commit rights, developer jumps up and down and is happy and commits stuff for the next week, developer X gets bored and wanders off to pick their nose or get commit rights elsewhere.
Then there’s the issue of releases. After months of struggling with an astoundingly bad codebase, the xdoclet team finally managed to fart out a couple of beta vesions. Beta 3 came out somewhat screwy and wasn’t usable out of the box, so another halfhearted attempt was made and b3 was released, this time with missing dependencies included. That was back in June. The developers are now bored to death of this codebase, and in true open source spirit, have decided that all energy is best spent on xdoclet2, which will be cooler and more fun all round. On the plus side this is a completely clean break from the current codebase, so none of its filth will go forward. However, I bet some of the guys responsible for much of the stupidity will still be adding their brand of genius to xdoclet2 in time (if they haven’t already). On the downside, all the hard work and effort that people have put into various modules for xdoclet is down the toilet. I suspect 1.2 will never get to be a final release, and the majority of those bugs will never get fixed.
In my mind, xdoclet will always be a textbook case of what happens when developers work in an environment utterly divorced from reality, where they get to do all the dumb things they want to do in the name of coolness and nifty features. The complex and enormous subsystem for i18n support for ant build messages is a timeless classic, and the xjavadoc tool is now going to be ditched apparently for QDox (which already existed back then). Still, I’m sure glad that the developers don’t feel about bad all those endless wasted hours working on something essentially useless that’ll just be thrown away in a few months, and serve no meaningful purpose in the meantime.
Ah well, you get what you paid for, you dumb bastards!
September 22nd, 2003 at 10:51 am
“Ah well, you get what you paid for, you dumb bastards!”
I guess you are right, Hani. I will go shell out a million for a TIBCO integration solution.
September 22nd, 2003 at 11:05 am
I cannot strongly deny being a dumb bastard, for lack of evidence to the contrary. However, XDoclet has mostly worked like a champ for me. Poking around the XDoclet lists will reveal some unanswered requests for help from yours truly, but I figured out most of them for myself, the hard way.
As for XDoclet2, as I understand it, it purports to create a more generic framework so that app server vendors etc. can better write their own modules. While not supporting the current product with the new one not even the horizon is a bit dubious, refactoring to “allow” other people to do the work instead of you strikes me as a “clever bastard” sort of thing to do, no ?
September 22nd, 2003 at 1:26 pm
Hani, since you’ve posted something which can vaguely be interpreted as an anti-open source comment, could you please make us a favor and tell us how many Baueristic posts you’ve deleted? … PLEASEEE?
September 22nd, 2003 at 2:14 pm
Aren’t YOU a committer on XDoclet Hani?
September 22nd, 2003 at 4:44 pm
To be honest, Hani has a point here (but I wouldn’t call it a failure). The current state of XDoclet 1.2 is horrible. All the I18N stuff, the complex build process, the countless unresolved and unassigned JIRA issues which keep coming in, a lack of active developers (myself included), and the problem of having too many, badly supported modules.
Some developers already started looking into the new architecture proposed by Aslak, and while it provides a nice way of solving many issues with the current XDoclet, I think that the main reason people are not jumping as fast as we would all like is because the new architecture doesn’t provide any real advantage. Generated code/xml stays generated code/xml.
The next few months will tell.
September 22nd, 2003 at 11:50 pm
Hani has a point here. The maintenance of 1.2 has been going along sluggish. Some of the issues I have opened > 1 month ago have been collecing dust with nobody bothering to assign them.
With developers concentrating on XD2, XD1.x it looks like is becoming seemingly unpopular. This is dangerous, especially while:
1) all the plugins are currently only available for XD1, making XD2 nothing more than a shadow of it’s predecessor.
2) Books and references to XDoclet mostly pointing to the 1.x versions.
If this continues like that, the current working versions will become less and less used, while the new one isn’t a) ready and b) compatible.
Our inhouse projects, depending on XDoclet are running on private builds as of July 03.
My $.02
September 24th, 2003 at 2:22 pm
“and makes EJB development vaguely tolerable”
I hope you get scared by a freaked out cow stomping into your apartment and thereby make you involuntarily smash your keyboard on your forehead for that comment.
There are like zillions tools for rapid generation of boring EJB code out there, all with the purpose of revealing you of the agonizing pain of writing your own superclasses to handle the boring tasks of EJB development, you lazy bum! May ascii goatse haunt your dreams! EJB development is fast, reliable and veeeeery tolerable compared to the alternatives!
September 29th, 2003 at 11:45 am
Yes, this latest version of XDoclet is pretty bad. But, my big gripe with XDoclet is the seemingly useless documentation. The process goes something like this: Add a new tag to your source, run ant, and see which configuration file changed to include your new tag, and verify that it is in the right format. This can be tedious if you run something like JBoss that has 4 or 5 config files, some that override others… talk about pulling your hair out.