I think there are 2 separate issues. Having one big jar with all the commons code - or one big jar with all jakarta code - is a good idea. So is having a distribution with 20 small jars. It's a matter of taste, so having both is the best solution.
The issue I'm concerned with is the spaghetti that goes between the packages, and the ability to pick one component without having to use all jakarta. And as a practical problem - modeler won't work without digester which doesn't work without collections, beanutils. And digester doesn't work well in the top loader - and who knows what else has the same problems. As you know, there are good reasons to be able to keep the root loader clean. It may be just another matter of taste - but at this moment bloat ( include everything, just in case ) wins. I think those are _very_ distinct problems, and we shouldn't mix them. I fully support one big jakarta-commons.jar, as well as a distribution that includes all the software in jakarta. Costin Craig R. McClanahan wrote: > > > On Fri, 6 Dec 2002 [EMAIL PROTECTED] wrote: > >> Date: Fri, 6 Dec 2002 18:05:53 +0000 (GMT) >> From: [EMAIL PROTECTED] >> Reply-To: Jakarta Commons Developers List >> <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] >> Subject: Re: [core] Scope, you choose! >> >> My mail was meant to emphasise the different ideas/companents/packages >> that have been mentioned over time. In particular they are the ones that >> are about assisting development with the 'core' of the JDK. >> >> I would suggest that if we follow the charter, and all of its >> theoretically marvellous principles, then we end up with lots and lots >> of small jars. >> > > Lots of JARs isn't necessarily bad, if your development environment makes > it easy to dynamically build classpaths (like Ant does). However, there > are often going to be cases where you'd really like a "bunch o commons > JARs" all together, to make life easier. The political challenge is, who > gets to define what is included in the bunch? > > I tried to punt on this issue with the "combo" project, which includes a > specified released version of *all* the packages in jakarta-commons (but > not the sandbox). Currently, this thing actually builds (except for > Latka, but that's most likely an issue on my development platform), ending > up with a JAR file of just over one megabyte. As a side benefit, it > generates consolidated Javadocs for the packages that are included. > > The theory is that most people will want a JAR that contains the latest > released version of all the JARs, so that is how the build is set up. > Presumably, any time a Commons package was released, the CVS tag to pull > for that package would also be updated in the combo build.xml file. > However, because each of the tags is itself an Ant property, it is very > easy to use this to grab exactly the combination of versions you want. It > also would be straightforward to set up mechanisms where you can subset > this -- right now you'd just have to comment out the things you don't > want. > > Rather than getting into emotional discussions of "core" versus > "non-core", how about if we start with "combo" that includes *all* the > non-sandbox packages, and work from there? > > Craig -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
