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/12/02 17:36:53 UTC
[VOTE] New Development Direction
This is a vote to clarify whether we want to focus all
our discussions of the new unified container to Avalon 5
(next generation) or Avalon 4.1 (current generation).
Here are the implications:
Avalon 4.1
----------
Current development. We refine current interfaces so that
the contracts are more universal and testable. This includes
the semantics we have surrounding Context and Serviceable.
It also means that we can't clean up the cruft. (deprecated
stuff remains deprecated).
Avalon 5
--------
New development/clean slate. We leverage our experience with
lifecycle interfaces to provide a starting point, but we do
not limit ourselves to that alone. We can clean up the cruft,
but we must supply a "Compatibility JAR" to allow easy migration
from Avalon 4.1 to Avalon 5. We can also shorten the package
names (minor, but sometimes helpful). It also helps us unify
on a new product.
If we continue version 4.1 development we don't have the
luxury of challenging any of the current lifecycle interfaces
or making things just simply easier to use.
Implied in either action is that the existing containers continue
to live their lives until the new container is complete.
Which is it? Unified Container == Avalon 4.1 or Avalon 5?
(Voting to remain open as long as necessary [not less than a
week]).
Please provide a quick comment why you made your choice (either
way).
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] New Development Direction
Posted by Marcus Crafter <cr...@fztig938.bank.dresdner.net>.
On Mon, Dec 02, 2002 at 11:36:53AM -0500, Berin Loritsch wrote:
> Avalon 5
> --------
> New development/clean slate. We leverage our experience with
> lifecycle interfaces to provide a starting point, but we do
> not limit ourselves to that alone. We can clean up the cruft,
> but we must supply a "Compatibility JAR" to allow easy migration
> from Avalon 4.1 to Avalon 5. We can also shorten the package
> names (minor, but sometimes helpful). It also helps us unify
> on a new product.
+1. I think now is a good time to do the above. Since we are
embarking on a fresh container effort, the time feels right (IMO) to
re-evaluate the contracts under which it runs.
> Implied in either action is that the existing containers continue
> to live their lives until the new container is complete.
+1. Glad you made that point.
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] New Development Direction
Posted by Marcus Crafter <cr...@fztig938.bank.dresdner.net>.
On Mon, Dec 02, 2002 at 11:36:53AM -0500, Berin Loritsch wrote:
> Avalon 5
> --------
> New development/clean slate. We leverage our experience with
> lifecycle interfaces to provide a starting point, but we do
> not limit ourselves to that alone. We can clean up the cruft,
> but we must supply a "Compatibility JAR" to allow easy migration
> from Avalon 4.1 to Avalon 5. We can also shorten the package
> names (minor, but sometimes helpful). It also helps us unify
> on a new product.
+1. I think now is a good time to do the above. Since we are
embarking on a fresh container effort, the time feels right (IMO) to
re-evaluate the contracts under which it runs.
> Implied in either action is that the existing containers continue
> to live their lives until the new container is complete.
+1. Glad you made that point.
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] New Development Direction
Posted by "Noel J. Bergman" <no...@devtech.com>.
My suggestion is that the first step be to look at the architecture for
Avalon 5, clean it up, and talk with your clients to see what we think (as
well as see what you think). Right now a lot of discussions are braked by
issues over how things are done now, rather than the right way to do things.
If people like the new approach(es), then iterate over the various phases of
architecture, design and implementation. I think that you'll find that if
Avalon 5 is substantially cleaner, leaner, easier, faster, etc., than Avalon
4 then we will not be unhappy. My guess is that the Framework interfaces
will be relatively stable except in a few areas; most of the major change
will be in how the profile-based container works.
Peter talks about doing more work on Avalon 4 as a learning exercise. Well,
you've already learned a lot, and you'll always be learning new things. The
profile approach to container building should enable more rapid development.
And no one has said that the code would be written from scratch. It doesn't
make sense to talk about code until you get to that point.
Plus, you'll have continued incremental changes on the 4.x series, a
migration plan for Avalon 5 (Avalon/V?), and use of the current containers
to prototype the new contracts. What's the downside?
This seems like a good time to for clients to prepare for a new approach to
Avalon, as well. James is preparing for a major overhaul (we'll see how
much actual re-coding we do, but we are giving ourselves permission to make
major changes). Sounds like Cocoon has a major release planned (did I hear
about a v3?). Don't know about other client projects, but the developers
ought to be invited to the discussion. All programs should be
client-driven, Avalon especially so since it exists only as a platform for
client code.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] New Development Direction
Posted by "Noel J. Bergman" <no...@devtech.com>.
My suggestion is that the first step be to look at the architecture for
Avalon 5, clean it up, and talk with your clients to see what we think (as
well as see what you think). Right now a lot of discussions are braked by
issues over how things are done now, rather than the right way to do things.
If people like the new approach(es), then iterate over the various phases of
architecture, design and implementation. I think that you'll find that if
Avalon 5 is substantially cleaner, leaner, easier, faster, etc., than Avalon
4 then we will not be unhappy. My guess is that the Framework interfaces
will be relatively stable except in a few areas; most of the major change
will be in how the profile-based container works.
Peter talks about doing more work on Avalon 4 as a learning exercise. Well,
you've already learned a lot, and you'll always be learning new things. The
profile approach to container building should enable more rapid development.
And no one has said that the code would be written from scratch. It doesn't
make sense to talk about code until you get to that point.
Plus, you'll have continued incremental changes on the 4.x series, a
migration plan for Avalon 5 (Avalon/V?), and use of the current containers
to prototype the new contracts. What's the downside?
This seems like a good time to for clients to prepare for a new approach to
Avalon, as well. James is preparing for a major overhaul (we'll see how
much actual re-coding we do, but we are giving ourselves permission to make
major changes). Sounds like Cocoon has a major release planned (did I hear
about a v3?). Don't know about other client projects, but the developers
ought to be invited to the discussion. All programs should be
client-driven, Avalon especially so since it exists only as a platform for
client code.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] New Development Direction
Posted by "Noel J. Bergman" <no...@devtech.com>.
My suggestion is that the first step be to look at the architecture for
Avalon 5, clean it up, and talk with your clients to see what we think (as
well as see what you think). Right now a lot of discussions are braked by
issues over how things are done now, rather than the right way to do things.
If people like the new approach(es), then iterate over the various phases of
architecture, design and implementation. I think that you'll find that if
Avalon 5 is substantially cleaner, leaner, easier, faster, etc., than Avalon
4 then we will not be unhappy. My guess is that the Framework interfaces
will be relatively stable except in a few areas; most of the major change
will be in how the profile-based container works.
Peter talks about doing more work on Avalon 4 as a learning exercise. Well,
you've already learned a lot, and you'll always be learning new things. The
profile approach to container building should enable more rapid development.
And no one has said that the code would be written from scratch. It doesn't
make sense to talk about code until you get to that point.
Plus, you'll have continued incremental changes on the 4.x series, a
migration plan for Avalon 5 (Avalon/V?), and use of the current containers
to prototype the new contracts. What's the downside?
This seems like a good time to for clients to prepare for a new approach to
Avalon, as well. James is preparing for a major overhaul (we'll see how
much actual re-coding we do, but we are giving ourselves permission to make
major changes). Sounds like Cocoon has a major release planned (did I hear
about a v3?). Don't know about other client projects, but the developers
ought to be invited to the discussion. All programs should be
client-driven, Avalon especially so since it exists only as a platform for
client code.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] New Development Direction
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leif Mortenson wrote:
> Berin Loritsch wrote:
>
>> Avalon 5
>> --------
>>
> +1
> I think this would go along well with the new ubercontainer. Lets make
> sure to
> provide a good upgrade path. I'll admit, I am still using the ECM with
> components
> implemented as services on most of my projects... Using the ECMC it is
> quite
> easy to use and is stable.
>
> At some point though I also need to move over, but I have also needed to
> get
> the work paying the bills done and needed something stable to work with.
>
> Where possible, lets try to maintain class and package names so that as
> much
> user code as possible can be used in Avalon 5 without changes.
>
> While doing something new is more fun than maintaining old code, lets make
> sure and all remember the large number of users depending on the APIs that
> we produce. :-)
Thanks Leif for lending me the words to explain better my position.
+1 to the 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: [VOTE] New Development Direction
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leif Mortenson wrote:
> Berin Loritsch wrote:
>
>> Avalon 5
>> --------
>>
> +1
> I think this would go along well with the new ubercontainer. Lets make
> sure to
> provide a good upgrade path. I'll admit, I am still using the ECM with
> components
> implemented as services on most of my projects... Using the ECMC it is
> quite
> easy to use and is stable.
>
> At some point though I also need to move over, but I have also needed to
> get
> the work paying the bills done and needed something stable to work with.
>
> Where possible, lets try to maintain class and package names so that as
> much
> user code as possible can be used in Avalon 5 without changes.
>
> While doing something new is more fun than maintaining old code, lets make
> sure and all remember the large number of users depending on the APIs that
> we produce. :-)
Thanks Leif for lending me the words to explain better my position.
+1 to the 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: [VOTE] New Development Direction
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leif Mortenson wrote:
> Berin Loritsch wrote:
>
>> Avalon 5
>> --------
>>
> +1
> I think this would go along well with the new ubercontainer. Lets make
> sure to
> provide a good upgrade path. I'll admit, I am still using the ECM with
> components
> implemented as services on most of my projects... Using the ECMC it is
> quite
> easy to use and is stable.
>
> At some point though I also need to move over, but I have also needed to
> get
> the work paying the bills done and needed something stable to work with.
>
> Where possible, lets try to maintain class and package names so that as
> much
> user code as possible can be used in Avalon 5 without changes.
>
> While doing something new is more fun than maintaining old code, lets make
> sure and all remember the large number of users depending on the APIs that
> we produce. :-)
Thanks Leif for lending me the words to explain better my position.
+1 to the 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: [VOTE] New Development Direction
Posted by Leif Mortenson <le...@tanukisoftware.com>.
Berin Loritsch wrote:
>Avalon 5
>--------
>
+1
I think this would go along well with the new ubercontainer. Lets make
sure to
provide a good upgrade path. I'll admit, I am still using the ECM with
components
implemented as services on most of my projects... Using the ECMC it is
quite
easy to use and is stable.
At some point though I also need to move over, but I have also needed to get
the work paying the bills done and needed something stable to work with.
Where possible, lets try to maintain class and package names so that as much
user code as possible can be used in Avalon 5 without changes.
While doing something new is more fun than maintaining old code, lets make
sure and all remember the large number of users depending on the APIs that
we produce. :-)
Cheers,
Leif
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] New Development Direction
Posted by Peter Donald <pe...@realityforge.org>.
On Tue, 3 Dec 2002 14:49, Berin Loritsch wrote:
> Peter Donald wrote:
> >Why don't we do both? It is more important to develope a model for 4.1 and
> >continue enhance that where it is required. We can always keep a
> > Framework5 revolution in mind but I think that will fall out of things we
> > do for Framework4.x. ie As we find uglies in Framework4.x we add them to
> > a list of things that we should fix in Framework5.x and if by the time
> > 4.x is finished the list is big enough we move to Framework5.x
>
> We haven't significantly changed Framework 4.1 for a long time. By
> adding more semantic clarification
> to Framework 4.1, we are effectively defining a 4.2 which is still a new
> version. Dividing our interests
> between 4.2, 5.0 and 4.1 would be too much work. Maintaining 4.1 while
> developing 5.0 is a better
> use of our limited resources.
I disagree. 5.0 is a big step and I would want to completely remove large
chunks that were essentially failed experiments. So there needs to be a lot
longer incubation time with 5.0 before it will be ready to be adopted.
However 4.x can easily be improved in the meantime and while improving it we
can always store up a list of things that we find that we would like to kill
in 5.0. The good thing is that these things are motivated by real needs
rather than pie in the sky wants
--
Cheers,
Peter Donald
-----------------------------------------------
"Only two things are infinite, the universe and
human stupidity, and I'm not sure about the
former." -Albert Einstein
-----------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] New Development Direction
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Peter Donald wrote:
>
>> Why don't we do both? It is more important to develope a model for
>> 4.1 and continue enhance that where it is required. We can always
>> keep a Framework5 revolution in mind but I think that will fall out
>> of things we do for Framework4.x. ie As we find uglies in
>> Framework4.x we add them to a list of things that we should fix in
>> Framework5.x and if by the time 4.x is finished the list is big
>> enough we move to Framework5.x
>>
>
> We haven't significantly changed Framework 4.1 for a long time. By
> adding more semantic clarification
> to Framework 4.1, we are effectively defining a 4.2 which is still a
> new version. Dividing our interests
> between 4.2, 5.0 and 4.1 would be too much work. Maintaining 4.1
> while developing 5.0 is a better
> use of our limited resources.
And perhaps the maintainace of 4.1 while developing 4.2 is possibly
closer to invested interests.
;-)
>
>
> ---------------------------------------------
> Introducing NetZero Long Distance
> 1st month Free!
> Sign up today at: www.netzerolongdistance.com
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] New Development Direction
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
>Why don't we do both? It is more important to develope a model for 4.1 and
>continue enhance that where it is required. We can always keep a Framework5
>revolution in mind but I think that will fall out of things we do for
>Framework4.x. ie As we find uglies in Framework4.x we add them to a list of
>things that we should fix in Framework5.x and if by the time 4.x is finished
>the list is big enough we move to Framework5.x
>
We haven't significantly changed Framework 4.1 for a long time. By
adding more semantic clarification
to Framework 4.1, we are effectively defining a 4.2 which is still a new
version. Dividing our interests
between 4.2, 5.0 and 4.1 would be too much work. Maintaining 4.1 while
developing 5.0 is a better
use of our limited resources.
---------------------------------------------
Introducing NetZero Long Distance
1st month Free!
Sign up today at: www.netzerolongdistance.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] New Development Direction
Posted by Peter Donald <pe...@realityforge.org>.
Why don't we do both? It is more important to develope a model for 4.1 and
continue enhance that where it is required. We can always keep a Framework5
revolution in mind but I think that will fall out of things we do for
Framework4.x. ie As we find uglies in Framework4.x we add them to a list of
things that we should fix in Framework5.x and if by the time 4.x is finished
the list is big enough we move to Framework5.x
On Tue, 3 Dec 2002 03:36, Berin Loritsch wrote:
> This is a vote to clarify whether we want to focus all
> our discussions of the new unified container to Avalon 5
> (next generation) or Avalon 4.1 (current generation).
> Here are the implications:
>
> Avalon 4.1
> ----------
> Current development. We refine current interfaces so that
> the contracts are more universal and testable. This includes
> the semantics we have surrounding Context and Serviceable.
> It also means that we can't clean up the cruft. (deprecated
> stuff remains deprecated).
>
> Avalon 5
> --------
> New development/clean slate. We leverage our experience with
> lifecycle interfaces to provide a starting point, but we do
> not limit ourselves to that alone. We can clean up the cruft,
> but we must supply a "Compatibility JAR" to allow easy migration
> from Avalon 4.1 to Avalon 5. We can also shorten the package
> names (minor, but sometimes helpful). It also helps us unify
> on a new product.
>
> If we continue version 4.1 development we don't have the
> luxury of challenging any of the current lifecycle interfaces
> or making things just simply easier to use.
>
> Implied in either action is that the existing containers continue
> to live their lives until the new container is complete.
>
>
> Which is it? Unified Container == Avalon 4.1 or Avalon 5?
>
>
> (Voting to remain open as long as necessary [not less than a
> week]).
>
> Please provide a quick comment why you made your choice (either
> way).
--
Cheers,
Peter Donald
*------------------------------------------------*
| The student who is never required to do what |
| he cannot do never does what he can do. |
| - John Stuart Mill |
*------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] New Development Direction
Posted by Leif Mortenson <le...@tanukisoftware.com>.
Berin Loritsch wrote:
>Avalon 5
>--------
>
+1
I think this would go along well with the new ubercontainer. Lets make
sure to
provide a good upgrade path. I'll admit, I am still using the ECM with
components
implemented as services on most of my projects... Using the ECMC it is
quite
easy to use and is stable.
At some point though I also need to move over, but I have also needed to get
the work paying the bills done and needed something stable to work with.
Where possible, lets try to maintain class and package names so that as much
user code as possible can be used in Avalon 5 without changes.
While doing something new is more fun than maintaining old code, lets make
sure and all remember the large number of users depending on the APIs that
we produce. :-)
Cheers,
Leif
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] New Development Direction
Posted by Leif Mortenson <le...@tanukisoftware.com>.
Berin Loritsch wrote:
>Avalon 5
>--------
>
+1
I think this would go along well with the new ubercontainer. Lets make
sure to
provide a good upgrade path. I'll admit, I am still using the ECM with
components
implemented as services on most of my projects... Using the ECMC it is
quite
easy to use and is stable.
At some point though I also need to move over, but I have also needed to get
the work paying the bills done and needed something stable to work with.
Where possible, lets try to maintain class and package names so that as much
user code as possible can be used in Avalon 5 without changes.
While doing something new is more fun than maintaining old code, lets make
sure and all remember the large number of users depending on the APIs that
we produce. :-)
Cheers,
Leif
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] New Development Direction
Posted by Marcus Crafter <cr...@fztig938.bank.dresdner.net>.
On Mon, Dec 02, 2002 at 11:36:53AM -0500, Berin Loritsch wrote:
> Avalon 5
> --------
> New development/clean slate. We leverage our experience with
> lifecycle interfaces to provide a starting point, but we do
> not limit ourselves to that alone. We can clean up the cruft,
> but we must supply a "Compatibility JAR" to allow easy migration
> from Avalon 4.1 to Avalon 5. We can also shorten the package
> names (minor, but sometimes helpful). It also helps us unify
> on a new product.
+1. I think now is a good time to do the above. Since we are
embarking on a fresh container effort, the time feels right (IMO) to
re-evaluate the contracts under which it runs.
> Implied in either action is that the existing containers continue
> to live their lives until the new container is complete.
+1. Glad you made that point.
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] New Development Direction
Posted by Stephen McConnell <mc...@apache.org>.
Just taking care of paperwork - my vote on this is +1 on Avalon 5.
Cheers, Steve.
Stephen McConnell wrote:
>
> Berin:
>
> I think that there is a problem with the subject you are
> requesting a vote on.
>
> * There is the issue of the evolution of the Avalon
> component API specification - refining, evolving,
> based on what we have. Wether this is 4.3, 5 or
> 6 is not the issue - the issue is identification
> is problems and resolution of solutions.
>
> * There is the issue of the container framework. This
> does not need 5, 6 or whatever - what we have at the
> client contract level has only a minimal impact on
> the objective of a common containement architecture
> and profile based containers.
>
> If you were to rephrase the question along the lines of
> "are we starting out with a clean sheet of paper" with
> respect to containerment architecture then I'm totally
> with with you. That process will result in resolution
> and evolution of the avalon framework contract.
>
> Cheers, Steve.
>
>
> Berin Loritsch wrote:
>
>> This is a vote to clarify whether we want to focus all
>> our discussions of the new unified container to Avalon 5
>> (next generation) or Avalon 4.1 (current generation).
>> Here are the implications:
>>
>> Avalon 4.1
>> ----------
>> Current development. We refine current interfaces so that
>> the contracts are more universal and testable. This includes
>> the semantics we have surrounding Context and Serviceable.
>> It also means that we can't clean up the cruft. (deprecated
>> stuff remains deprecated).
>>
>> Avalon 5
>> --------
>> New development/clean slate. We leverage our experience with
>> lifecycle interfaces to provide a starting point, but we do
>> not limit ourselves to that alone. We can clean up the cruft,
>> but we must supply a "Compatibility JAR" to allow easy migration
>> from Avalon 4.1 to Avalon 5. We can also shorten the package
>> names (minor, but sometimes helpful). It also helps us unify
>> on a new product.
>>
>> If we continue version 4.1 development we don't have the
>> luxury of challenging any of the current lifecycle interfaces
>> or making things just simply easier to use.
>>
>> Implied in either action is that the existing containers continue
>> to live their lives until the new container is complete.
>>
>>
>> Which is it? Unified Container == Avalon 4.1 or Avalon 5?
>>
>>
>> (Voting to remain open as long as necessary [not less than a
>> week]).
>>
>> Please provide a quick comment why you made your choice (either
>> way).
>>
>> --
>> To unsubscribe, e-mail:
>> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
>> <ma...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] New Development Direction
Posted by Stephen McConnell <mc...@apache.org>.
Just taking care of paperwork - my vote on this is +1 on Avalon 5.
Cheers, Steve.
Stephen McConnell wrote:
>
> Berin:
>
> I think that there is a problem with the subject you are
> requesting a vote on.
>
> * There is the issue of the evolution of the Avalon
> component API specification - refining, evolving,
> based on what we have. Wether this is 4.3, 5 or
> 6 is not the issue - the issue is identification
> is problems and resolution of solutions.
>
> * There is the issue of the container framework. This
> does not need 5, 6 or whatever - what we have at the
> client contract level has only a minimal impact on
> the objective of a common containement architecture
> and profile based containers.
>
> If you were to rephrase the question along the lines of
> "are we starting out with a clean sheet of paper" with
> respect to containerment architecture then I'm totally
> with with you. That process will result in resolution
> and evolution of the avalon framework contract.
>
> Cheers, Steve.
>
>
> Berin Loritsch wrote:
>
>> This is a vote to clarify whether we want to focus all
>> our discussions of the new unified container to Avalon 5
>> (next generation) or Avalon 4.1 (current generation).
>> Here are the implications:
>>
>> Avalon 4.1
>> ----------
>> Current development. We refine current interfaces so that
>> the contracts are more universal and testable. This includes
>> the semantics we have surrounding Context and Serviceable.
>> It also means that we can't clean up the cruft. (deprecated
>> stuff remains deprecated).
>>
>> Avalon 5
>> --------
>> New development/clean slate. We leverage our experience with
>> lifecycle interfaces to provide a starting point, but we do
>> not limit ourselves to that alone. We can clean up the cruft,
>> but we must supply a "Compatibility JAR" to allow easy migration
>> from Avalon 4.1 to Avalon 5. We can also shorten the package
>> names (minor, but sometimes helpful). It also helps us unify
>> on a new product.
>>
>> If we continue version 4.1 development we don't have the
>> luxury of challenging any of the current lifecycle interfaces
>> or making things just simply easier to use.
>>
>> Implied in either action is that the existing containers continue
>> to live their lives until the new container is complete.
>>
>>
>> Which is it? Unified Container == Avalon 4.1 or Avalon 5?
>>
>>
>> (Voting to remain open as long as necessary [not less than a
>> week]).
>>
>> Please provide a quick comment why you made your choice (either
>> way).
>>
>> --
>> To unsubscribe, e-mail:
>> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
>> <ma...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] New Development Direction
Posted by Stephen McConnell <mc...@apache.org>.
Just taking care of paperwork - my vote on this is +1 on Avalon 5.
Cheers, Steve.
Stephen McConnell wrote:
>
> Berin:
>
> I think that there is a problem with the subject you are
> requesting a vote on.
>
> * There is the issue of the evolution of the Avalon
> component API specification - refining, evolving,
> based on what we have. Wether this is 4.3, 5 or
> 6 is not the issue - the issue is identification
> is problems and resolution of solutions.
>
> * There is the issue of the container framework. This
> does not need 5, 6 or whatever - what we have at the
> client contract level has only a minimal impact on
> the objective of a common containement architecture
> and profile based containers.
>
> If you were to rephrase the question along the lines of
> "are we starting out with a clean sheet of paper" with
> respect to containerment architecture then I'm totally
> with with you. That process will result in resolution
> and evolution of the avalon framework contract.
>
> Cheers, Steve.
>
>
> Berin Loritsch wrote:
>
>> This is a vote to clarify whether we want to focus all
>> our discussions of the new unified container to Avalon 5
>> (next generation) or Avalon 4.1 (current generation).
>> Here are the implications:
>>
>> Avalon 4.1
>> ----------
>> Current development. We refine current interfaces so that
>> the contracts are more universal and testable. This includes
>> the semantics we have surrounding Context and Serviceable.
>> It also means that we can't clean up the cruft. (deprecated
>> stuff remains deprecated).
>>
>> Avalon 5
>> --------
>> New development/clean slate. We leverage our experience with
>> lifecycle interfaces to provide a starting point, but we do
>> not limit ourselves to that alone. We can clean up the cruft,
>> but we must supply a "Compatibility JAR" to allow easy migration
>> from Avalon 4.1 to Avalon 5. We can also shorten the package
>> names (minor, but sometimes helpful). It also helps us unify
>> on a new product.
>>
>> If we continue version 4.1 development we don't have the
>> luxury of challenging any of the current lifecycle interfaces
>> or making things just simply easier to use.
>>
>> Implied in either action is that the existing containers continue
>> to live their lives until the new container is complete.
>>
>>
>> Which is it? Unified Container == Avalon 4.1 or Avalon 5?
>>
>>
>> (Voting to remain open as long as necessary [not less than a
>> week]).
>>
>> Please provide a quick comment why you made your choice (either
>> way).
>>
>> --
>> To unsubscribe, e-mail:
>> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
>> <ma...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] New Development Direction
Posted by Stephen McConnell <mc...@apache.org>.
Berin:
I think that there is a problem with the subject you are
requesting a vote on.
* There is the issue of the evolution of the Avalon
component API specification - refining, evolving,
based on what we have. Wether this is 4.3, 5 or
6 is not the issue - the issue is identification
is problems and resolution of solutions.
* There is the issue of the container framework. This
does not need 5, 6 or whatever - what we have at the
client contract level has only a minimal impact on
the objective of a common containement architecture
and profile based containers.
If you were to rephrase the question along the lines of
"are we starting out with a clean sheet of paper" with
respect to containerment architecture then I'm totally
with with you. That process will result in resolution
and evolution of the avalon framework contract.
Cheers, Steve.
Berin Loritsch wrote:
>This is a vote to clarify whether we want to focus all
>our discussions of the new unified container to Avalon 5
>(next generation) or Avalon 4.1 (current generation).
>Here are the implications:
>
>Avalon 4.1
>----------
>Current development. We refine current interfaces so that
>the contracts are more universal and testable. This includes
>the semantics we have surrounding Context and Serviceable.
>It also means that we can't clean up the cruft. (deprecated
>stuff remains deprecated).
>
>Avalon 5
>--------
>New development/clean slate. We leverage our experience with
>lifecycle interfaces to provide a starting point, but we do
>not limit ourselves to that alone. We can clean up the cruft,
>but we must supply a "Compatibility JAR" to allow easy migration
>from Avalon 4.1 to Avalon 5. We can also shorten the package
>names (minor, but sometimes helpful). It also helps us unify
>on a new product.
>
>If we continue version 4.1 development we don't have the
>luxury of challenging any of the current lifecycle interfaces
>or making things just simply easier to use.
>
>Implied in either action is that the existing containers continue
>to live their lives until the new container is complete.
>
>
>Which is it? Unified Container == Avalon 4.1 or Avalon 5?
>
>
>(Voting to remain open as long as necessary [not less than a
>week]).
>
>Please provide a quick comment why you made your choice (either
>way).
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] New Development Direction
Posted by Berin Loritsch <bl...@citi-us.com>.
Point taken, Paul.
Keep in mind that compliance is measured in
terms of Framework version. If a container is 4.1 compliant,
then it is compliant to Avalon Framework 4.1 specifications.
If a container is 5.0 compliant, then it is compliant to Avalon
Framework 5.0 specifications.
We will have to write Avalon Framework 5.0, and the compliant
container if we choose that path. We haven't discussed naming
yet, and we are determining which Framework version we are
working to be compatible with.
> From: Paul Hammant [mailto:paul_hammant@yahoo.com]
>
> > > Which is it? Unified Container == Avalon 4.1 or Avalon 5?
> >
> > +1 for Avalon 5
> >
> > It provides a new platform to build a unified community, and
> > clean up cruft so we have nothing deprecated. It also provides
> > opportunity to get input from other Apache communities to help
> > shape our decisions.
>
> We will have to be *real* careful with our naming. Are we
> still going to refer to the interfaces
> as Avalon-Framework ? Or are they Avalon too. I really think
> we need to have a different name for
> the uber container as there are people out there that use the
> interfaces in their internal
> mainable() projects.
>
> IMHO..
> Avalon == group of projects
> Avalon-Framework == lifecycle interfaces (our art)
> Containix == the reference ubercontainer
> Avalon-Phoenix == a generation 1 container, wound down when
> Containix reaches 1.0
>
> There is already enough confusion without making...
>
> group-of-projects == framework == reference container
>
> -ph
>
> __________________________________________________
> 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: [VOTE] New Development Direction
Posted by Paul Hammant <pa...@yahoo.com>.
> > Which is it? Unified Container == Avalon 4.1 or Avalon 5?
>
> +1 for Avalon 5
>
> It provides a new platform to build a unified community, and
> clean up cruft so we have nothing deprecated. It also provides
> opportunity to get input from other Apache communities to help
> shape our decisions.
We will have to be *real* careful with our naming. Are we still going to refer to the interfaces
as Avalon-Framework ? Or are they Avalon too. I really think we need to have a different name for
the uber container as there are people out there that use the interfaces in their internal
mainable() projects.
IMHO..
Avalon == group of projects
Avalon-Framework == lifecycle interfaces (our art)
Containix == the reference ubercontainer
Avalon-Phoenix == a generation 1 container, wound down when Containix reaches 1.0
There is already enough confusion without making...
group-of-projects == framework == reference container
-ph
__________________________________________________
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: [VOTE] New Development Direction
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Berin Loritsch [mailto:bloritsch@citi-us.com]
<snip/>
> Which is it? Unified Container == Avalon 4.1 or Avalon 5?
+1 for Avalon 5
It provides a new platform to build a unified community, and
clean up cruft so we have nothing deprecated. It also provides
opportunity to get input from other Apache communities to help
shape our decisions.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] New Development Direction
Posted by "Noel J. Bergman" <no...@devtech.com>.
As an Avalon client, I (non-)"vote" for Avalon 5.
For one thing, the current discussions indicate that consensus and clarity
needs to be regained on fundamental architectural issues.
As a part of moving towards Avalon 5, I'd like to see the core notions
revisited and clarified as an essential exercise towards defining the
architecture and design. Avalon 4.1 would not have that same freedom. This
should not be interpreted as throwing out the old, but it seems to me that
if the currently implemented ideas were as clear, well-defined, and agreed
upon as they ought to be, that the current discussions amongst long time
Avalon members wouldn't differ on architectural issues.
I agree that "existing containers continue to live their lives until the new
container is complete." Existing containers should also be used to
prototype the external contracts while the new internals are being readied.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] New Development Direction
Posted by Peter Royal <pr...@apache.org>.
On Monday, December 2, 2002, at 11:36 AM, Berin Loritsch wrote:
> Which is it? Unified Container == Avalon 4.1 or Avalon 5?
>
Avalon 4.5
There are many many people building atop of the 4.x framework. We owe
it to our users to keep a stable base. I would like to see the unified
container built upon the current framework. This is so that James,
Phoenix, Cocoon and any other consumers will have a DEAD SIMPLE
migration path.
First lets bring everything together, make it a cohesive whole, and
then take the giant step forward together. If we don't build upon the
framework that we already have, the unified container discussions will
get bogged down in what the 5.0 framework should entail.
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>