Berin, I am in favor of splitting into multiple jars along the lines you say. I would suggest that we prepend jar names wih excalibur though.
-Paul. > Since my original messages got derailed into discussing Commons and > integrating > Avalon into largish projects, I want this thread to remain *on > focus*. Please > do not go on a tangent. > > Excalibur has some disjunct pieces that are fairly decoupled. To > leverage this > asset, we need to have multiple jars. That way people who favor small > disjunct > apis similar to commons can get what they need. People who favor > monolithic > approaches can use the main jar as is. We have already accomplished > this with > cli-util.jar. > > I propose we publish distinct API groups. Most of the hard work is > done already > with the package boundaries. The issue is when there are cross > package dependancies. > Let's face it, Pools are easier to write with Buffers and Mutexes. By > doing this, > we have to commit to documenting the dependancies. > > Whether we decide to donate to commons or not, it will only help > Excalibur and > Avalon adoption. The "daggers" I propose are: > > JAR FILE Package(s) > Dependancies > ----------------- ------------------------------------------ > ----------------- > cli-util.jar org.apache.avalon.excalibur.cli none > collections.jar org.apache.avalon.excalibur.collections none > concurrent.jar org.apache.avalon.excalibur.concurrent none > manager.jar org.apache.avalon.excalibur.component, > pool.jar, concurrent.jar, > org.apache.avalon.excalibur.logger > framework.jar, collections.jar > datasource.jar org.apache.avalon.excalibur.datasource > framework.jar > i18n-util.jar org.apache.avalon.excalibur.i18n none? > io-util.jar org.apache.avalon.excalibur.io none > monitor.jar org.apache.avalon.excalibur.monitor > framework.jar > naming.jar org.apache.avalon.excalibur.naming none? > pool org.apache.avalon.excalibur.pool > concurrent.jar, collections.jar > property.jar org.apache.avalon.excalibur.property > framework.jar > proxy-util.jar org.apache.avalon.excalibur.proxy none > testcase.jar org.apache.avalon.excalibur.testcase > framework.jar, manager.jar, > > pool.jar, concurrent.jar > xml-utils.jar org.apache.avalon.excalibur.xml > framework.jar > > For scratchpad code we can determine them later, otherwise, the > "daggers" I propose > are: > > JAR FILE Package(s) > Dependancies > ----------------- ------------------------------------------ > ----------------- > cache.jar org.apache.avalon.excalibur.cache > framework.jar > catalog.jar org.apache.avalon.excalibur.catalog > framework.jar, SUN's Catalog jar? > event.jar org.apache.avalon.excalibur.event > concurrent.jar, collections.jar > instrument.jar org.apache.avalon.excalibur.profile none > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
