I'm in a similar situation in my project. Originally built using mainly BMP entity beans, I'm at a point of reevaluation and thinking about hibernate. I think for the time being I'll stick with the generated classes in the target directory, and see if I "need" them saved in CVS.
I can't think of many J2EE applications that aren't using xdoclet, so maybe it would be a good idea to put together a "Best Practices" guide for this kind of thing? I'm sure there are several people using maven that have these same questions. I think maven does a great job at handling it, but with several different options, a short HOWTO might be beneficial to newbies (and the not so newbie....like myself). Ryan -----Original Message----- From: Kevin Hagel [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 09, 2003 3:28 PM To: Maven Users List Subject: Re: location of generated source I haven't dealt with XDoclet and EJBs much beyond experimentation. I'm staying away from entity beans anyway, since I'm using hibernate. when the project gets to the point where I want remote access, I'm plan to use Stateless Session Beans only. I mostly use it right now for hibernate and jmx/jboss stuff, and I'm busy trying to write a module for handling springframework stuff. I can suggest an experiment maybe ...? do a touch *.* and run xdoclet, then run it again ...? ----- Original Message ----- From: "Sonnek, Ryan" <[EMAIL PROTECTED]> To: "'Maven Users List'" <[EMAIL PROTECTED]> Sent: Tuesday, December 09, 2003 1:27 PM Subject: RE: location of generated source > Thanks for the response. > Do you find the build to be fast enough for doing incremental builds? I > mean, even if xdoclet doesn't generate the files in question, does the > timestamp check take unnecessarily long? The reason I was thinking of > taking my generated files out of 'target/xdoclet', was because the > interfaces and utility classes it generates are so rarely updated, that the > constant refreshing of the classes becomes tedious. How large is your > project and what do you use xdoclet for (entity and session ejbs, taglibs)? > > Thanks again. > Ryan > > -----Original Message----- > From: Kevin Hagel [mailto:[EMAIL PROTECTED] > Sent: Tuesday, December 09, 2003 3:18 PM > To: Maven Users List > Subject: Re: location of generated source > > I always put XDoclet-generated files in target/xdoclet/hibernatedoclet, > target/xdoclet/springdoclet, that kind of thing. > Isn't it true that XDoclet won't bother re-creating your generated classes > if the timestamps on the source and destination files match? I mean is > there a force=false kind of setting or something? > > You can also set > maven -DdoXDoclet=true > on the command line and just > <j:if test="${doXDoclet == 'true'}"> > ....xdoclet things > ....copy xdoclet-generated source over to src/java... > </j:if> > > ----- Original Message ----- > From: "Sonnek, Ryan" <[EMAIL PROTECTED]> > To: "'Maven Users List'" <[EMAIL PROTECTED]> > Sent: Tuesday, December 09, 2003 8:07 AM > Subject: location of generated source > > > > Where do most maven developers place generated files (ex: xdoclet)? > > I've been developing a maven project for the past 6 months and have been > > dumping all generated files into 'target' to avoid saving into CVS. Now, > > with over 200 generated classes, and little change, I'd like to avoid > having > > xdoclet run EACH java:compile. So, here are my two options as I see them: > > > > 1. create a separate subproject, and have the generated interfaces saved > in > > src/java to "appease" maven. Add a task into maven.xml to regenerate the > > classes only when needed. > > > > 2. save the files in src/java-gen (or something like that), and modify > > maven.xml to add that location to the maven.src.path (is that the right > > property?). > > > > what do others do out there? > > > > Ryan > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
