On Jan 14, 2004 4:51 PM Andrew Stevens wrote: > > So why not just exclude the subclasses that don't have the > @struts.form tag from your fileset? You can then include > their (hand-written) entries in the validation.xml via merge > points, like Erik was suggesting. > > > Andrew.
Your suggestion is a good one and would probably work in most instances, but it's a nuisance to have to control this particular behavior of <strutsvalidationxml> using a fileset in my build file. One of the things that attracted to me to XDoclet is the fact that I need to build several products from the same Struts code base, but certain classes must not be shipped in certain products (and their corresponding entries must be stripped from the deployment descriptors, as well). XDoclet provides a rather elegant solution to this requirement and at the same time eliminates a lot of complex if/then logic that used to exist in my build script. With XDoclet, I can specify a single fileset based on the product I am building and then use that fileset for my compile targets as well as my webdoclet target. In this way, my deployment descriptors always match the class files I am compiling and shipping in various products. Skirting around this issue by filtering the forms that I want <strutsvalidationxml> to process using a fileset reintroduces into my build script some of the special case logic I am trying to eliminate. -Kelly ------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
