Berin Loritsch wrote:
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 ;).
;-)
I understand your point.
- 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.
Yes, +1 for the discussion on it.
* 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.
roger
So we will have
* avalon-framework
* avalon-components
* avalon-scratchpad
* avalon-phoenix
* avalon-newstablecontainer
Seems ok.
* 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.
+1000 Works like a charm :-)
--
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]>
