• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

first impressions

 
Ranch Hand
Posts: 237
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
I'm new to XDoclet, except that I've heard of it (like a hundred other tech-things). My first impression is that XDoclet is a Javadoc language extension with associated tools like the javadoc engine.
I would like to see the book, but meanwhile in order to post some meaningful questions (and maybe even answers) I've looked at http://xdoclet.sourceforge.net/ .
With all the generative power that XDoclet offers, my impression is that there would be a problem with it that requires a bit of a learning curve.
It may overlap in functionality with other tools and development steps, especially if you try to introduce it into an established project.
For example, JBuilder has its own ways of helping generate descriptor files and running a make sequence. Other IDEs have their own.
So my first question is, "What are your experiences with integrating XDoclet generation into such development processes?"
Another issue is round-trip engineering. Many nifty automatic generation tools in the past would generate fairly functional code, but the generated code was sloppy or failed to be able to do everything you need. So the developer needed to write changes to the generated code. Before reverse-engineering IDE's that code would then be clobbered upon re-generation of the code, forcing the developer to learn to save changes and re-edit them in.
My second question, therefore, is how does XDoclet deal with the issue I just described?
No matter what, XDoclet seems very promising.
Thank you in advance
[ December 09, 2003: Message edited by: john prieur ]
 
Author
Posts: 367
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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...
 
Juan Rolando Prieur-Reza
Ranch Hand
Posts: 237
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks, this sounds very promising.
By the way JBuilder does talk to Ant (i.e. export). But I like to invoke build steps manually sometimes which works regardless of IDE, and reduce dependency on any one IDE and its supposedly cool libraries.
 
norman richards
Author
Posts: 367
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I haven't seen JBuilder for years. I joined a project about 4 years ago where JBuilder was the preferred dev environment for the 40 person engineering team. They had checked in the JBuilder build project files for developers to share and written some perl scripts to process the project files for the nightly builds. Oh the horror!
They were having problems with the process, so they asked me to convert the system to make (but still sourced from the JBuilder project files) to allow each developer to test the full nightly build project. It was still ugly, but it worked. Eventually we got them to get out of the "one IDE to rule them all" mindset and a few years ago they moved to a Ant build with each developer able to chose the development tools that work best for what they are doing.
I haven't seen JBuilder since, so I wasn't sure what kind of build support it had now.
 
Message for you sir! I think it is a tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic