> > Then Avalon would be left with threee things. Client API for components
(aka
> > Framework), Containers for Client API (aka Fortress/Phoenix/Merlin) and
some
> > Services (though I am not sure whether these belong in another project
or in
> > commons or what).
>
> The Turbine folks, who are now moving steadily to Avalon based as you
> know, have showed interest in a repository for Avalon Components.

IMO The repository idea is especially important for COP.  The nice thing
about COP is that you can use a lot of things that were already done in your
work.  Putting Avalon components in Commons is I think a mistake, since no
one looking for a specific component to do a job will go through the work
seperating non-components and utilities from the actual component
implementations.  It might hinder the adoption of the framework.  I know,
same applies currently to Excalibur, and that's why the utilities (io,
concurrent, collections and so on) should go into commons.

>
> For me it's
>    avalon-services.apache.org
>
>   or
>    services.apache.org
>
>   or simply in
>    commons.apache.org

As I said, I don't think it's a good place there.

>
> NOTE:
>
>    IIUC commons.apache.org  has been voted
>
>    incubator.apache.org has also been voted successfully
>
> > At times I have thought that moving Phoenix+Cornerstone+Apps to a new
project
> > would be a good thing and then at other times I hate the idea so ... ;)

A good idea IMO would also be to merge cornerstone and maybe apps with
excalibur to form a service repository, maybe under the name of cornerstone,
or Excalibur, or 'services'.  All these projects are component repositiories
anyway already.

-------------------
Marc Schier


--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@;jakarta.apache.org>

Reply via email to