Ok, here's where things stand so far as i can see: Commiters: +1 nathan +1 gabe -? geir (sounded like a -1)
Contributors: +1 anthony +? tim (not sure where you ended up) -? bill (sounded like -0) so, at this point, conversation has died. i answered geir and bill's opposing remarks, but they do not appear to have changed their minds. since geir's vote is binding according to apache rules, i guess i can't go forward with this. :-/ now, i must admit i'm a little frustrated by the lack of response to my arguments in favor, and i don't want this to continue to hold things up around here. so, being a notoriously stubborn and thick-headed person i'm going to lay out my argument one last time (and include the struts stuff as i secretly wanted all along) and then pathetically beg the opposition to change. ---------- Reasons We Should Fold The Tools/* Trees Into One: 1. This project is quite small. Building/distributing 3 jars is serious overkill. 2. It makes life easier for the many who use all three trees (tools,view,struts). 3. The most (almost the only?) active committer supports this. (yeah, it's just me, but that's gotta count for something, right?) ---------- Reasons Against This And Their Counter-Arguments: 1. Those using only tools/tools would have to drag around servlet.jar and struts.jar and whatnot. Counter: Those just *using* tools/tools will (at some point soon hopefully) be able to just download a binary of velocity-tools.jar and use only those classes which interest them. If they don't use classes dependent on servlet.jar or struts.jar, then they don't need those jars. 2. Those wishing to compile, then use just tools/tools will have to muck around with servlet.jar and struts.jar and whatnot. Counter: For those checking out the project source and compiling it, we already include servlet.jar and struts.jar in CVS. They needn't do anything but check out the module and compile it. Furthermore, if people really only want to compile the tools/tools or tools/view classes, then we can carefully choosing the package/paths of those files and add Ant targets to compile/jar only those classes. If that's what it takes, I'll put in the work for that myself. My plan for the paths is (in order of dependency): generic tools - org.apache.velocity.tools.generic.* ViewTool tools - org.apache.velocity.tools.view.tools.* struts tools - org.apache.velocity.tools.struts.* 3. It's theoretically better to have separate places for non-view tools and struts tools. Doesn't that just make sense? Counter: Theoretical is nice, but practical makes people happier. In other words, is it really better to cave to the "needs" or "desires" of some imagined theoretical users, or the interests of the active developers and contributers? Remember, so far no user is able to compile tools/tools independent of tools/view because of the misplaced ParameterParser and NO ONE has complained about that! 4. Why change the status quo? We don't want to break backwards compatibility. Counter: We've released nothing so far. We don't presently distribute binaries or have any real official documentation on the current state of things out there. We have absolutely no compunction to keep things B.C. yet. ---------- and now comes the pathetic begging.... please support me in this!!! please, please, please, please, pretty please with a cherry on top!!!! :) Nathan Bubna [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
