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 2003/06/18 22:06:02 UTC

[RT] Making sense of our repositories

I would like to get us to a place where our repositories make sense, and
have a specific purpose.  We currently have the following set of
repositories:

avalon
avalon-logkit
avalon-excalibur
avalon-components
avalon-sandbox
avalon-phoenix
avalon-site

Of which only two are "product-specific" (LogKit and Phoenix).  It is
clear what goes in Components, Site, and Sandbox.  I would like to
clarify what goes in "Avalon".

Currently with Framework and Fortress in there, I would define it as
"Framework and Containers".

That would mean that Phoenix technically should go in there, but
Phoenix is so big right now, we need to devote some time to it,
and see how much we can reuse accross our containers.  This should
be done as a unified effort, not as a competition type of thing
as was done in the past.

Lastly, Excalibur becomes a collection of container utilities.  THe
thing about Excalibur, is that it should be utilities that should not
really be hosted elsewhere.

The current contents of Excalibur are:

compatibility
component
configuration
datasource
event
extension
i18n
instrument (*-client, *-manager)
lifecycle
logger
monitor
pool
sourceresolve
store
thread
xmlutil

Of these datasource, monitor, sourceresolve, store, and xmlutil all
should move to avalon-components so that everything is where it belongs.
Also, now that Fortress is released, we should deprecate component and
pool--and possibly thread.

If we perform all these actions, then Excalibur will become:

compatibility
configuration
event
extension
i18n
instrument (*-client, *-manager)
lifecycle
logger

Which is a much smaller set.  Again, of that set a couple of the
libraries are so central, they can be considered extensions of the
core Avalon.  Those are the instrument (and friends) and lifecycle.
The question remains on how to best incorporate them into our structure.
If we move them into the core "avalon" repository then the "avalon"
repository becomes the home for containers, framework, and extentions.

Likewise, extension and i18n are generic enough to try and work with
Jakarta Commons on it.

That leaves only compatibility, configuration, event, and logger.  That
seems pretty paltry to justify a whole CVS Repository (as does a
seperate one for LogKit).

This is a random thought designed to generate discussion.  What are
everyone's feelings on the matter?


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org