On 9/21/05, Henning P. Schmiedehausen <[EMAIL PROTECTED]> wrote: > Nathan Bubna <[EMAIL PROTECTED]> writes: > > >anyway, though i've clearly been out to lunch in being suprised that > >1.5-dev now has a commons-lang dependency, i'll attempt to stand by my > >opinion that VelocityTools core classes shouldn't be given a new > >dependency just to test for empty strings. and really, given that i > >was more accepting of the commons-lang dep in the core because the > >core project offers two jars (to simplify things for users that want > >them simplified), i can at least claim consistency in concern about > >adding dependencies. :) > > For that (and because using .isEmpty() and .isNotEmtpy() actually > helps with the code readability), we could go the approach that > commons-email did: > > Add a VelocityUtils helper class and collect these small methods > there. We should, however consider a threshold of copied methods at > which we can decide to go with an external dependency.
no, this would be a fairly pointless exercise and at greater risk of the "rot" you describe below. by the time a Velocity release came out with that class, VelocityTools 1.2 should already be released. after 1.2 is out, there's little reason not to use commons-lang directly. > While I agree that jar hell is bad and small building blocks like > commons-email are better off having just a few or no external > dependencies, I don't really get it for a project like > Velocity. Referencing methods from StringUtils, which is a pretty > stable class since the first release of commons-lang, is IMHO no > problem. The whole idea of the commons _is_ not to duplicate code. > > Most people that go through jar hell do it, because they are not aware > of the dependencies needed by a component. Our job would be to > document when a certain external jar dependency is needed and what > version that would be. The hibernate people did a really good job for > Hibernate2 (see > http://cvs.sourceforge.net/viewcvs.py/hibernate/Hibernate2/lib/README.txt?rev=1.12&view=markup) > > As long as we keep arguing "just one method doesn't justify an > external dependency", we will keep pulling methods into our code > base. They _will_ rot there. if you don't believe me, look at the > state of some parts of the org.apache.turbine.util subtree. :-) actually, i agree. my argument was specifically that "just testing for an empty string" doesn't justify an external dependency. that's quite different to me than arguing "just one method..." :) > Best regards > Henning > > > >On 9/19/05, Will Glass-Husain <[EMAIL PROTECTED]> wrote: > >> Hi Nathan, > >> > >> (Responding to the JIRA). Yes, Velocity has a commons-lang 2.1 > >> dependency, as of last week. (was bundled in with the event handler > >> patch). > >> > >> You actually commented positively on it (which was encouraging as I am > >> reluctant to add dependencies without need). > >> > >> WILL > >> > >> ----- Original Message ----- > >> From: "Nathan Bubna" <[EMAIL PROTECTED]> > >> To: "Velocity Developers List" <[email protected]> > >> Sent: Monday, September 12, 2005 6:56 AM > >> Subject: Re: event handler patch > >> > >> > >> looks great, Will! > >> > >> regarding the dependency thing... are we going to continue to > >> provide both the velocity.jar and velocity-dep.jar with the 1.5 > >> version? if so, then the addition of commons-lang is not too bad. > >> people can use the whole commons-lang lib with velocity.jar and we can > >> extract and ship StringUtils in the velocity-dep.jar. > >> > >> > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > -- > Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH > [EMAIL PROTECTED] +49 9131 50 654 0 http://www.intermeta.de/ > > RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire > Linux, Java, perl, Solaris -- Consulting, Training, Development > > 4 - 8 - 15 - 16 - 23 - 42 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
