• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

To authors

 
Pradeep bhatt
Ranch Hand
Posts: 8927
Firefox Browser Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Craig Walls
author
Ranch Hand
Posts: 363
8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.
 
Mcgill Smith
Ranch Hand
Posts: 178
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Juan Rolando Prieur-Reza
Ranch Hand
Posts: 237
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Craig Walls
author
Ranch Hand
Posts: 363
8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Posts: 363
8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 237
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 367
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic