You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2001/12/27 17:57:54 UTC
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Excalibur Utilities
Posted by Paul Hammant <Pa...@yahoo.com>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Excalibur Utilities
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> On Fri, 28 Dec 2001 03:57, Berin Loritsch wrote:
>
>>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.
>>
>
> This is very close to my original desire for Excalibur which IIRC you
> -1'ed!!! :)
Allow some room for people to grow. :)
> The one difference - rather than "commit to documenting the dependancies" we
> instead declare them in a properties file or something that would allow the
> "Optional Package" manifest specifications to be generated for each jar and
> thus the dependency tree could be automagically walked like that.
That would be part of the solution, but if a Pool requires Concurrent and
Containers, you have to tell the user that they are in different packages.
Otherwise, they will be in for a rude awakening.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Excalibur Utilities
Posted by Peter Donald <pe...@apache.org>.
On Fri, 28 Dec 2001 03:57, Berin Loritsch wrote:
> 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.
This is very close to my original desire for Excalibur which IIRC you
-1'ed!!! :)
The one difference - rather than "commit to documenting the dependancies" we
instead declare them in a properties file or something that would allow the
"Optional Package" manifest specifications to be generated for each jar and
thus the dependency tree could be automagically walked like that.
--
Cheers,
Pete
---------------------------------------
Be nice to your friends. If it weren't
for them, you'd be a complete stranger.
---------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Excalibur Utilities
Posted by Neeme Praks <ne...@one.ee>.
> 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:bloritsch@apache.org]
> 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:
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>