all,
we have had the discussions of how to organize the avalon code before,
and it came up again in recent discussions. The important thing
mentioned recently was some input by newbies -- they find the
organisation pretty difficult to understand.
looking at the parts of which avalon consists, and not looking at their
current names, I'd say it *should* be possible to split avalon into the
same basic parts you find in most software:
1 - specification
2 - implementation
3 - extension specification(s)
4 - extension implementation(s)
5 - utility
6 - non-normative documentation
7 - external
8 - examples
9 - client software
10 - sandbox
roughly, the current subprojects fit as follows:
framework == 1 + part of 2 + 6 + 7 + part of 10
excalibur == part of 2 + part of 3 + part of 4 + part of 5* +
part of 10
logkit == part of 5
phoenix == part of 2 + part of 3 + part of 4
cornerstone == part of 3 + part of 4
apps == 8 + 9
(* -> largely moving to jakarta-commons)
where a better subproject organisation would be something like the
following:
framework == 1
excalibur == 2
container == 3(a), 3(b)
fortress == 4(a)
phoenix == 4(a), 4(b)
utility == 5 + 7
site == 6
apps == 8 + 9
sandbox == 10
with the explicit goal to have next to nothing in "utility" (as that
stuff is usually of more general use). That would also make it a goal to
move logkit out into a separate place.
I'm not saying this is what we should do (just throwing the current
organisation completely overboard would be somewhat stupid; and then
there's jakarta politics), would just like to hear from y'all whether we
are somewhat in agreement of where we would like to be in a perfect
world.
I'm also not saying this organisation should also dictate CVS setup
(though I do think it should, I'd like to keep that a separate
discussion).
That makes it easier to figure out what to do in an imperfect world.
grz,
- Leo
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
