XDoclet integrates well with an
Ant based build system. If you are using an IDE that doesn't support Ant, then you are out of luck. (I'd recommend moving to one that does
If you are using an IDE proprietary build function instead of using the IDEs support for Ant, I recommend moving to Ant. There's no reason to use a proprietary build system anymore.
Assuming we you are in an Ant build, I think using XDoclet is better than using a vendor proprietary task to generate deployment descriptors. Without knowing JBuilder, I can't really compare. But the portability and IDE independence of XDoclet is enough for me. And, knowing the power of XDoclet, I'd have a hard time imagining JBuilder does a better job.
I've helped several projects move to XDoclet and it's not hard at all if you take it one step at a time. In the book, we recommend migrate one layer at a time. Start with the
EJB tier first, perhaps, and move just one session bean. Then move all the session beans. Then movie the entity beans. Etc... When you have a the entire tier moved, do the same thing with the web tier. Or your JMX MBeans. Or...
If you take it one tier at a time, you'll understand better what each XDoclet task is doing. The mixed development will give you some exposure to merge points and some of the finer points of generation. It's also easier to isolate changes when you move on tier at a time.
I'm working on a project now that was originally BMP entity beans and session beans. In introducing XDoclet into the project, I didn't change anything at first. My first task was actually to generate some new CMP beans. Once XDoclet was "proven", we began migrating the older BMP beans one by one. We got rid of the old DAO framework and all the hand coded value objects. It was a huge win. Right now everything on the EJB tier is generated
by XDoclet except one BMP bean and a couple of DAOs used directly by the session beans. We've also added some XDoclet generation for the JMX components and generation of the web.xml files for each of the web applications that use the framework.
It was a slow process, but everyone on the team is confident in XDoclet because we didn't break everything by changing it all at once. When we encountered difficulties, we could deal with them in the context of a small change rather than having to sift through an big broken project.
On the second point, XDoclet is very extensible. You can usually get XDoclet to generate what you want with little more than a merge point. As always, store your generated code in a temporary build directory. Don't mix it with your hand written code or check it in to your revision control system. Treat the generated code like you would a .class file. It is a byproduct of the build. You can inspect it to understand it better, but you wouldn't edit
it any sooner than you would edit your generated javadocs or .class files...
