You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@citi-us.com> on 2002/11/20 18:55:15 UTC
Avalon Project Hierarchy
The Avalon project hierarchy has a concept that works, but
the implementation that doesn't. For instance, from the
thread "Single Avalon Implementation yes/no/why/how", we
have Noel writing:
> > Please be specific about what you mean? As I see it, the
> current division
> > of Avalon technologies makes sense to me:
> >
> > * Avalon Frameworks - these are the basic contracts that
> > authors can expect to be guaranteed in all platforms,
> > plus some simple utilities.
> >
> > * Avalon Excalibur - a major implementation of the
> > the Frameworks. But not the only possible one.
> >
> > * Avalon Containers - container implementations.
> > Guaranteed to support Avalon Frameworks, and
> > typically written using Excalibur classes.
> >
> > * Avalon Cornerstone - common pluggable services.
> > Best case says that they should run in any
> > proper container.
> >
> > * Avalon Applications - a repository for "demo"
> > applications that don't have their own place.
And Nicola responding:
> Basically it makes sense.
> There are some issues though:
>
> * Excalibur is not a major implementation of the the Framework. It
> contains utility stuff to create containers and some
> containers itself.
>
> * Avalon Containers is not there, and containers have been growing in
> Excalibur.
>
> * Avalon Cornerstone has components that cannot yet run in all
> containers. We should ensure that it can happen or that it's properly
> labeled where really impossible to make it cross-container.
Which represents some conceptual friction.
Nicola's solution includes:
> 1) Avalon becomes a single repository with framework and
> utilities. All
> utilities that are not Avalon-specific move to J-Commons- or Commons.
> This has already been started.
>
> 2) There is a place where to breed containers. Can be Avalon
> scratchpad
> or container scratchpad.
>
> 3) there is a place to keep containers. In my proposal it's in a
> ./containers subdir of the Avalon CVS. If the container becomes big
> enough, like Phoenix, it becomes an Avalon subproject in its
> own right.
>
> 4) Avalon Cornerstone and Avalon Applications are placed in a
> repository
> where multiple parties can collaborate. So it can be Apache Avalon
> Commons ot Apache Commons Avalon, but the concept remains.
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.
* 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).
- The TestCase and Instrument projects need to be handled as they are
specific to Avalon.
- It can probably be argued that Instrument might make an excellent
candidate for Avalon Commons. It is some top notch code.
- We may want to make the core Instrument library part of Avalon
framework (discussion must occur first).
* Avalon Scratchpad is a location for maturing subprojects to grow.
* 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.
* 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.
* 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.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon Project Hierarchy
Posted by Leif Mortenson <le...@tanukisoftware.com>.
>
>
>>> - 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 ;).
>
instrument is basically dependency free. There is the exception of the
AbstractLogEnabledInstrumentable class. The other two packages contain
dependencies. But could be reworked a bit to live over there. How would
that work? Would I need to change the dependencies to use commons
jars. Or make use of released versions of the Avalon jars?
Instrument-Manager just uses framework, instrument and altrmi.
Instrument-Client is stand alone, so its dependencies are not so
critical. What
it uses can be reworked without affecting existing users.
But overall, I like Avalon. :-) And would still stay. Trying to keep
up over on commons
in addition would also end up taking more more of my time. So if it
makes sense,
leaving them here would be nice :-)
>>> - 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.
>
I had thought about moving instrument into framework before. I view the
core classes
as being on the same level as the logging classes. Kind of a set of
base utility classes.
Like logging, the actual implementation is separated out and exists
right now in the
instrument-manager classes. A different implementation could be written
at any time
and all of the components using the instrument classes would still work
with the new
manager implementation.
I think it would be simpler for users to add instrument to framework
than to add a
dependency to framework on instrument. The drawback is that instrument
would lose
the ability to be used outside of avalon. I doubt that is an issue with
any users right now
however as the instrument-manager requires avalon classes.
Note that components always require the core instrument classes to be
present. They
will work whether or not they are registered with an instrument-manager
however.
This was done to ease the implementation into a world with lots of
existing containers.
Of course I think that any good container should have the goal of supporting
instrumentation :-)
Cheers,
Leif
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon Project Hierarchy
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Noel J. Bergman wrote:
> Nicola,
>
> OK. So what you are saying is that Excalibur, in being "eliminated" as an
> individual entity, has its Avalon-specific classes divided into two areas:
> Container and Components, depending upon the type of class.
Correct.
Also, since Excalibur contains also non-Avalon specific stuff, that will
go in some Commons.
> That's the entirety of our disconnect?
I think we really agree, it's just a terminology-understanding thing.
> --- Noel
>
> -----Original Message-----
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> Sent: Thursday, November 21, 2002 16:08
> To: Avalon Developers List
> Subject: Re: Avalon Project Hierarchy
>
> Noel J. Bergman wrote:
>
>>>The only thing that could change is the placement of Excalibur stuff in
>>>Commons, avalon-components or scratchpad.
>>
>>I'm sorry, Nicola. I know I raised this question yesterday, and I'm still
>>not understanding this particular change.
>
>
> No, I'm sorry I was not able to explain it clearly enough.
> Hmmm, I'm seeing some ASCII art, cool!
>
>
>>Looking at a "layered" view of Avalon:
>>
>> Model Current Sub-Project Proposed
>
> Sub-Project
>
> +---------------------------+ ------------------- --------------------
>
>> | Avalon Applications | Applications Components
>> +------------------------+--+
>> | Avalon Components | | Components Components
>> +=====================+--| |
>> | Avalon Container | | | Phoenix, et al Container
>> +---------------------+ | |
>> | Avalon ContainerKit | | | Excalibur Container
>> +=====================+-----|
>> | Avalon Frameworks | Frameworks Frameworks
>> +---------------------------+
>>
>>This terrible ASCII graphic
>
>
> I like it :-)
>
> Just change it to
>
> Model Current Sub-Project Proposed Sub-Project
> +---------------------------+ ----------------- --------------------
> | Avalon Applications | Applications Components or Apps
> +------------------------+--+
> | | | Excalibur stuff Components
> | Avalon Components | | +Cornerstone
> | | | ^^^^^^^^^^^^^^^^^^^^^
> +=====================+--| |
> | | | | Phoenix, et al
> | Avalon Container | | | (Excalibur) Container
> | | | | ^^^^^^^^^^^^^^^^^^^^^
> +=====================+-----|
> | Avalon Framework | Framework Framework
> +---------------------------+
>
>
>
>>is intended to show that everything sees
>>interfaces published by Avalon Frameworks, but (ideally) Components see
>
> only
>
>>Frameworks (and other Components) as exposed through the Container, and
>>Applications are (sets of) Components & configuration.
>>
>>I could see Avanon-specific Excalibur code rolled into the Container
>>sub-project that Stefano proposes, which is what I've illustrated above.
>
>
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon Project Hierarchy
Posted by "Noel J. Bergman" <no...@devtech.com>.
Nicola,
OK. So what you are saying is that Excalibur, in being "eliminated" as an
individual entity, has its Avalon-specific classes divided into two areas:
Container and Components, depending upon the type of class.
That's the entirety of our disconnect?
--- Noel
-----Original Message-----
From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
Sent: Thursday, November 21, 2002 16:08
To: Avalon Developers List
Subject: Re: Avalon Project Hierarchy
Noel J. Bergman wrote:
>>The only thing that could change is the placement of Excalibur stuff in
>>Commons, avalon-components or scratchpad.
>
> I'm sorry, Nicola. I know I raised this question yesterday, and I'm still
> not understanding this particular change.
No, I'm sorry I was not able to explain it clearly enough.
Hmmm, I'm seeing some ASCII art, cool!
> Looking at a "layered" view of Avalon:
>
> Model Current Sub-Project Proposed
Sub-Project
>
+---------------------------+ ------------------- --------------------
> | Avalon Applications | Applications Components
> +------------------------+--+
> | Avalon Components | | Components Components
> +=====================+--| |
> | Avalon Container | | | Phoenix, et al Container
> +---------------------+ | |
> | Avalon ContainerKit | | | Excalibur Container
> +=====================+-----|
> | Avalon Frameworks | Frameworks Frameworks
> +---------------------------+
>
> This terrible ASCII graphic
I like it :-)
Just change it to
Model Current Sub-Project Proposed Sub-Project
+---------------------------+ ----------------- --------------------
| Avalon Applications | Applications Components or Apps
+------------------------+--+
| | | Excalibur stuff Components
| Avalon Components | | +Cornerstone
| | | ^^^^^^^^^^^^^^^^^^^^^
+=====================+--| |
| | | | Phoenix, et al
| Avalon Container | | | (Excalibur) Container
| | | | ^^^^^^^^^^^^^^^^^^^^^
+=====================+-----|
| Avalon Framework | Framework Framework
+---------------------------+
> is intended to show that everything sees
> interfaces published by Avalon Frameworks, but (ideally) Components see
only
> Frameworks (and other Components) as exposed through the Container, and
> Applications are (sets of) Components & configuration.
>
> I could see Avanon-specific Excalibur code rolled into the Container
> sub-project that Stefano proposes, which is what I've illustrated above.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon Project Hierarchy
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Noel J. Bergman wrote:
>>The only thing that could change is the placement of Excalibur stuff in
>>Commons, avalon-components or scratchpad.
>
> I'm sorry, Nicola. I know I raised this question yesterday, and I'm still
> not understanding this particular change.
No, I'm sorry I was not able to explain it clearly enough.
Hmmm, I'm seeing some ASCII art, cool!
> Looking at a "layered" view of Avalon:
>
> Model Current Sub-Project Proposed Sub-Project
> +---------------------------+ ------------------- --------------------
> | Avalon Applications | Applications Components
> +------------------------+--+
> | Avalon Components | | Components Components
> +=====================+--| |
> | Avalon Container | | | Phoenix, et al Container
> +---------------------+ | |
> | Avalon ContainerKit | | | Excalibur Container
> +=====================+-----|
> | Avalon Frameworks | Frameworks Frameworks
> +---------------------------+
>
> This terrible ASCII graphic
I like it :-)
Just change it to
Model Current Sub-Project Proposed Sub-Project
+---------------------------+ ----------------- --------------------
| Avalon Applications | Applications Components or Apps
+------------------------+--+
| | | Excalibur stuff Components
| Avalon Components | | +Cornerstone
| | | ^^^^^^^^^^^^^^^^^^^^^
+=====================+--| |
| | | | Phoenix, et al
| Avalon Container | | | (Excalibur) Container
| | | | ^^^^^^^^^^^^^^^^^^^^^
+=====================+-----|
| Avalon Framework | Framework Framework
+---------------------------+
> is intended to show that everything sees
> interfaces published by Avalon Frameworks, but (ideally) Components see only
> Frameworks (and other Components) as exposed through the Container, and
> Applications are (sets of) Components & configuration.
>
> I could see Avanon-specific Excalibur code rolled into the Container
> sub-project that Stefano proposes, which is what I've illustrated above.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon Project Hierarchy
Posted by "Noel J. Bergman" <no...@devtech.com>.
> The only thing that could change is the placement of Excalibur stuff in
> Commons, avalon-components or scratchpad.
I'm sorry, Nicola. I know I raised this question yesterday, and I'm still
not understanding this particular change.
Looking at a "layered" view of Avalon:
Model Current Sub-Project Proposed Sub-Project
+---------------------------+ ------------------- --------------------
| Avalon Applications | Applications Components
+------------------------+--+
| Avalon Components | | Components Components
+=====================+--| |
| Avalon Container | | | Phoenix, et al Container
+---------------------+ | |
| Avalon ContainerKit | | | Excalibur Container
+=====================+-----|
| Avalon Frameworks | Frameworks Frameworks
+---------------------------+
This terrible ASCII graphic is intended to show that everything sees
interfaces published by Avalon Frameworks, but (ideally) Components see only
Frameworks (and other Components) as exposed through the Container, and
Applications are (sets of) Components & configuration.
I could see Avanon-specific Excalibur code rolled into the Container
sub-project that Stefano proposes, which is what I've illustrated above.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon Project Hierarchy
Posted by Paul Hammant <pa...@yahoo.com>.
>
> > I also object to the word "new" in any product name. I also object to the word "stable" in
> product
> > names.
> >
> > Call it ZContainer or something...
>
> Paul, are you being serious?!?
Ahh "avalon-newstablecontainer" is a place holder for another name. I see.
- Paul
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon Project Hierarchy
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Paul Hammant wrote:
> -1 (vote) for me.
>
> This is too much revolution when code is being used by real people in real companies...
* framework is already there
* components is already there, and it's called Cornerstone
* scratchpad has nothing to do with production code
* phoenix is still there
The only thing that could change is the placement of Excalibur stuff in
Commons, avalon-components or scratchpad.
What revolution are you talking about?
> I also object to the word "new" in any product name. I also object to the word "stable" in product
> names.
>
> Call it ZContainer or something...
Paul, are you being serious?!?
> - Paul
>
> --- Carsten Ziegeler <cz...@s-und-n.de> wrote: >
>
>>Nicola Ken Barozzi:
>>
>>>So we will have
>>>
>>> * avalon-framework
>>> * avalon-components
>>> * avalon-scratchpad
>>> * avalon-phoenix
>>> * avalon-newstablecontainer
>>>
>>
>>+1 for this and all the implications mentioned in the mail
>>as well (I don't want to include all of the mail here only
>>to say, I agree).
>>
>>Carsten
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon Project Hierarchy
Posted by "Noel J. Bergman" <no...@devtech.com>.
> -1 (vote) for me.
> This is too much revolution when code is being used by real people in real
companies...
Paul,
I agree with your concern, and raised it earlier. Somehow Nicola thinks
that he can resolve the packaging issues. I suggest that proposals for
re-factoring include information related to compatibility with existing
systems.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon Project Hierarchy
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Nicola Ken Barozzi wrote:
>
> Paul Hammant wrote:
...
> And each container would continue to distribute what the hack it wants?
^^^^^^
heck
> Please, let's not stumble on details, and let's be constructive.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon Project Hierarchy
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Paul Hammant wrote:
>>We use the code in a real company and I don't see any real
>>impact for us by these changes directly.
>
>
> Kew;
>
>
>>Of course, there
>>should be some "compatibility packaging", when it comes
>>to the distribution, so that you don't have to download
>>35 different jars to get the same as you now get by downloading
>>one package.
>
> Nobody downloads 35 different jars to begin a project. They download one container (which bundles
> some jars), then add others as and when. We're all doing Agilesque development these days? If
> yes, then it is possible we do not even start with the container.
Wawawawait... where did we start this 35 different jars issue?
Avalon Components would package each component separately *exactly* like
Exaclibur components for example.
And each container would continue to distribute what the hack it wants?
Please, let's not stumble on details, and let's be constructive.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon Project Hierarchy
Posted by "Noel J. Bergman" <no...@devtech.com>.
There is clearly a tension between wanting to evolve and dance nimbly, and
needing to support the installed base. However, solutions to problems are
not binary and mutually exclusive. If there are multiple conflicting
interests, then the constructive thing is to look for solutions that
accommodate all of those interests as best as possible. Such solutions
should, IMO, be as simple and elegant as possible.
>From what I have seen from archived discussions, one of the things that
everyone needs to bring to the table now is a willingness to look for viable
solutions to problems, not just raise objections to a particular proposal.
If someone sees a proposed solution that they don't like, great. But it is
important to recognize the problems that the possible flawed solution was
proposed to address, and propose alternative solutions.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon Project Hierarchy
Posted by Paul Hammant <pa...@yahoo.com>.
> We use the code in a real company and I don't see any real
> impact for us by these changes directly.
Kew;
> Of course, there
> should be some "compatibility packaging", when it comes
> to the distribution, so that you don't have to download
> 35 different jars to get the same as you now get by downloading
> one package.
Nobody downloads 35 different jars to begin a project. They download one container (which bundles
some jars), then add others as and when. We're all doing Agilesque development these days? If
yes, then it is possible we do not even start with the container.
- Paul
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon Project Hierarchy
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Paul Hammant wrote:
>
> -1 (vote) for me.
>
> This is too much revolution when code is being used by real
> people in real companies...
We use the code in a real company and I don't see any real
impact for us by these changes directly. Of course, there
should be some "compatibility packaging", when it comes
to the distribution, so that you don't have to download
35 different jars to get the same as you now get by downloading
one package.
But that's IMHO a different issue which can be solved later on.
>
> I also object to the word "new" in any product name. I also
> object to the word "stable" in product
> names.
>
Ehm, if you refer to avalon-newstablecontainer than this is
not ment to be the real name, replace "newstablecontainer"
with a name for it, like perhaps merlin or whatever.
Carsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon Project Hierarchy
Posted by Paul Hammant <pa...@yahoo.com>.
-1 (vote) for me.
This is too much revolution when code is being used by real people in real companies...
I also object to the word "new" in any product name. I also object to the word "stable" in product
names.
Call it ZContainer or something...
- Paul
--- Carsten Ziegeler <cz...@s-und-n.de> wrote: >
>
> Nicola Ken Barozzi:
> > So we will have
> >
> > * avalon-framework
> > * avalon-components
> > * avalon-scratchpad
> > * avalon-phoenix
> > * avalon-newstablecontainer
> >
> +1 for this and all the implications mentioned in the mail
> as well (I don't want to include all of the mail here only
> to say, I agree).
>
> Carsten
>
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon Project Hierarchy
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Nicola Ken Barozzi:
> So we will have
>
> * avalon-framework
> * avalon-components
> * avalon-scratchpad
> * avalon-phoenix
> * avalon-newstablecontainer
>
+1 for this and all the implications mentioned in the mail
as well (I don't want to include all of the mail here only
to say, I agree).
Carsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon Project Hierarchy
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Berin Loritsch wrote:
>>From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>>
>>
>>>* 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 nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon Project Hierarchy
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>
> > * 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon Project Hierarchy
Posted by Nicola Ken Barozzi <ni...@apache.org>.
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
> * 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.
> - 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 nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon Project Hierarchy
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Noel J. Bergman wrote:
>>The Avalon project hierarchy has a concept that works, but
>>the implementation that doesn't.
>
> I think I agree with that in concept, but I don't think that there was
> actually disagreement between Nicola and myself at all.
From a conceptual view, we seem to agree, yes.
>>For instance, from the thread "Single Avalon Implementation
>
> yes/no/why/how",
>
>>we have Noel writing:
>
>
>>> * Avalon Excalibur - a major implementation of the
>>> the Frameworks. But not the only possible one.
>>
>
>>And Nicola responding:
>
>
>>>* Excalibur is not a major implementation of the the Framework. It
>>>contains utility stuff to create containers and some
>>>containers itself.
>>
>
>>Which represents some conceptual friction.
>
>
> Nicola's correction / clarification *is* better. Nicola's correction is
> that Excalibur isn't the implementation, but is rather a collection of
> useful code used to implement containers, which (from the perspective of a
> component) is the implementation of Frameworks. And if that isn't what
> Nicola meant, then I apologize and need to re-read his message. :-)
In fact Excalibur -now- is such a module, and it contains also some
container too (it's basically a big bag ;-).
> My understanding of Nicola's approach is:
>
> - Avalon is a repository containing Framework and
> Avalon-specific utilities
>
> - There is a area for container development
>
> - There is an area for pluggable components
Yes
> I might re-cast that as:
>
> - A repository containing Framework, which
> is the Avalon contract definition. This
> is what you can count on to be present,
> or optionally present with a guaranteed
> interface, in any compliant container.
>
> - Containers, and container-specific
> components.
>
> - Portable components.
>
> - Container development. Those classes
> that are provided to aid in developing
> new containers.
Yes
> When I then look at your solution:
>
>
>>* Avalon Framework remains as is. We can look
>> at Avalon 5 later after the dust has settled.
>
>
> Agreed.
>
>
>>* 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).
>
>
>>* 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.
>
>
> I see that you and Nicola agree on this approach, but it confuses me. Why
> merge projects that seem to be at different levels within the model?
> One is
> a set of common classes used to implement containers, and the other is a set
> of components that are intended to run inside of containers. They appear,
> to me, to be two completely different categories.
Yes.
IIUC Berin wasn't thinking of merging them, but simply making Excalibur
a place for a set of components that are intended to run inside of
containers.
Thus my request to change the name to avalon-components.
> Basically, I see these categories:
>
> (1) contract exposed to components,
> (2) containers
> (3) components
>
> and common, Avalon-specific, code that can be used to develop new
> containers. This seems to be conceptually in keeping with both the current
> project notions and the various plans being proposed. Am I missing
> something?
IMHO no, this is a correct summary.
> I do agree with Nicola that using descriptive names in these
> discussions is best, regardless of what brand names may be applied to the
> projects, so maybe I am responding to a naming change, but I don't think
> that's it.
It's a radical change for Excalibur; well, effectively we are killing
it, as well as Cornerstone.
Now:
Cornerstone keeps some Components.
After:
"avalon-components" will keep them, and we should make them as
cross-container as possible
Now:
Excalibur keeps generic utility classes, Avalon utility classes,
components, containers and scratchpad stuff. Seems strange, but it is.
After:
- generic utility classes -> Jakarta or Apache Commons
- Avalon utility classes -> not sure, but they are components or
go in framework as utilities
- containers -> toplevel Avalon subprojects
- scratchpad stuff -> avalon-scratchpad
> By the way, speaking of naming changes, whatever changes occur, don't forget
> that those of us with projects already built on these technologies have both
> dependencies and inertia. Avalon is a platform. Because you have outside
> client code, you can't dance as nimbly as you might want. Packaging for
> outside consumption is an issue.
I don't want to see java package name changes just for this.
If an excalibur project will go for example to avalon-components, or a
cornerstone one, it can/should retain his package name.
It's just a matter of being clear about the Avalon projects. Package
names are not necessarily to follow suit.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon Project Hierarchy
Posted by "Noel J. Bergman" <no...@devtech.com>.
> The Avalon project hierarchy has a concept that works, but
> the implementation that doesn't.
I think I agree with that in concept, but I don't think that there was
actually disagreement between Nicola and myself at all.
> For instance, from the thread "Single Avalon Implementation
yes/no/why/how",
> we have Noel writing:
> > * Avalon Excalibur - a major implementation of the
> > the Frameworks. But not the only possible one.
> And Nicola responding:
> > * Excalibur is not a major implementation of the the Framework. It
> > contains utility stuff to create containers and some
> > containers itself.
> Which represents some conceptual friction.
Nicola's correction / clarification *is* better. Nicola's correction is
that Excalibur isn't the implementation, but is rather a collection of
useful code used to implement containers, which (from the perspective of a
component) is the implementation of Frameworks. And if that isn't what
Nicola meant, then I apologize and need to re-read his message. :-)
My understanding of Nicola's approach is:
- Avalon is a repository containing Framework and
Avalon-specific utilities
- There is a area for container development
- There is an area for pluggable components
I might re-cast that as:
- A repository containing Framework, which
is the Avalon contract definition. This
is what you can count on to be present,
or optionally present with a guaranteed
interface, in any compliant container.
- Containers, and container-specific
components.
- Portable components.
- Container development. Those classes
that are provided to aid in developing
new containers.
When I then look at your solution:
> * Avalon Framework remains as is. We can look
> at Avalon 5 later after the dust has settled.
Agreed.
> * 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).
> * 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.
I see that you and Nicola agree on this approach, but it confuses me. Why
merge projects that seem to be at different levels within the model? One is
a set of common classes used to implement containers, and the other is a set
of components that are intended to run inside of containers. They appear,
to me, to be two completely different categories.
Basically, I see these categories:
(1) contract exposed to components,
(2) containers
(3) components
and common, Avalon-specific, code that can be used to develop new
containers. This seems to be conceptually in keeping with both the current
project notions and the various plans being proposed. Am I missing
something? I do agree with Nicola that using descriptive names in these
discussions is best, regardless of what brand names may be applied to the
projects, so maybe I am responding to a naming change, but I don't think
that's it.
By the way, speaking of naming changes, whatever changes occur, don't forget
that those of us with projects already built on these technologies have both
dependencies and inertia. Avalon is a platform. Because you have outside
client code, you can't dance as nimbly as you might want. Packaging for
outside consumption is an issue.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon Project Hierarchy
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>> * Avalon Framework remains as is. We can look at Avalon 5 later after
>> the dust has settled.
>
>
> this *MUST NOT CHANGE*. i realize the impetus that was behind the move
> to Serviceable and the dropping of the Component interface. IMHO, in
> hindsight, this was a VERY BAD idea. Not conceptually, but
> practically, because now everyone must move over or face massive
> deprecation warnings, which is not good. The empty marker interface
> could easily be provided by dynamic proxies. But what is done is done.
> we need to leave the A-F interfaces *SET IN STONE* so we have a
> foundation to build upon.
I'd agree to the extent of saying "as little as possible", or "nothing
that breaks back-compat". However at the time of the servicable change,
nobody knew that the the faking of Component was possible. It was a
revaltion to me on the JAMES list when Peter pointed out that he had
wrapped all components (small c) with Component makers in Phoenix 4.0.
It is imperfect though.
>> * 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).
>
Given Excalibur (ignoring Merlin which should get a more prominent
position at Apache) is largely a set of beans, I see that as a massive
change to its remit.
> I'd like to see Excalibur either
>
> a) move to Apache Commons
Where the beans are very reusable, yes.
> or
>
> b) have a separate committer list, so individuals from A-F consumer
> projects could be involved in the component library. Basically opening
> it wide up for wider involvement.
+1
>> * 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.
>
>
> +1
+1
>> * 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
being disucssed elsewhere.
>> * 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.
>
We have agreed to eliminate many of these. Many more are very good
demos of component design.
> Agreed. Some things can go to the scratchpad (phyre, for one... kinda
> shelved for the moment unfortunately, but it will rise again!)
I'm guilty of this too.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Avalon Project Hierarchy
Posted by Peter Royal <pr...@apache.org>.
On Wednesday, November 20, 2002, at 09:55 AM, Berin Loritsch wrote:
> * Avalon Framework remains as is. We can look at Avalon 5 later after
> the dust has settled.
this *MUST NOT CHANGE*. i realize the impetus that was behind the move
to Serviceable and the dropping of the Component interface. IMHO, in
hindsight, this was a VERY BAD idea. Not conceptually, but practically,
because now everyone must move over or face massive deprecation
warnings, which is not good. The empty marker interface could easily be
provided by dynamic proxies. But what is done is done. we need to leave
the A-F interfaces *SET IN STONE* so we have a foundation to build upon.
> * 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 like to see Excalibur either
a) move to Apache Commons
or
b) have a separate committer list, so individuals from A-F consumer
projects could be involved in the component library. Basically opening
it wide up for wider involvement.
> * 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.
+1
> * 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
> * 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.
Agreed. Some things can go to the scratchpad (phyre, for one... kinda
shelved for the moment unfortunately, but it will rise again!)
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>