> i18n-util.jar org.apache.avalon.excalibur.i18n none? If my stuff falls under that then the interfaces and some very basic classes have no dependancies and the implementation(s) will depend on framework, xml-util and maybe also some caching and database stuff in the future.
Neeme > -----Original Message----- > From: Berin Loritsch [mailto:[EMAIL PROTECTED] > Sent: Thursday, December 27, 2001 6:58 PM > To: avalon-dev@jakarta.apache.org > Subject: Excalibur Utilities > > > 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 > > -- > > "They that give up essential liberty to obtain a little temporary safety > deserve neither liberty nor safety." > - Benjamin Franklin > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
