<snip>
Unless users are working in an environment where minimizing the total number
of jars is crucial, I don't think cloning a dependency is worth it to save a
jar.
Lastly, it seems like you end up removing a dependency on Collections, and
add a dependency on BeanCollections.. And now, as a user, I have to make a
decision on whether to include BeanCollections or not.. Which means I need
to learn more about BeanUtils to make an intelligent decision, which raises
the bar to use.
hi eric
i think that their are now two distinct target users for commons:
1 builders of applications 2 creators of libraries, frameworks and containers
we need to satisfy both sets of users.
i take your point but i think that it only applies to those in the first category.
those developers in the second category have been telling us that they need more finely grained and focussed libraries with fewer dependencies. (some of this has been positive - thanks dain :) - some in the form of negative 'jakarta commons is crap'.)
this has come to a head recently with the existence of two incompatible releases of commons collections. unless we act, developers in the second category will soon need to choose between dropping (or repackaging) their commons dependencies or telling their users that they cannot use the latest (and very much greatest ;) commons-collections.
you're right that users in the first category need a simple install and prefer to get everything (rather than bits and pieces). we can probably distribute three jars:
beanutils-all beanutils-core beanutils-bean-collections
together with a README advising people which ones to grab.
- robert
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
