> Sounds like someone needs to patch Eclipse (which is open source, > IIRC). The compiler doesn't care what directory the source files are > in; the IDE shouldn't either.
Someone over on maven-dev mentioned working on an Eclipse plugin, so perhaps that will do the trick. Eclipse does support multiple src directories, it just doesn't like duplicate files in each (e.g. src/java and target/src have many files that the same) so you have to choose which one to edit. You can't choose src/java because none of the BaseXxx files are there and you can't choose target/src because you're changes need to be saved to src/java. > > Another pro is that not everyone who wanted to build the system would > > need Torque...they could use reference the jar. ...But I don't know if > > people'd actually be in such a situation. > > You can't compile or run your Torque-dependent code without its JAR, > so this isn't a valid argument. True, I didn't word that quite right. I meant to say they wouldn't have to generate the OM code to compile the rest of the source (like Scarab and Fulcrum require since the BaseXxx files aren't stored in CVS) but then ideally Torque is integrated nicely into the build scripts anyway (like Scarab and Fulcrum) so it's still not a valid argument. > > But then you have an extra jar to move around and Torque has to been > > extending to also compile, not just generate code. So while I still > > think this would be very cool, I don't know if it's as practical. > > I don't follow you. Wouldn't it be the job of the build system to > perform the compilation? Using Ant's JavacTask from Torque's tasks > wouldn't be very complicated, but the use case is not readily apparent > to me (perhaps because I don't use an IDE past XEmacs and Unix these > days). Again, my wording was pretty bad. I did have the javac task in mind and doing something along the lines of the current compile target. I can't remember what logic made me think that adding a compile task would be all that difficult...I don't think I had thought about it that much. Or something. :-) > > - The more practical solution, as I see it, is just to have Torque > > generate the BaseXxx files in a separate package, e.g. > > com.company.om.base, modeling the com.company.om.map. The upshot is that > > it's really simple, but helps keep the source tree at least a little bit > > cleaner. > > As John mentions later in this thread, that is not a correct use of > packages, and is damaging to the API (generally exposing more than > necessary). Yep, makes sense. I admit I'm not up to par on packaging-best-practices, but the argument still makes sense. > Definitely, good to see your ideas. Thanks. Maybe I'll put something together on this, but I'd really like to get to the standalone-enabled build-torque.xml one of these days. - Stephen -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
