aspose file tools*
The moose likes Other Java Products and Servers and the fly likes To authors Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Products » Other Java Products and Servers
Bookmark "To authors" Watch "To authors" New topic
Author

To authors

Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Hello authors
1. What motivated you to write the book?
2. How is your book different from other book available in the market?
3. What is the future of XDoclet?
4. What are changes/additions/modification you would like to be done on Xdoclet.
Thanks


Groovy
Craig Walls
author
Ranch Hand

Joined: Sep 19, 2003
Posts: 301

The answer to questions 1 and 2 are pretty much the same. When we first started using XDoclet, we looked around for good learning material on XDoclet. We searched the internet, magazines, and books. Unfortunately, we came up lacking. At the time, the only book that covered XDoclet was Erik Hatcher's "Java Development with Ant". It was good, but it covered an older version of XDoclet and XDoclet wasn't the focus of the book. Magazines and the internet were not helpful, either. Articles on XDoclet were few and the only material we found on the internet (even on XDoclet's own site) was slim and very often wrong. We kept saying to ourselves: "I sure wish that there was a book on this."


That question quickly led us to write the book. Since we first started, several other books have come out that have some coverage on XDoclet. I've read through most of them and they're good. But again, the focus of those other books isn't given solely to XDoclet. Our book, on the other hand, is dedicated to XDoclet, covers all of the main modules of v1.2, and has the most complete and most accurate reference on XDoclet tasks, subtasks, tags, and XDt template tags.


As for the future of XDoclet: This question is often asked in two different contexts: XDoclet vs. JSR-175 and XDoclet 1.2 vs. XDoclet 2.


Starting with XDoclet vs. JSR-175, let me make it clear that XDoclet is a code generation framework whereas JSR-175 is a runtime metadata facility of the Java language. Put another way, XDoclet is a build-time code generation engine, but JSR-175 is a run-time mechanism for accessing meta-data (keyword: reflection). These are two completely different animals, even though they may appear similar (much the same way a zebra resembles a horse). I'll concede that many of the problems that XDoclet addresses could also be addressed (or completely eliminated) by JSR-175, but there will always be a need for code generation, even if the deployment descriptor goes away. Just think about any redundant boiler-plate code you may write and you'll find XDoclet a better solution than JSR-175 in most cases.


Now, XDoclet 1.2 vs XDoclet 2. It's true that as I write this the XDoclet team is busy hammering out the next generation of XDoclet. XDoclet 2 is a total do-over of XDoclet and is very different from XDoclet 1.2. I'm really excited about XDoclet 2 because it addresses many of XDoclet 1.2's shortcomings (such as being limited to JavaDoc comments as a source of metadata). I'll try to write up my thoughts on how XDoclet 2 differs from XDoclet 1.2 in another post later today, but for now let me say that XDoclet 2 is still quite far off in the future. The core of XDoclet 2 is fairly stable, but there are only a handful of plugins available. It may be sometime yet before XDoclet 2 is usable (unless you want to write your own plugins). I predict we'll still be relying on XDoclet 1.2 for at least another year, if not longer.


As for what I'd like to see changed in XDoclet: Well, I'm a committer to the project, so if I'd like to see it changed then I just change it, right? But, truthfully, the things I don't like about XDoclet are being changed in XDoclet 2. I'll talk about that in a later post.

Spring in Action - Unleash POJO power in your applications!
Modular Java - Discover the secret weapon to modularity on the Java platform!
XDoclet in Action - Your complete guide to code generation with XDoclet.
Mcgill Smith
Ranch Hand

Joined: Nov 11, 2003
Posts: 178
Quote : Craig Walls
XDoclet 2 is a total do-over of XDoclet and is very different from XDoclet 1.2
----------------------------------------------------

How much,learning Xdoclet 1.2 going to help when Xdoclet 2.0 comes out.
Thanks in advance.


Regards
Mcgill
Juan Rolando Prieur-Reza
Ranch Hand

Joined: Jun 20, 2003
Posts: 236
Originally posted by Craig Walls:
...limited to JavaDoc comments as a source of metadata...

I wonder how much clutter is added to java source code when we add enough XDoclet code to generate deployment descriptors, value objects, etc. ?
It seems to me that there was a good reason for deployment descriptors to exist as separate files (and as a separate language). Not the least of which is to keep the java code clean, and not dwindle into obscurity among the meta stuff.
Another issue...
Looking at this example of XDoclet...
This seems to highlight the other reason for keeping deployment data separate from the code. Specifically, the decision of whether a transaction should be Required or Supported or Mandatory cannot rest solely with the developer. It must be modifiable by the downstream processes of assembly and deployment. Many such choices are allowed to be made by people other than the developer, such as roles. But if those choices are now "hard coded" as XDoclet attributes in the java source code, the choice is complicated; it would require work-arounds to the generated code and remember to re-edit after generations. This is a most unpleasant coupling.
How do the XDoclet experts address this concern?
Thanks


Juan Rolando Prieur-Reza, M.S., LSSBB, SCEA, SCBCD, SCWCD, SCJP/1.6, IBM OOAD, SCSA
Craig Walls
author
Ranch Hand

Joined: Sep 19, 2003
Posts: 301

True, if you hardcode your metadata in the doclet tags, then you are coupling deployment data with application code. I won't argue with you on that.


For some things, that is okay. I've got some deployment info in my code that has never changed and likely will never change, so no harm done in hardcoding it in my XDoclet tags.


But for things that might change, you have a few options: First, just don't use XDoclet. That may sound like a strange solution coming from an XDoclet advocate, but the fact is that it isn't a silver bullet and if you don't like it, then don't use it.


Another option is to take advantage of XDoclet merge points. Let XDoclet generate as much as it can for you and merge in the stuff you are uncomfortable with tagging.


Probably the best option is to use Ant properties in your tagging. So, instead of hardcoding type="RequiresNew", try type="${transaction.type}" and then set the ${transaction.type} property in your Ant build properties file. This way you can swap out the actual property value at build time.
Craig Walls
author
Ranch Hand

Joined: Sep 19, 2003
Posts: 301
Originally posted by Mcgill smith:
Quote : Craig Walls
XDoclet 2 is a total do-over of XDoclet and is very different from XDoclet 1.2
----------------------------------------------------

How much,learning Xdoclet 1.2 going to help when Xdoclet 2.0 comes out.
Thanks in advance.

It depends. With any luck, not much will change. Your Ant or Maven build file will certainly change, but the tagging may not change at all. It really depends on how well the XDoclet 2 plugin writers preserve backward compatibility. So far, there aren't that many XDoclet 2 plugins, but the ones that do exist preserve backward compatibility fairly well, so maybe you won't need to change much.

The question is: Will learning and using XDoclet 1.2 help you on your projects now? If so, then don't wait for XDoclet 2. Go ahead and reap the rewards of code generation today. When XDoclet 2 comes along, the transition should be fairly smooth.
Juan Rolando Prieur-Reza
Ranch Hand

Joined: Jun 20, 2003
Posts: 236
Thanks, Craig, this sounds great. (Don't get me wrong I don't dislike anything I'm hearing about XDoclet - I'm just probing.)
norman richards
Author
Ranch Hand

Joined: Jul 21, 2003
Posts: 367
I'll add something here on whether or not you should put deployment information in your source files. Of course, as craig has shown, you can derive some of this stuff from more dynamic sources like ant properties. But keep in mind that just because you generate the deployment descriptor one way for development or for handing over to the deployment team doesn't mean that the deployment descriptor is fixed. If you have truly have a split model where development and deployment are separate activities this makes perfect sense. But, you need to have SOMETHING there for the deployers to fill in, and XDoclet can generate that for you. (the "full" J2EE model actually has several stages of different roles incrementally adding to or modifying the final deployment information)
Related to this, I'll point out that in the EJB space XDoclet provides a lot of value from simplifying the full J2EE development model. People forget that J2EE is complex for a reason. It supports extreme component based enterprise development processes. Not everyone needs that level of complexity, so tools like XDoclet can step in and take some of that burden away. If you need some of the J2EE complexity for your process, then you can roll XDoclet back a bit and expose more of the J2EE dev process. XDoclet is extremely flexible in letting you work the way you want to work on your project.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: To authors