Berin Loritsch wrote:
The Avalon project hierarchy has a concept that works, but
the implementation that doesn't.
roger
<nice-summary/>
As of right now, everyone seems to be in agreement that Framework is at the core. It is by itself. Where the differences in ideas/oppinions come is where components and containers go. For that reason, I would like to propose the following solution. * Avalon Framework remains as is. We can look at Avalon 5 later after the dust has settled.
+1
+1 This /could/ become in the future a repository where also outer projects can put components, dunno, but for now it's the only workable solution.* Avalon Excalibur gets repurposed to strictly a location for Components. All support code gets moved to commons (unless the move is already done with Jakarta commons like in the case of Collections or replaced by a more robust library like Concurrent).
I'd call it "Avalon Components", because all these fancy names have some people confused; and when a fancy name project changes what it contains, we are ready for pretty serious misunderstandings. IMHO that is.
- The TestCase and Instrument projects need to be handled as they are
specific to Avalon.
+1
- It can probably be argued that Instrument might make an excellent
candidate for Avalon Commons. It is some top notch code.
What is Avalon Commons in your view?
- We may want to make the core Instrument library part of Avalon
framework (discussion must occur first).
+1
* Avalon Scratchpad is a location for maturing subprojects to grow.
+1 the concept, +0 for a separate repository for it.
* As containers become mature, they move out of Avalon scratchpad and become a top level sub-project. I.e. Avalon Fortress and Avalon Merlin at the same level as Avalon Phoenix when they are released.
+0 Not sure about the direct road: scratchpad -> top level subproject But I have no alternative viable solution.
* All components in Avalon Cornerstone get merged into Excalibur. This means we have to come up with some standard Context name/value pairs that always exist--as this is the only reason why most cornerstone components require Phoenix.
+1 definately.
* I am not sure what to do with Avalon Apps. We need to look at the possibility of moving them out of Avalon's sphere of responsibility. I would have a hard time justifying their existence in an Avalon charter. But we may also want to follow the same rules as containers for the applications.
Same feeling here.
Thanks Berin, this is good stuff! :-)
--
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]>
