bean-collections has one classes that has been released (BeanComparator). i'd prefer to keep this class in bean-collections since it is a very good fit there but i'd be willing to move it back if anyone thinks that this would be a major issue.
i'd like to ship a distribution containing both an all-in-one jar (all beanutils classes) and also a modular jars. so, the compressed binary distribution would contain three jars:
commons-beanutils-all commons-beanutils-core commons-beanutils-bean-collections
those users who don't care about disc space could grab the all-in-one jar. those libraries, frameworks and applications that do could depend on commons-beanutils-core alone. the distribution build builds all these jars (delegating the bean-collections to that's build script). i think that this arrangement should satisfy both target groups of users.
for the moment, the all-in-one jar is named commons-beanutils (for gump compatibility reasons). unless the community comes up with a better plan for beanutils distributions, i'll change the name of the jar and correct the gump descriptors later this week.
i've been playing with the mavenized documentation. at the moment, i'm thinking about using a subdirectory with a separate mavenized deployment for the bean-collections stuff. any opinions/better plans?
the other matter is the offline documentation (in the package.html). i'm not really sure whether i'd be better to retain a single package.html in core (adding indications about which distribution jar each feature is in) or whether it's better to have a separate on in each. which do people prefer?
- robert
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
