Ok, since the original proposal i made for this was rather buried in a
separate conversation, i want to give this proposal a thread of its own
before i take action on it.
---------------------------------------------
The gist of the proposal is this:
Move the generic (i.e. non-struts) tools from the tools/tools package
into the tools/view package and drop the tools/tools package altogether.
The new package designation for these tools would be:
org.apache.velocity.tools.view.tools.*
One thing not mentioned as yet: I'd also like to move the
MultiViewsTool
from org.apache.velocity.tools.view.i18n.* to
org.apache.velocity.tools.view.tools.i18n.*. I think that would be a more
consistent organization. Daniel, does that work for you?
---------------------------------------------
So far the responses are:
- Committers in favor: Nathan
- Contributors in favor: Tim Colson
- Ambivalent or Opposed: none
---------------------------------------------
For those wondering why this has been proposed here's a recap of the
discussion so far:
<nathan>
you know, as i think about it, i'm not really sure why we even have a
separate folder tree/jar/et. al. for the non-struts tools. there's all of
three useful classes in there, and one of them is already dependent on the
view package. i'm seriously thinking we ought to fold them into the view
tree/package. i think it'd be nice to cut things down to just VelocityView
and VelocityStruts (or whatever you want to call them).
can anyone give a really good reason to maintain a separate library just for
these tools? after all, they are "view tools."
</nathan>
<tim>
Aren't the tools supposed to be able to live without
VelocityViewServlet, so folks using other frameworks can leverage them
without the extra baggage?
</tim>
<nathan>
yes, that's the idea. but as i said, one of the four tools in there
(ParameterParser) is already dependent on the view package (the home of the
VVS). so, if they want to compile the tools library or use the
ParameterParser, they already need the view package. so what's the harm in
combining the two? if they don't want to use the servlet-tied stuff, then
they can just ignore it and use only the tools they want.
</nathan>
I'll probably give this a week or so, and if there's still no opposition,
i'll start making the switch. I really think this is a good move to
simplify things.
Nathan Bubna
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
