[Proposal:Avalon5] Merge all Avalon 5 development into Avalon Sandbox

[Berin Loritsch <bl...@citi-us.com>]

We have *several* CVS repositories, and a couple different locations for
"Avalon 5" stuff.  We really need one location for the new Avalon
development and discussion issues.  For that reason I propose that we
merge all the efforts into

${avalon-sandbox}/avalon5

That would remove the ${jakarta-avalon}/src/proposal/avalon5 directory,
and make it official where our efforts need to go.

An alternative to that approach is to create a new Avalon CVS, so that
we can migrate initial stuff into one CVS structure.  I envision the new
Avalon CVS structure to look like something like this:

${avalon}/
    /framework4
        /src
            /java
            /cs
            /test
            /xdocs
    /framework5
        /src
            /java
            /cs
            /test
            /xdocs
    /container (for uber-container)
        /src
            /java
            /cs
            /test
            /xdocs

Questions are what do we do with Excalibur/LogKit/Cornerstone CVS?


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [Proposal:Avalon5] Merge all Avalon 5 development into Avalon Sandbox

[Nicola Ken Barozzi <ni...@apache.org>]

Berin Loritsch wrote:
> We have *several* CVS repositories, and a couple different locations for
> "Avalon 5" stuff.  We really need one location for the new Avalon
> development and discussion issues.  For that reason I propose that we
> merge all the efforts into
> 
> ${avalon-sandbox}/avalon5

+0

> That would remove the ${jakarta-avalon}/src/proposal/avalon5 directory,
> and make it official where our efforts need to go.
> 
> An alternative to that approach is to create a new Avalon CVS, so that
> we can migrate initial stuff into one CVS structure.  I envision the new
> Avalon CVS structure to look like something like this:
> 
> ${avalon}/
>     /framework4
>         /src
>             /java
>             /cs
>             /test
>             /xdocs
>     /framework5
>         /src
>             /java
>             /cs
>             /test
>             /xdocs
>     /container (for uber-container)
>         /src
>             /java
>             /cs
>             /test
>             /xdocs

What about keeping avalon 4 where it is and making the new CVS like this 
  (copied from you)

  ${avalon}/
      /src
        /java
        /cs
        /test
        /documentation

and have framework and container reside in the same java dir.
We can always make the compilation be done in two steps with the two 
packages.

I'd be +0 also for this though:

  ${avalon}/
      /framework
          /src
              /java
              /cs
              /test
              /documentation
      /container (for uber-container)
          /src
              /java
              /cs
              /test
              /documentation

> Questions are what do we do with Excalibur/LogKit/Cornerstone CVS?

This brings up another big question, yes. And IMHO it mixes with the 
AltRMI-EOB thread.

Should we have only framework and container in Avalon?

   if(reply="yes"){
     move("Excalibur/LogKit/Cornerstone", destination);
   }
   else{
     move("Excalibur/LogKit/Cornerstone", "Avalon Component Repository");
     add("EOB", "incubator", "avalon-eob");
     add("Jesktop", "incubator", "avalon-jesktop");
   }

What would "Avalon Component Repository" mean?

Basically it's exactly the same concept we envisioned some time back for 
an Avalon repository in Apache Commons.
A project that would keep Avalon Container-indipendent Components taken 
from Cornerstone, Excalibur, Logkit, Turbine, OBJ, etc...
It would have its set of developers and committers, all supervised by 
the Avalon PMC, instead of the Commons PMC.

Dunno if this is what we would want.

Why then do we want to delete Excalibur-Cornerstone?

1) excalibur has more than simply components, and didn't have rules 
about what to create there. We need to have a place to put 
Components/Services, not generic utility classes.

2) It's only for Avalon committers.

3) Cornerstone was tied to Phoenix, and this one would host only 
container-indipendent components.

The creation of this sub-project would mean that we could think about an 
EOB sub-project, and a Jesktop/Monarch UI subproject, the both of which 
would pass incubation phase.

Why would it be different from the current subproject system?

Because these ones are not competing versions of the same thing, but 
different applications of the framework-container.
They will have to be done by using the uber-container when it come out.

Thoughts, comments, suggestions, ideas?

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


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>