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
