avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: [RT] Making sense of our repositories
Date Wed, 18 Jun 2003 22:45:21 GMT

Farr, Aaron wrote, On 18/06/2003 22.35:

>>-----Original Message-----
>>From: Berin Loritsch [mailto:bloritsch@apache.org]
>>Sent: Wednesday, June 18, 2003 4:06 PM
>>To: Avalon Developers List
>>Subject: [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:
> 
> 
> [snip]
...

> So it seems to me that the cvs structure should reflect that as much as
> possible and thankfully that seems to be the direction the project is
> headed.  The minimal set of repositories could probably be something like
> this:
> 
> avalon
>    ( 
>      /framework
>      /containers [?]  <-- would hold fortress, phoenix, merlin
>      /ext             <-- the core Excalibur components Berin mentioned
>     )
> avalon-components     <-- remaining excalibur and cornerstone components
> avalon-sandbox        <-- we all need a sandbox to play in
> avalon-site           (no way this could end up in avalon/site ?)

I had partitioned the Avalon site in:

  Framework | Components | Containers | Apps | Sandbox

IMHO this is the category that can be used.

  avalon
     (
       /framework
       /container       <-- would hold our only container
      )
  avalon-components    <-- remaining excalibur and cornerstone components
  avalon-sandbox       <-- we all need a sandbox to play in

Why 1 container? Well, one implementation is the only way we can focus 
on getting things done. And it should be targetted at least for server 
usage. I say at least, if it can do more, better.

Why framework with container and ext under the same roof? Because we 
have seen that making a separate CVS module has created more community 
problems that we could manage. And design difficulties.

Why /ext at all? Well, we could seemingly kill it IMHO. These are 
utility packages that are needed by the container, so they are 
effectively *part* of the container. We have seen that a repo for ext 
stuff becomes a sandbox with little control. It's easy to make 
"extensions", harder to manage the resulting mess.

Why a site? Now that we have a base project called avalon, IMHO it's 
easier to put the site there.

Recap:

   The Apache Avalon Project is a Framework with a Container impl.
   It has a Components subproject, and a Sandbox for experiments.

   "Avalon" is a Framework.
   It has many containers, one of which is made by Apache Avalon.
   It has many components, some of which are in Apache Avalon.
   It has many apps, some of which at Apache.
   It has a sandbox for experiments.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------



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


Mime
View raw message