It does seem like code generation is a more common strategy today than it was a couple of years ago. Back in 2000 we never generated any code, but tools today make it so easy to generate Java code. The Maven POM does support a <sourceModifications> element which can alleviate some frustration, and you can also (as mentioned below) modify the maven.compile.src.dir property (or whatever it is) with the mavenAddPath Ant Task.
I think it would be great if the POM somehow accomodated the notion of generated source code directory. I also remember one of the outstanding, low-priority tasks from the Maven website was to introduce to the POM the notion of a sample application. More compilable code that, in this case, is not part of the project source tree but somewhere else. One could make little Maven projects, one per sample application, and maybe that is the solution to take when POM inheritance becomes a little more stable. The single java source tree is an elegant solution but sometimes its difficult to work with model. -----Original Message----- From: Kevin Hagel [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 09, 2003 1:42 PM To: Maven Users List Subject: Re: location of generated source I agree completely. It would also be nice to see some documentation regarding xdoclet settings in project.properties, how they map to values that are used by xdoclet. If I hadn't been so busy trying to write an xdoclet module myself, I would still be regularly lost on this. maven.xdoclet.hibernatedoclet.0=true maven.xdocelt.hibernatedoclet.0.fileset=blah and so on. I actually find it easier to use ant taskdefs in my maven.xml, rather than use the maven settings that the xdoclet plugin suggests. Kevin ----- Original Message ----- From: "Sonnek, Ryan" <[EMAIL PROTECTED]> To: "'Maven Users List'" <[EMAIL PROTECTED]> Sent: Tuesday, December 09, 2003 1:38 PM Subject: RE: location of generated source > 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] > --------------------------------------------------------------------- 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]
