> From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]] > > > * 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). > > +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. > 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.
Ok. Sounds good. > > - 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? Umm, I meant Apache Commons. I.e. Instrument gets a more broad audience than just Avalon. I don't want to loose Leif, though ;). > > - We may want to make the core Instrument library part of Avalon > > framework (discussion must occur first). > > +1 Let's see the feelings on the list. before we go too far in this direction. If we move Instrument to Apache Commons, then we would have a dependency of Framework on Instrument, or an understanding that Instrument is a supported option for components. The nice thing about Instrument is that if a component uses Instrument but the container does not support it, then the component is not broken. > > * Avalon Scratchpad is a location for maturing subprojects to grow. > > +1 the concept, +0 for a separate repository for it. Think of how Jakarta Commons works. We have "jakarta-commons" and "jakarta-commons-scratchpad". It seems to work pretty well for them. We should follow their lead as much as possible on that approach. > > * 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. My thing is that we don't want the "Official Container" connotation, esp. if a container falls out of favor (i.e. ECM). We want the containers to follow the specs, so we might want to come up with a container specification test suite to ensure any published container follows the core Avalon specifications. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
