Raible Designs

« Struts Consultants | Main | Struts Roadmap »

Wednesday November 27, 2002

Using XDoclet on Large Projects Kurt emerges from his sabbatical (12 days is a long time in blogsphere) and mentions a little tidbit I'd like to comment on:

Last week I attending a TC JUG meeting where the topic was Struts 1.1: The Good, the Bad and the Ugly.
...
Interestingly the speaker didn't like XDoclet because he felt that on large development teams the config files should be managed outside of the source code during the design phase. Since I have never worked on a large team (not that I won't want to) I don't know if his concern is valid. Interesting comment though.

(I added the bold.) First of all, I have only recently (last 6 months) found XDoclet, and all the projects I've been on (in my entire life) have always had less than 5 coders. I've been on teams as large as 20, but the module I was working on never involved everyone. In my experience, the design phase never really consists of writing very much code or configuration, but rather a bunch of UML diagrams and static HTML prototypes.

I have found (in my brief work on struts-xdoclet) that I need to change values in my web.xml to test different settings (i.e. a servlet's init-param). However, since I'm coding some of these values in my classes, in order to change and test, I have to re-compile and deploy. Of course, I could just change the values in web.xml after I've deployed, but that's just a workaround.

A better solution, which I hope to implement, is to put certain values in my classes as tokens (i.e. @encrypt-password@) and then I can use Ant's replace task to specify this value from the command line. That way, I can set the default in my build.xml file and change it by either 1) specifying the property in build.properties, or 2) specifying it from the command line (i.e. ant -Dencrypt-password=true).

I'd be very interested in hearing anyone's war stories on this topic (managing config files in a large team). Posted in Java at Nov 27 2002, 12:31:26 PM MST 2 Comments

Comments:

There are two things I really like about XDoclet: 1. when you change the name of a class, or method that is automatically picked up in the next build - No duplication. 2. I dont have to edit something that is to do with my action (for example) anywhere other than in the action. Whilst I can see why in production you want deployment descriptors (after all, XDoclet effectively hardcodes everything into source), during development, this is a waste of time - especially when the details are changing rapidly. XDoclet enables you to have the best of both worlds.. developers can have everything in one place (the source) and once in a production environment, deployment descriptors can be changed without the need for recompiling. Of course, XDoclet also provides many other benefits - but the above is whats relevant to struts (imho). In reply to your suggestion to use @ant.replace@ to configure things - if you're going to put stuff in another file, why not put it in web.xml? btw - XDoclet supports the use of @tag value="${ant.properties}" cheers dim

Posted by Dmitri Colebatch on November 27, 2002 at 02:03 PM MST #

Actually, I got a note from Erik tonight with some handy information. He wrote: <span style="font-style: italic"> Did you know you can do Ant property substitution in XDoclet tags? For example:

 * @web.servlet name="search-init" 
     load-on-startup="1"
 * @web.servlet-init-param 
     name="index-dir" value="${index.dir}"
 * @web.servlet-init-param 
     name="use-ejb" value="${use.ejb}"

It's a very slick way to get build-time info into XDoclet artifacts.</span> Sweet - it's already there and I don't even have to do any extra work. How awesome is that?!

Posted by Matt Raible on November 27, 2002 at 03:38 PM MST #

Sun	Mon	Tue	Wed	Thu	Fri	Sat
« November 2008
						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30
Today

Raible Designs

Search This Site

Recent Entries

Tag Cloud

Navigation