"Stephen Haberman" <[EMAIL PROTECTED]> writes: > One of the annoying things about Torque is that you have all of the > BaseXxx files mixed in with your extensions objects. The Base/Extension > idea is great, but it just sucks having both files in the same dir. > > Scarab and Fulcrum keep the src tree clean by generating the files off > in a target/src-style directory. This works fine, but I'm not all too > keen on it, especially when you go to use an editor like Eclipse.
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. > So I've been thinking about different approaches to getting the BaseXxx > source files in a different dir. I was debating two approaches: > > - Having Torque compile all of the BaseXxx source files into the same om > package, but put them in projectname-base-torque.jar or something of the > sort. Initially I thought this'd be really cool as you could just > reference the jar from your editor/build process and not worry about the > BaseXxx source files being in the src tree (Torque would compile them > off in a temp dir and then bring them back in). I don't want the generated source mixed in with my real source. If the additional JAR file will meet your needs for this, adding a new target to the build file to produce this JAR (explicitly) seems like a reasonable compromise. > 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. > 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). > - 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). > Torque works great for my current project, I'm just trying to think of > ways to make it cooler and easier to use. Definitely, good to see your ideas. - Dan -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
