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
${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
This brings up another big question, yes. And IMHO it mixes with the AltRMI-EOB thread.Questions are what do we do with Excalibur/LogKit/Cornerstone CVS?
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 [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
