Matt RaibleMatt Raible is a Web Developer and Java Champion. Connect with him on LinkedIn.

The Angular Mini-Book The Angular Mini-Book is a guide to getting started with Angular. You'll learn how to develop a bare-bones application, test it, and deploy it. Then you'll move on to adding Bootstrap, Angular Material, continuous integration, and authentication.

Spring Boot is a popular framework for building REST APIs. You'll learn how to integrate Angular with Spring Boot and use security best practices like HTTPS and a content security policy.

For book updates, follow @angular_book on Twitter.

The JHipster Mini-Book The JHipster Mini-Book is a guide to getting started with hip technologies today: Angular, Bootstrap, and Spring Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster.

This book shows you how to build an app with JHipster, and guides you through the plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks so you understand the underpinnings of your great application.

For book updates, follow @jhipster-book on Twitter.

10+ YEARS


Over 10 years ago, I wrote my first blog post. Since then, I've authored books, had kids, traveled the world, found Trish and blogged about it all.

RECENT ENTRIES


Tag Cloud


abbie appfuse birthday denver family grails gwt jack java javascript jhipster jsf linkedin maven roller skiing softwaresummit spring springmvc struts2 travel trish vacation webframeworks wicket
« 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 09: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 10:38 PM MST #

Post a Comment:
  • HTML Syntax: Allowed