Hi Simon, I thought we were happy to get away from the copy-and-paste paradigma of reusing code - as you pointed out, there are now three classes used of commons-lang.
What happens if a bug-fix is introduced in these classes, am I supposed to go through the source code once more and copy them over once again if nothing has changed? In fact, we are relying on so many commons-libraries, should we throw all of them out and copy all the code over? @Sean: how come you say we did avoid a dependency on commons-lang for that long? I didn't have the feeling that we where trying to achieve this, correct me if I am wrong... regards, Martin On 10/19/05, Simon Kitching <[EMAIL PROTECTED]> wrote: > Hi guys, > > Well, you should check out some of the email discussions held on > commons-dev about this. The general conclusion was that even commons > components should avoid dependencies on other commons components where > feasable. > > Obviously copying large chunks of another library isn't a good idea. But > where just a class or two was used it was decided that copying was less > evil than a dependency. > > Examples: > * commons-beanutils has been modified to avoid a > dependency on collections. > * commons-digester has been modified to avoid a dependency on > collections. But its dependency on beanutils continues because > it uses quite a lot of beanutils. > > I know there are other cases in commons though I can't remember which > for the moment. > > Commons can be thought of as a "collection of code snippets" available > for copying as well as a library. The main commons-collections > maintainer is on record as being happy with this. > > Regards, > > Simon (maintainer of commons-digester + commons-logging). > > Sean Schofield wrote: > > I agree with Bill on that one. I was suprised to see that this > > dependency had been introduced (after we had avoided it for so long) > > but I don't think its a big deal. > > > > sean > > > > On 10/18/05, Bill Dudney <[EMAIL PROTECTED]> wrote: > >> I respectfully disagree, there is no way I want us copying > >> functionality from commons-lang into myfaces. > >> > >> -bd- > >> > >> On Oct 18, 2005, at 6:47 PM, Simon Kitching wrote: > >> > >>> Hi, > >>> > >>> Class org.apache.myfaces.custom.calendar.HtmlCalendarRenderer.java > >>> has had a dependency on commons-lang added. This means that my app > >>> which previously worked fine now fails with a NoClassDefFoundError. > >>> > >>> The dependency was introduced by r289859 (mmarinschek) on 2005-09-18. > >>> > >>> I would recommend removing dependencies on commons-lang if > >>> possible. It's always nice for a library such as myfaces to keep > >>> its dependencies as small as possible. > >>> > >>> I've searched for "org.apache.commons.lang" and found the following > >>> classes currently depend on it: > >>> > >>> HtmlCalendarRenderer (method EscapeUtils.escapeJavaScript) > >>> HtmlJsValueSetRenderer (same) > >>> JspStateManagerImpl (EqualsBuilder and HashCodeBuilder) > >>> > >>> I think it's quite feasable for myfaces to copy this o.a.c.lang > >>> functionality into the myfaces project. > >>> > >>> > >>> > >>> On the general topic of binary compatibility, may I recommend the > >>> CLIRR project: > >>> http://clirr.sourceforge.net/ > >>> Given two jars it will tell you whether they are binary compatible > >>> or not. It also generates a nice report of the API changes made > >>> which can be useful for creating release notes. > >>> > >>> Regards, > >>> > >>> Simon > >>> > >> > > > > -- http://www.irian.at Your JSF powerhouse - JSF Trainings in English and German
