avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@osm.net>
Subject Re: organisation of avalon subprojects
Date Sun, 30 Jun 2002 22:03:38 GMT


Leo Simons wrote:

>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.
>  
>

Agreed.

>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
>

That makes sense.

>excalibur   == part of 2 + part of 3 + part of 4 + part of 5* +
>               part of 10
>

What sort of mix do you have in mind here ?

>logkit      == part of 5
>

Yep.

>phoenix     == part of 2 + part of 3 + part of 4
>

Yep.

>cornerstone == part of 3 + part of 4
>

Yep.

>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
>

I would really like to see the death of the container seperation - its 
way too early to be brainding anything in the container area just yet. 
 Phoenix  I think will survive as a brand but will be restructured. 
Merlin is going throiugh the same process of restructuring but probably 
more radical at this point in time.  What is important is that we 
seperate out container framework content, container services, and 
container tools and that should be the defintion of a container.  
Merlin,  Fortress and antything else calling itself a containing has to 
evolve and leverage that platform (or die).

>
>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 in agreement about the restructed view.  As you have noted below I 
don't see this as a CVS structural thing any time soon.  But if we 
simply look at the logical breakdown of what is Avalon - I think you 
have outlined an breakdown that makes a lot of sense.

Cheers, Steve.


>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:avalon-dev-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
>
>  
>

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net




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


Mime
View raw message