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/26 15:14:21 UTC
[VOTE] Plans to move ahead
Nothing I am saying is particularly new here. However, before we
can jump into the nitty gritty details about what the API and
contracts should look like, we need to gain consensus on the
general direction. No matter what the course, I am willing to
help achieve the end goal. Let's get this out of the way before
we finalize Context contracts, start coding, etc.
Development Plan 1:
We continue to support our existing projects while we start fresh
on a new effort. The new effort will be a scalable container that
follows a "profile". Basically the container will only use the
features that are part of that profile and ignore everything else.
PROS: It is new code that we as a team must work together on. We
will have just as much functionality as we want without
worrying about functionality we don't want.
CONS: It requires a more complex validation layer (i.e. we need to
make sure that components that are used do not *require* the
functionality we left out of the profile).
Development Plan 2:
We adapt our current projects to the three/four tiered approach
(Tutorial, Micro, Standard, Enterprise). This is probably an easier
migration path, and it would leverage the existing code that we
already have.
PROS: It uses existing code to build upon. It is easier for a user
to determine what type of container that they need for the set
of components they are using.
CONS: It isn't new development, so there is potential for "my way is
better" conflicts. We may actually be more difficult to
determine consensus on the particulars of container/component
contracts.
Which way do we as a community want to support? Once we have the
general plan, let's put together the infrastructure and focus on it.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Plans to move ahead
Posted by Stefano Mazzocchi <st...@apache.org>.
Stephen McConnell wrote:
>
> My preferred position is to go with plan [1].
> While I think that is the worst-case-scenario concerning "Merlin",
> "Fortress", or "Phoneix" centric product development, I also think
> it is the only scenario for a community owned solution.
>
> I do believe that plan [1] will enivatibly involve pulling the best of
> existing containters and container related resources together, and
> in that respect I see the potential for something much more valuable
> comming out of the process.
>
> I do not see this as conflicting with ongoing requirements concerning
> support of the Phoenix commuity - in fact this is similar to the
> requirements we have for supporting ECM user migration. End result is
> the migration of all of our users to a single common container
> architecture - a.k.a. everyone wins.
I completely share this view.
Note that Stephen is implying that Avalon identity is more important
than its container's.
This is the attitude I like to see.
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Plans to move ahead
Posted by Stephen McConnell <mc...@apache.org>.
My preferred position is to go with plan [1].
While I think that is the worst-case-scenario concerning "Merlin",
"Fortress", or "Phoneix" centric product development, I also think
it is the only scenario for a community owned solution.
I do believe that plan [1] will enivatibly involve pulling the best of
existing containters and container related resources together, and
in that respect I see the potential for something much more valuable
comming out of the process.
I do not see this as conflicting with ongoing requirements concerning
support of the Phoenix commuity - in fact this is similar to the
requirements we have for supporting ECM user migration. End result is
the migration of all of our users to a single common container
architecture - a.k.a. everyone wins.
Cheers, Steve.
Berin Loritsch wrote:
>Development Plan 1:
>
>We continue to support our existing projects while we start fresh
>on a new effort. The new effort will be a scalable container that
>follows a "profile". Basically the container will only use the
>features that are part of that profile and ignore everything else.
>
>Development Plan 2:
>
>We adapt our current projects to the three/four tiered approach
>(Tutorial, Micro, Standard, Enterprise). This is probably an easier
>migration path, and it would leverage the existing code that we
>already have.
>
>
--
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] Plans to move ahead
Posted by Mircea Toma <mi...@apache.org>.
> Development Plan 1:
>
> We continue to support our existing projects while we start fresh
> on a new effort. The new effort will be a scalable container that
> follows a "profile". Basically the container will only use the
> features that are part of that profile and ignore everything else.
+1
Mircea
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Plans to move ahead
Posted by Leif Mortenson <le...@tanukisoftware.com>.
Berin Loritsch wrote:
>Development Plan 1:
>
>We continue to support our existing projects while we start fresh
>on a new effort. The new effort will be a scalable container that
>follows a "profile". Basically the container will only use the
>features that are part of that profile and ignore everything else.
>
+1 I also like the idea of a single container which can be configured
to function in
different environments. All of the code/products that I have out there
make use
of the ECM and associated servlet package. I would hope for
compatibility or at
least a fairly easy migration path.
I think that it is important that we at least try to continue using the
Framework
code as is. That will make most components/services migrate cleanly.
I do wonder at how realistic it is to come up with the perfect
container. No matter
what we create, there is always going to be a new idea that surfaces.
Just think
about how many containers we have now.
Like is done with the separation between framework and excalibur, we really
need to focus on what is needed to implement components/services and what
is needed to implement the containers. Being able to make any
component run
in any container would be nice. But containers are always going to have
differing
features and the component model needs to support that.
Would it be possible to have a the concept of required versus optional
lifecycle
interfaces in components? For example. LogEnabled is required.
Instrumentable
is optional. If a component implementing LogEnabled is dropped into a
container
which does not support logging, that component should not be allowed to
be loaded.
If it is loaded, runtime exceptions will be thrown. If on the other
hand the container
did not implement Instrumentable, the component would still function.
Component developers should not be required to deal with this
themselves. We
should have a framework level class which would be used by all container
implementations to simply validate whether or not a component can be
used by the
container. Before instantiating any components, the container would
register its
feature set with the helper class. The class would then compare the
registered
feature list with the features required by the component. (Would need
to work
lifecycle extensions in here as well)
When I first started working with Avalon. There was basically just the
ECM. All of
the excalibur code was separated in the all and scratchpad sub projects.
This
made things very clear as to what was released and what was scratchpad code.
We all talked about "promoting" packages to the all project when they
had been
reviewed by the community.
I would really like to see us return to such a model. Currently, there
is no easy
way to tell what is scratchpad and what is released. When someone spends a
lot of time working on a project, they want to see it promoted as soon
as possible.
Myself included. But I think it is good for the community to keep
things separated
until the ideas have proven themselves.
Cheers,
Leif
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Plans to move ahead
Posted by Marcus Crafter <cr...@fztig938.bank.dresdner.net>.
On Tue, Nov 26, 2002 at 09:14:21AM -0500, Berin Loritsch wrote:
>
> Development Plan 1:
>
> We continue to support our existing projects while we start fresh
> on a new effort. The new effort will be a scalable container that
> follows a "profile". Basically the container will only use the
> features that are part of that profile and ignore everything else.
+1, I find this to be the best approach, it let's us reuse the
best ideas from previous container development to come up with a
common community developed solution.
> Development Plan 2:
>
> We adapt our current projects to the three/four tiered approach
> (Tutorial, Micro, Standard, Enterprise). This is probably an easier
> migration path, and it would leverage the existing code that we
> already have.
Is #2 really a question of tiering ? or rather the adaption of our
current containers ?
Just thinking out loud here, but the resulting container from plan #1
will also need to take into account the different scales, right?
People will want to embed it, use it standalone, have tutorials with
it, and use it in large environments, etc.
Or am I barking up the wrong tree here ?
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] Plans to move ahead
Posted by Paul Hammant <Pa...@yahoo.com>.
I vote for #1
- Paul
>Nothing I am saying is particularly new here. However, before we
>can jump into the nitty gritty details about what the API and
>contracts should look like, we need to gain consensus on the
>general direction. No matter what the course, I am willing to
>help achieve the end goal. Let's get this out of the way before
>we finalize Context contracts, start coding, etc.
>
>
>Development Plan 1:
>
>We continue to support our existing projects while we start fresh
>on a new effort. The new effort will be a scalable container that
>follows a "profile". Basically the container will only use the
>features that are part of that profile and ignore everything else.
>
>PROS: It is new code that we as a team must work together on. We
> will have just as much functionality as we want without
> worrying about functionality we don't want.
>
>CONS: It requires a more complex validation layer (i.e. we need to
> make sure that components that are used do not *require* the
> functionality we left out of the profile).
>
>
>Development Plan 2:
>
>We adapt our current projects to the three/four tiered approach
>(Tutorial, Micro, Standard, Enterprise). This is probably an easier
>migration path, and it would leverage the existing code that we
>already have.
>
>PROS: It uses existing code to build upon. It is easier for a user
> to determine what type of container that they need for the set
> of components they are using.
>
>CONS: It isn't new development, so there is potential for "my way is
> better" conflicts. We may actually be more difficult to
> determine consensus on the particulars of container/component
> contracts.
>
>
>Which way do we as a community want to support? Once we have the
>general plan, let's put together the infrastructure and focus on it.
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Plans to move ahead
Posted by Leo Simons <le...@apache.org>.
On Tue, 2002-11-26 at 15:14, Berin Loritsch wrote:
> Development Plan 1:
>
> We continue to support our existing projects while we start fresh
> on a new effort. The new effort will be a scalable container that
> follows a "profile". Basically the container will only use the
> features that are part of that profile and ignore everything else.
>
> PROS: It is new code that we as a team must work together on. We
> will have just as much functionality as we want without
> worrying about functionality we don't want.
>
> CONS: It requires a more complex validation layer (i.e. we need to
> make sure that components that are used do not *require* the
> functionality we left out of the profile).
+ it requires a more complex backward compatibility layer
+ it might take longer to get a release that's useful to the
cocoon people for 3.x (though the pro of that might be that
more of them come over to help)
I would like to explore this direction, +1
> Development Plan 2:
>
> We adapt our current projects to the three/four tiered approach
> (Tutorial, Micro, Standard, Enterprise). This is probably an easier
> migration path, and it would leverage the existing code that we
> already have.
>
> PROS: It uses existing code to build upon. It is easier for a user
> to determine what type of container that they need for the set
> of components they are using.
>
> CONS: It isn't new development, so there is potential for "my way is
> better" conflicts. We may actually be more difficult to
> determine consensus on the particulars of container/component
> contracts.
+ while nice to put clear labels on things and restrict the
scope of current containers a little more, it really doesn't
make sense technically. ie merlin is already moving along the
lines of plan #1, a micro container should be simple enough
to be a tutorial container.........
I think this is the second-best alternative should many people not like
#0, hence I'm -0 on this one for now.
cheers,
- Leo Simons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Plans to move ahead
Posted by Stephen McConnell <mc...@apache.org>.
Neeme Praks wrote:
>
> Berin Loritsch ::
>
>> >>Development Plan 1:
>> >>
>> >>We continue to support our existing projects while we start fresh
>> >>on a new effort. The new effort will be a scalable container that
>> >>follows a "profile". Basically the container will only use the
>> >>features that are part of that profile and ignore everything else.
>> >>
>> >>Development Plan 2:
>> >>
>> >>We adapt our current projects to the three/four tiered approach
>> >>(Tutorial, Micro, Standard, Enterprise). This is probably an easier
>> >>migration path, and it would leverage the existing code that we
>> >>already have.
>> >
>> >Seems to me that you have missed the 3rd alternative:
>> >
>> >We continue to support our existing projects while we take the best
>> >parts of the existing code into the new "tiered" model container.
>> >
>> >(and I do not believe that you were seriously proposing plan
>> >2, as that
>> >seems to imply NOT SUPPORTING EXISTING projects)
>>
>> Sorry to be confusing, but I thought that was implied for Dev plan 2.
>>
>> Which model do you prefer?
>
>
> Ok, that's what I suspected ;-)
>
> In that case, "3rd alternative" == "development plan 2"... :-)
>
> And I would support exactly that: "refactor" (in the sense of "copy",
> not in the sense of "move" or "rename") the existing codebase(s) into
> a new "tiered" model.
>
> +1
This seems to me to be consitent with plan 1 - but whatever - yes - it
needs to happen.
Cheers, Steve.
>
>
> Rgds,
> Neeme
>
>
> --
> 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] Plans to move ahead
Posted by Neeme Praks <ne...@apache.org>.
Berin Loritsch ::
> >>Development Plan 1:
> >>
> >>We continue to support our existing projects while we start fresh
> >>on a new effort. The new effort will be a scalable container that
> >>follows a "profile". Basically the container will only use the
> >>features that are part of that profile and ignore everything else.
> >>
> >>Development Plan 2:
> >>
> >>We adapt our current projects to the three/four tiered approach
> >>(Tutorial, Micro, Standard, Enterprise). This is probably an easier
> >>migration path, and it would leverage the existing code that we
> >>already have.
> >
> >Seems to me that you have missed the 3rd alternative:
> >
> >We continue to support our existing projects while we take the best
> >parts of the existing code into the new "tiered" model container.
> >
> >(and I do not believe that you were seriously proposing plan
> >2, as that
> >seems to imply NOT SUPPORTING EXISTING projects)
>
> Sorry to be confusing, but I thought that was implied for Dev plan 2.
>
> Which model do you prefer?
Ok, that's what I suspected ;-)
In that case, "3rd alternative" == "development plan 2"... :-)
And I would support exactly that: "refactor" (in the sense of "copy",
not in the sense of "move" or "rename") the existing codebase(s) into a
new "tiered" model.
+1
Rgds,
Neeme
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Plans to move ahead
Posted by Stephen McConnell <mc...@apache.org>.
Neeme Praks wrote:
>
> Berin Loritsch ::
>
>> Let me make this really simple (you guys are thinking too hard).
>>
>> Proposal 1
>> unified container that uses profiles
>>
>> Proposal 2
>> multi-tiered set of containers
>>
>> We can worry about the details of how to proceed from there.
>
>
>
> OK, now I re-read your original email and found out that I had
> misinterpreted the information there. Your focus was on "unified" vs.
> "multi".
>
> I do not really see a conflict there, I would say that unified
> container with profiles can be used to implement the multi-tiered
> approach.
>
> In other words, I think you are comparing apples to oranges here.
> Proposal 1 is about implementation and proposal 2 is about different
> "application spaces" or "tiers".
>
> I would rephrase your proposal as:
>
> proposal 1 (stays as is):
> -------------------------
> unified container that uses profiles to implement multi-tiered container
> (the question if the "profile" will be hard-wired or if it will be
> more dynamic with some sort of configuration files is already an
> implementation detail)
>
> IMO, this proposal could also be rephrased as "unified toolkit that is
> used to implement containers in multiple tiers".
That's my take on proposal 1.
>
> proposal 2:
> -----------
> becomes irrelevant?
>
> So, I support proposal 1.
dito.
Steve.
>
> Rgds,
> Neeme
>
>
> --
> 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] Plans to move ahead
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Neeme Praks [mailto:neeme@apache.org]
>
> OK, now I re-read your original email and found out that I had
> misinterpreted the information there. Your focus was on "unified" vs.
> "multi".
You are making it harder than it needs to be....
I put you down for Proposal 1.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Plans to move ahead
Posted by Neeme Praks <ne...@apache.org>.
Berin Loritsch ::
> Let me make this really simple (you guys are thinking too hard).
>
> Proposal 1
> unified container that uses profiles
>
> Proposal 2
> multi-tiered set of containers
>
> We can worry about the details of how to proceed from there.
OK, now I re-read your original email and found out that I had
misinterpreted the information there. Your focus was on "unified" vs.
"multi".
I do not really see a conflict there, I would say that unified container
with profiles can be used to implement the multi-tiered approach.
In other words, I think you are comparing apples to oranges here.
Proposal 1 is about implementation and proposal 2 is about different
"application spaces" or "tiers".
I would rephrase your proposal as:
proposal 1 (stays as is):
-------------------------
unified container that uses profiles to implement multi-tiered container
(the question if the "profile" will be hard-wired or if it will be more
dynamic with some sort of configuration files is already an
implementation detail)
IMO, this proposal could also be rephrased as "unified toolkit that is
used to implement containers in multiple tiers".
proposal 2:
-----------
becomes irrelevant?
So, I support proposal 1.
Rgds,
Neeme
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Plans to move ahead
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
>Let me make this really simple (you guys are thinking too hard).
>
>
>Proposal 1
>
>unified container that uses profiles
>
+1
>
>Proposal 2
>
>multi-tiered set of containers
>
>
>
-0
>
>We can worry about the details of how to proceed from there.
>
>
>--
>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] Plans to move ahead
Posted by Peter Royal <pr...@apache.org>.
On Tuesday, November 26, 2002, at 10:12 AM, Berin Loritsch wrote:
> Let me make this really simple (you guys are thinking too hard).
>
>
> Proposal 1
>
> unified container that uses profiles
+1
(still catching up on the flood of emails from the weekend :)
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] Plans to move ahead
Posted by Berin Loritsch <bl...@citi-us.com>.
Let me make this really simple (you guys are thinking too hard).
Proposal 1
unified container that uses profiles
Proposal 2
multi-tiered set of containers
We can worry about the details of how to proceed from there.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Plans to move ahead
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Berin Loritsch wrote:
>
>>-----Original Message-----
>>From: Neeme Praks [mailto:neeme@apache.org]
>>Sent: Tuesday, November 26, 2002 9:45 AM
>>To: Avalon Developers List
>>Subject: Re: [VOTE] Plans to move ahead
>>
>>
>>
>>Berin Loritsch wrote:
>>
>>
>>>Development Plan 1:
>>>
>>>We continue to support our existing projects while we start fresh
>>>on a new effort. The new effort will be a scalable container that
>>>follows a "profile". Basically the container will only use the
>>>features that are part of that profile and ignore everything else.
>>>
>>>Development Plan 2:
>>>
>>>We adapt our current projects to the three/four tiered approach
>>>(Tutorial, Micro, Standard, Enterprise). This is probably an easier
>>>migration path, and it would leverage the existing code that we
>>>already have.
>>
>>
>>Seems to me that you have missed the 3rd alternative:
>>
>>We continue to support our existing projects while we take the best
>>parts of the existing code into the new "tiered" model container.
>>
>>(and I do not believe that you were seriously proposing plan
>>2, as that
>>seems to imply NOT SUPPORTING EXISTING projects)
>
>
> Sorry to be confusing, but I thought that was implied for Dev plan 2.
>
> Which model do you prefer?
Please be more specific.
What "existing projects" should we support?
Released are ECM and Phoenix, and they will be supported anyway.
Fortress and Merlin would in either case go into the new container, as I
see it counterproductive to keep them separated.
Proposal 3
1 Phoenix is supported and put in feature freeze.
2 Merlin and Fortress united
3 a micro profile is made from them
4 Phoenix is made to use "Merlin and Fortress united" as a container
Or something along these lines.
Note that step two could imply that we start anew including selective
parts of both efforts.
--
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] Plans to move ahead
Posted by Berin Loritsch <bl...@citi-us.com>.
> -----Original Message-----
> From: Neeme Praks [mailto:neeme@apache.org]
> Sent: Tuesday, November 26, 2002 9:45 AM
> To: Avalon Developers List
> Subject: Re: [VOTE] Plans to move ahead
>
>
>
> Berin Loritsch wrote:
>
> > Development Plan 1:
> >
> > We continue to support our existing projects while we start fresh
> > on a new effort. The new effort will be a scalable container that
> > follows a "profile". Basically the container will only use the
> > features that are part of that profile and ignore everything else.
> >
> > Development Plan 2:
> >
> > We adapt our current projects to the three/four tiered approach
> > (Tutorial, Micro, Standard, Enterprise). This is probably an easier
> > migration path, and it would leverage the existing code that we
> > already have.
>
>
> Seems to me that you have missed the 3rd alternative:
>
> We continue to support our existing projects while we take the best
> parts of the existing code into the new "tiered" model container.
>
> (and I do not believe that you were seriously proposing plan
> 2, as that
> seems to imply NOT SUPPORTING EXISTING projects)
Sorry to be confusing, but I thought that was implied for Dev plan 2.
Which model do you prefer?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Plans to move ahead
Posted by Neeme Praks <ne...@apache.org>.
Berin Loritsch wrote:
> Development Plan 1:
>
> We continue to support our existing projects while we start fresh
> on a new effort. The new effort will be a scalable container that
> follows a "profile". Basically the container will only use the
> features that are part of that profile and ignore everything else.
>
> Development Plan 2:
>
> We adapt our current projects to the three/four tiered approach
> (Tutorial, Micro, Standard, Enterprise). This is probably an easier
> migration path, and it would leverage the existing code that we
> already have.
Seems to me that you have missed the 3rd alternative:
We continue to support our existing projects while we take the best
parts of the existing code into the new "tiered" model container.
(and I do not believe that you were seriously proposing plan 2, as that
seems to imply NOT SUPPORTING EXISTING projects)
Rgds,
Neeme
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>