Creating the jar sounds like an interesting idea. As I have no problem with generating and compiling the source in a temp directory though, I so question if such a large change is worth the effort.
Regarding the move to a /base/ directory, it actually started off that way. There was a lot of other places in turbine that packages were being used to keep the number of files per directory small. As the correct use of packages is to put related files together to present a coherent public api this often led to public api's that would have better remained hidden. I would prefer not to return to this practice. I think it is pretty hard to argue that the BaseFoo and Foo classes are unrelated enough to warrant being in different packages. john mcnally On Tue, 2002-06-25 at 03:43, Eric Pugh wrote: > +1 on the .base directory.. I have often thought about this as well.. > Scrolling through all the Base* classes is a pain... However, one other > change that I made is that often I want to look at my base classes, and I > have to first type in a list view BaseXXX... > > If you are moving them to /base/ then how about changing the default > properties to name them with a postfix: /base/MyTableBase.java so they sort > nicely... > > Eric > > -----Original Message----- > From: Stephen Haberman [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, June 25, 2002 4:50 AM > To: [EMAIL PROTECTED] > Subject: pushing base files to a separate jar > > > 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. > > 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). > > 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. > > 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. > > - 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. > > Torque works great for my current project, I'm just trying to think of > ways to make it cooler and easier to use. > > Does either the separate jar or base package idea sound any good? > > Thanks, > Stephen > > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
