Torsten Curdt wrote:
On 18.05.2007, at 13:57, Niall Pemberton wrote:
I wasn't part of the decision at the time, but (at least some if not
all) these classes are in the BeanUtils public API so changing the
package would have (and still will) broken binary compatibility (to
remove the dependency on Collections 'coz of its incompatibility
between versions!) - they were copied and (AFAIK) the parts of the
public API deprecated with the intention of removing them in the next
release - but there hasn't been one since that was done and 1.7.0
released.
I am not pointing fingers. But whatever it takes - having those classes
in there like this is not acceptable and needs to be fixed ASAP.
Whilst it may have frustrated you recently, the current situation really
isn't that bad. It allowed [beanutils] to drop a 500Kb dependency on
[collections] in a simple manner.
The copy was permitted as there were few classes involved, and they were
very stable.
Changing the package name would have been, and still is, backwards
incompatible. As such it is unacceptable for such a widely used package
as [beanutils]. I am -1 to arbitrarily changing the package name.
We really need a prime directive in commons. Don't break backwards
compatibility. Every time we do we cause problems down the line - its
simple due to our status as the lowest of low libraries. And again, this
also emphasises that each commons library works much better when it
stands alone - no dependencies.
In summary, I am currently -1 to any change here, except possibly
producing a commons-beanutils-without-collections.jar file, perhaps as a
1.7.1.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
