You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Paul Hammant <Pa...@yahoo.com> on 2003/01/05 23:47:28 UTC
Containerkit
Folks,
This package is now in avalon-sandbox. Given it is used in Phoenix, has
code that was refactored from Phoenix, I think it is best not to mark
this package with the 'alpha' status that sandbox affords.
I'd like to see how people feel about ...
a) removal of containerkit from sandbox to some place more fitting
or
b) absorbing of containerkit into Phoenix (giving it x.x.phoenix
packages).
Thoughts gentlemen (and lurking ladies) please...
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Containerkit
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Paul Hammant wrote:
> Folks,
>
> This package is now in avalon-sandbox. Given it is used in Phoenix, has
> code that was refactored from Phoenix, I think it is best not to mark
> this package with the 'alpha' status that sandbox affords.
>
> I'd like to see how people feel about ...
>
> a) removal of containerkit from sandbox to some place more fitting
>
> or
>
> b) absorbing of containerkit into Phoenix (giving it x.x.phoenix
> packages).
>
> Thoughts gentlemen (and lurking ladies) please...
IMHO there is no "place more fitting" I can think of in the new Avalon
proposed organization, but keeping it alpha is not good.
Hence I'm for (b).
--
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: Containerkit
Posted by Stephen McConnell <mc...@apache.org>.
Paul Hammant wrote
> Leo Simons wrote:
>
>>> b) absorbing of containerkit into Phoenix (giving it x.x.phoenix
>>> packages).
>>
>>
>>
>> Given the speed the "common ground" discussions are taking I think
>> this is the best compromise. I am a bit concerned about later
>> backwards compatibility (if the final "common meta setup" we agree
>> upon deviates a lot from the one currently used in
>> containerkit/info/phoenix, it'll be a lot of work to get phoenix to
>> support both).
>
>
> We're gong for a scrap current (meta-model) design right for uber right?
As far the meta subject is concerned I look at it as a process of
evolving based on experience, requirements and concensus. I'm confident
the what will come out of the process will leverage a lot of we already
have and I'm also confident that the result will be different to what we
have now - more of an evolutionary step forward. I also see this
closely related to how the the containement architecture unfolds
(keeping in mind that the meta is a small but intrinsically important
part of a container solution).
<snip>
>> I'd also like to see some notice in the phoenix documentation that
>> although the meta materials are stable codewise (and supported as
>> such), we're not too sure about some aspects yet and thus that there
>> may be big changes in future versions (as we already know this, users
>> should know too :D).
>
>
> I don't see why Phonix has to carry adverts for meta (which it does
> not use). Meta is in sandbox right?
I think the reference to "meta" (lowercase) above is in the context of
"meta-model" development in general (i.e. its not referring to the Meta
package).
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Containerkit
Posted by Leo Simons <le...@apache.org>.
Paul Hammant wrote:
>>How about putting containerkit in phoenix cvs, then dropping only the
>>generated jar in the src and bin distros?
>
> OK, but PUnit (part of Phoenix) uses it. Also Enterprise Object Broker (not apache) uses it.
> I'd like to see the jar built, and distributed as part of phoenix. It would be no different to
> the long-lived phoenix-client.jar in that respect.
settled it is, then! (I think we also want to move avalon-sandbox/info
and apply the same treatment.)
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Containerkit
Posted by Paul Hammant <pa...@yahoo.com>.
> masters? Which masters? There aren't any.
The board.
> How about putting containerkit in phoenix cvs, then dropping only the
> generated jar in the src and bin distros?
OK, but PUnit (part of Phoenix) uses it. Also Enterprise Object Broker (not apache) uses it.
I'd like to see the jar built, and distributed as part of phoenix. It would be no different to
the long-lived phoenix-client.jar in that respect.
> The point is I don't want people to believe that _containerkit_ is a
> package that won't be refactored or that'll be around after any
> "ubercontainer" structure is in place. I'll happily commit to supporting
> several dtds 'n stuff for n^2 years, but not implementations.
Fine, which is why I am saying put it back in Phoenix.
> >
> > 'Container package' is ambiguous. Do you mean ..
> >
> > "Phoenix is temporary. It will be replaced by UberContainer later".
> >
> > or
> >
> > "Phoenix uses Container-kit. Container-kit will be replaced by some other container
> abstraction
> > solution inside Phoenix later".
>
> I ment the latter. I have to see that an UberContainer can be built
> before putting anything at stake for it.
Why monkey around with the internals of Phoenix when it is to be replaced with UberContainer
later.
It is completely pointless.
- 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: Containerkit
Posted by Leo Simons <le...@apache.org>.
> So why worry if containerkit goes _back_ to where it started -
> Phoenix codebase. It is a near solution that helps releive the clutter of CVs that has got us
> into so much trouble with our masters.
masters? Which masters? There aren't any.
>>>>Given recent developments at work, it is unlikely I'll have the time
>>>>to invest to do that conversion work (you might notice me working on
>>>>fortress though ;), so I won't give a +1, but if there's enough peeps
>>>>willing to commit to it, then I certainly don't have any other
>>>>objection, and I'll give an as-supportive-as-possible +0 on option (b).
>>>>
>>>>I would like to see the coupling between phoenix and a specific meta
>>>>model kept as small as possible though, with the eye on easing
>>>>migration to something else later.
>>>
>>>That will not change based on the location of container-kit will it?
>>
>>which paragraph are you referring too, the +0 or the loose coupling? The
>>first para will, the second one is less likely to.
>
> Are you going to work on Phoenix?
When I need to. There's a company commitment to it. When one of our
deployments gets buggered up I'll patch. But since we don't use any of
the more advanced phoenix features like management it's quite hard to
find a bug :D
> We do not want them to believe that it's going through some
refactoring excercise _and_ it
> is going to be killed in n years time for ubercontainer.
How about putting containerkit in phoenix cvs, then dropping only the
generated jar in the src and bin distros?
The point is I don't want people to believe that _containerkit_ is a
package that won't be refactored or that'll be around after any
"ubercontainer" structure is in place. I'll happily commit to supporting
several dtds 'n stuff for n^2 years, but not implementations.
>>1) I think the parts of containerkit that are used by phoenix should be
>>rolled back into phoenix, while making clear to phoenix users it is
>>intended as a temporary solution until we get a common 'containerkit' in
>>place. IOW:
>
>>cp -Rfp avalon-sandbox/containerkit jakarta-avalon-phoenix
>>echo 'This is temporarily here until we get a common avalon container
>>package in place yada yada' > \
>>jakarta-avalon-phoenix/containerkit/WARN.txt
>
> 'Container package' is ambiguous. Do you mean ..
>
> "Phoenix is temporary. It will be replaced by UberContainer later".
>
> or
>
> "Phoenix uses Container-kit. Container-kit will be replaced by some other container abstraction
> solution inside Phoenix later".
I ment the latter. I have to see that an UberContainer can be built
before putting anything at stake for it.
>>5) I see some more packages sitting in the phoenix lib dir that have not
>>been released. For the libs that come from sandbox, I think they should
>>be given the same treatment.
>
> You mean not have been separated out.
mostly, yes (I think). There's a few with an "a" in their version, ie
excalibur-info, excalibur-policy, excalibur-baxter, excalibur-extension.
I didn't finish my sentence I guess. For the non-seperated packages
(like excalibur logger), we need to release them as seperated packages.
For the non-released packages, we need to think about whether we want to
release them or roll 'em back in.
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Containerkit
Posted by Peter Donald <pe...@realityforge.org>.
On Thu, 9 Jan 2003 04:36, Stephen McConnell wrote:
> Peter Donald wrote:
> >On Wed, 8 Jan 2003 18:35, Nicola Ken Barozzi wrote:
> >>Which?
> >>
> >>Let me see:
> >>
> >>- Merlin: no
> >>- Fortress: no
> >>- ECM: no
> >>- Phoenix: yes
> >>
> >>Apache projects using Avalon:
> >>
> >>- James: uses Phoenix: yes
> >>- Cocoon: no
> >>
> >>What am I missing?
> >
> >Other containers not developed internally to Avalon.
>
> Care to provide some names and URLs?
Almost all of them are internal or not yet released.
--
Cheers,
Peter Donald
A right is not what someone gives you; it's what no one can take from you.
-- Ramsey Clark
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Containerkit
Posted by Stephen McConnell <mc...@apache.org>.
Peter Donald wrote:
>On Wed, 8 Jan 2003 18:35, Nicola Ken Barozzi wrote:
>
>
>>Which?
>>
>>Let me see:
>>
>>- Merlin: no
>>- Fortress: no
>>- ECM: no
>>- Phoenix: yes
>>
>>Apache projects using Avalon:
>>
>>- James: uses Phoenix: yes
>>- Cocoon: no
>>
>>What am I missing?
>>
>>
>
>Other containers not developed internally to Avalon.
>
Care to provide some names and URLs?
Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Containerkit
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 8 Jan 2003 18:35, Nicola Ken Barozzi wrote:
> Which?
>
> Let me see:
>
> - Merlin: no
> - Fortress: no
> - ECM: no
> - Phoenix: yes
>
> Apache projects using Avalon:
>
> - James: uses Phoenix: yes
> - Cocoon: no
>
> What am I missing?
Other containers not developed internally to Avalon.
--
Cheers,
Peter Donald
----------------------------------------------------------------
Fools ignore complexity. Pragmatists suffer it.
Some can avoid it. Geniuses remove it.
-- Perlis's Programming Proverb #58, SIGPLAN Notices, Sept. 1982
----------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ThreadPool + excalibur event + Cornerstone ThreadManager
Posted by mati <ma...@ncdc.pl>.
Could someone please answer my post;
thanks
>
>
> I have been trying to use DefaultThreadManager from excalibur event
package.
>
> I just do not want to have an additional ThreadPool managed by
> TPCThreadManager so I thought I would use the cornerstone one
>
> The problem is that CornerStone uses old ThreadPool
> import org.apache.avalon.excalibur.thread.ThreadPool;
>
> which is depracated by now
>
> On the other hand AbstractThreadManager expects to get the new one, and
here
> we have a problem
> import org.apache.excalibur.thread.ThreadPool;
>
> because I get exception:
>
> org.apache.excalibur.containerkit.lifecycle.LifecycleException: Component
> named "my-thread-manager" failed to pass through the Initialization stage.
> (Reason: java.lang.IncompatibleClassChangeError).
>
> I do not know what is the proper way of solving this problem. I've spotted
> that Peter Donald created DefaultThreadManager (excalibur-event) so I am
> wondering how did he manage to force these to work with Cornerstone
> ThreadManager and it's ThreadPool.
>
>
> Here is the code snippet:
>
> public void initialize() throws Exception {
> file://this.threadManager = new TPCThreadManager();
> ThreadPool pool =
this.cornerStoneThreadManager.getDefaultThreadPool();
> this.newThreadManager = new DefaultThreadManager(pool);
>
>
this.newThreadManager.enableLogging(getLogger().getChildLogger("excalibur-th
> read-manager"));
> newThreadManager.initialize();
> }
>
> I would appreciate any feedback.
>
> TIA
>
> Mateusz Szczap
> mati@no.spam.ncdc.pl
>
>
> --
> 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: ThreadPool + excalibur event + Cornerstone ThreadManager
Posted by mati <ma...@ncdc.pl>.
> I use the two together, but with an older snapshot of excalibur-event.
> -pete
Could you send me this snapshot, because I have tried with some and none
worked.
TIA
Mateusz Szczap
mati@ncdc.pl
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ThreadPool + excalibur event + Cornerstone ThreadManager
Posted by Peter Royal <pr...@apache.org>.
On Wednesday, January 8, 2003, at 09:32 AM, mati wrote:
> I have been trying to use DefaultThreadManager from excalibur event
> package.
>
> I just do not want to have an additional ThreadPool managed by
> TPCThreadManager so I thought I would use the cornerstone one
>
> The problem is that CornerStone uses old ThreadPool
> import org.apache.avalon.excalibur.thread.ThreadPool;
>
> which is depracated by now
>
> On the other hand AbstractThreadManager expects to get the new one,
> and here
> we have a problem
> import org.apache.excalibur.thread.ThreadPool;
>
> because I get exception:
>
> org.apache.excalibur.containerkit.lifecycle.LifecycleException:
> Component
> named "my-thread-manager" failed to pass through the Initialization
> stage.
> (Reason: java.lang.IncompatibleClassChangeError).
>
> I do not know what is the proper way of solving this problem. I've
> spotted
> that Peter Donald created DefaultThreadManager (excalibur-event) so I
> am
> wondering how did he manage to force these to work with Cornerstone
> ThreadManager and it's ThreadPool.
I use the two together, but with an older snapshot of excalibur-event.
-pete
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
ThreadPool + excalibur event + Cornerstone ThreadManager
Posted by mati <ma...@ncdc.pl>.
I have been trying to use DefaultThreadManager from excalibur event package.
I just do not want to have an additional ThreadPool managed by
TPCThreadManager so I thought I would use the cornerstone one
The problem is that CornerStone uses old ThreadPool
import org.apache.avalon.excalibur.thread.ThreadPool;
which is depracated by now
On the other hand AbstractThreadManager expects to get the new one, and here
we have a problem
import org.apache.excalibur.thread.ThreadPool;
because I get exception:
org.apache.excalibur.containerkit.lifecycle.LifecycleException: Component
named "my-thread-manager" failed to pass through the Initialization stage.
(Reason: java.lang.IncompatibleClassChangeError).
I do not know what is the proper way of solving this problem. I've spotted
that Peter Donald created DefaultThreadManager (excalibur-event) so I am
wondering how did he manage to force these to work with Cornerstone
ThreadManager and it's ThreadPool.
Here is the code snippet:
public void initialize() throws Exception {
//this.threadManager = new TPCThreadManager();
ThreadPool pool = this.cornerStoneThreadManager.getDefaultThreadPool();
this.newThreadManager = new DefaultThreadManager(pool);
this.newThreadManager.enableLogging(getLogger().getChildLogger("excalibur-th
read-manager"));
newThreadManager.initialize();
}
I would appreciate any feedback.
TIA
Mateusz Szczap
mati@no.spam.ncdc.pl
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Containerkit
Posted by Stephen McConnell <mc...@apache.org>.
Paul Hammant wrote:
> Nicola,
>
>>> yep. It is used in a few other containers so no need for it to be
>>> Phoenix specific.
>>
>>
>>
>> Which?
>
>
> EnterpriseObjectBroker dude.
Which is basically using Phoenix APIs. I.e. it's not an issue.
Steve.
>
> - Paul
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Containerkit
Posted by Paul Hammant <Pa...@yahoo.com>.
Nicola,
>> yep. It is used in a few other containers so no need for it to be
>> Phoenix specific.
>
>
> Which?
EnterpriseObjectBroker dude.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSAL] Containerkit
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote:
> On Tue, 7 Jan 2003 22:03, Nicola Ken Barozzi wrote:
>
>>I propose that code used in Phoenix that is now standing in the sandbox
>>be *moved* to Phoenix.
>>
>>RATIONALE:
>>
>>- Phoenix should not rely on stuff marked as sandbox
>>- The code should be only in one place, and in Phoenix it's
>> best because there is where it's maintained and can
>> evolve
>>- we will also consider *all* phoenix code for ubercontainer
>> so code moved there will still be considered
>>
>>Is someone is against this for a solid reason?
>
> yep. It is used in a few other containers so no need for it to be Phoenix
> specific.
Which?
Let me see:
- Merlin: no
- Fortress: no
- ECM: no
- Phoenix: yes
Apache projects using Avalon:
- James: uses Phoenix: yes
- Cocoon: no
What am I missing?
--
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: [PROPOSAL] Containerkit
Posted by Peter Donald <pe...@realityforge.org>.
On Tue, 7 Jan 2003 22:03, Nicola Ken Barozzi wrote:
> I propose that code used in Phoenix that is now standing in the sandbox
> be *moved* to Phoenix.
>
> RATIONALE:
>
> - Phoenix should not rely on stuff marked as sandbox
> - The code should be only in one place, and in Phoenix it's
> best because there is where it's maintained and can
> evolve
> - we will also consider *all* phoenix code for ubercontainer
> so code moved there will still be considered
>
> Is someone is against this for a solid reason?
yep. It is used in a few other containers so no need for it to be Phoenix
specific.
--
Cheers,
Peter Donald
*--------------------------------*
| Every rule has an exception, |
| except the rule of exceptions. |
*--------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[PROPOSAL] Containerkit
Posted by Nicola Ken Barozzi <ni...@apache.org>.
I propose that code used in Phoenix that is now standing in the sandbox
be *moved* to Phoenix.
RATIONALE:
- Phoenix should not rely on stuff marked as sandbox
- The code should be only in one place, and in Phoenix it's
best because there is where it's maintained and can
evolve
- we will also consider *all* phoenix code for ubercontainer
so code moved there will still be considered
Is someone is against this for a solid reason?
--
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: Containerkit
Posted by Paul Hammant <pa...@yahoo.com>.
Leo,
> >> Containerkit is not 'alpha' in the sense of code quality. It _is_
> >> alpha in the sense of "we're not guaranteeing backwards compatibility
> >> on this stuff (we're not done yet with the meta model disucssion)".
> >>
> >> As such I think it fits in sandbox.
> >
> > Fine, start some other project.
>
> eh? don't follow you here...
You want this in sandbox, yet It is part of phoenix and not alpha quality. You want some future
uber-containerkit-meta-info package. Fine start it.
> > It was refactored out of Phoenix. Phoenix is shipping. Phoenix is not
> > alpha.
>
> Making containerkit a seperate release gives it additional weight it
> doesn't have if it is just part of phoenix. If containerkit is just part
> of phoenix, there's less need to support other containers that use it.
>
> I'm okay with phoenix using containerkit (after all, it's basically
> refactoring going on). I'm not too happy about other containers doing
> so. That's the difference.
Containerket was taken out of Phoenix because there _might_ be a possibility of reuse. That has
not happened. Now it is has been moved from excalibur to sandbox. How many ways are tehre to
inerpret sandbox?
> >> but the info package in sandbox is, so the principal discussion is the
> >> same), and it's alpha state is hampering phoenix development (which is
> >> why you're posting this message, innit?), we need to find a way
> >> arround that.
> >
> > This is not about info versus containerkit. It is about Phoenix.
>
> my point was that I didn't see containerkit in there (due to not looking
> very well ;), but did see info, and that it didn't matter for the
> discussion, as along the same thoughtline we'll probably want to do the
> same for excalibur-info (now in avalon-sandbox) as for containerkit.
> Nevermind.
I guess. I'll investigate.
> >>> b) absorbing of containerkit into Phoenix (giving it x.x.phoenix
> >>> packages).
> >>
> >> Given the speed the "common ground" discussions are taking I think
> >> this is the best compromise. I am a bit concerned about later
> >> backwards compatibility (if the final "common meta setup" we agree
> >> upon deviates a lot from the one currently used in
> >> containerkit/info/phoenix, it'll be a lot of work to get phoenix to
> >> support both).
> >
> >
> > We're gong for a scrap current (meta-model) design right for uber right?
>
> dunno. Whatever compromise results in consensus I like. Point is we
> don't have consensus right now.
Concencus was given to us in respect of the Phoenix and Merlin. Both are to die in n years time
when uber container is finished. Ubercontainer will be from scratch. I am fairly sure that no
element of Phoenix code will be use for that. It is also likely that Phoenix and Merlin are _not_
refactored towards ubercontainer. So why worry if containerkit goes _back_ to where it started -
Phoenix codebase. It is a near solution that helps releive the clutter of CVs that has got us
into so much trouble with our masters.
> >> Given recent developments at work, it is unlikely I'll have the time
> >> to invest to do that conversion work (you might notice me working on
> >> fortress though ;), so I won't give a +1, but if there's enough peeps
> >> willing to commit to it, then I certainly don't have any other
> >> objection, and I'll give an as-supportive-as-possible +0 on option (b).
> >>
> >> I would like to see the coupling between phoenix and a specific meta
> >> model kept as small as possible though, with the eye on easing
> >> migration to something else later.
> >
> > That will not change based on the location of container-kit will it?
>
> which paragraph are you referring too, the +0 or the loose coupling? The
> first para will, the second one is less likely to.
Are you going to work on Phoenix? It is to be replaced by ubercontainer. Phoenix only has
stability issues now. We need only to represent to its user community that it is not built from
an assortment of alpha components. We need to illustrate to them that it is stable, will be bug
fixed. We do not want them to believe that it's going through some refactoring excercise _and_ it
is going to be killed in n years time for ubercontainer.
> >> I'd also like to see some notice in the phoenix documentation that
> >> although the meta materials are stable codewise (and supported as
> >> such), we're not too sure about some aspects yet and thus that there
> >> may be big changes in future versions (as we already know this, users
> >> should know too :D).
> >
> > I don't see why Phonix has to carry adverts for meta (which it does not
> > use). Meta is in sandbox right?
>
> I ment "meta materials" as in the phoenix code that deals with it, not
> the sandbox project.
>
> >> I do think a version of containerkit should remain in avalon-sandbox
> >> as there's stuff to harvest from it in the continuing "common meta
> >> setup" area.
> >
> > Given you now understand it is used by Phoenix, do you have a modified
> > opinion?
>
> nope.
> Let me rephrase (I think you were misunderstanding me):
>
> 1) I think the parts of containerkit that are used by phoenix should be
> rolled back into phoenix, while making clear to phoenix users it is
> intended as a temporary solution until we get a common 'containerkit' in
> place. IOW:
> cp -Rfp avalon-sandbox/containerkit jakarta-avalon-phoenix
> echo 'This is temporarily here until we get a common avalon container
> package in place yada yada' > \
> jakarta-avalon-phoenix/containerkit/WARN.txt
'Container package' is ambiguous. Do you mean ..
"Phoenix is temporary. It will be replaced by UberContainer later".
or
"Phoenix uses Container-kit. Container-kit will be replaced by some other container abstraction
solution inside Phoenix later".
> 2) I have some reservations about this move as outlined but I understand
> the clearcut user need for it, so if there's enough developer support
> I'm happy.
>
>
> 3) Containerkit should not be released as an independent package, but
> only as part of a phoenix release.
>
>
> 4) I think that the containerkit package as it is now should remain
> sitting around in sandbox regardless, for the sake of developing that
> common containerkit.
> 5) I see some more packages sitting in the phoenix lib dir that have not
> been released. For the libs that come from sandbox, I think they should
> be given the same treatment.
"not have been released"
http://jakarta.apache.org/builds/jakarta-avalon-excalibur/release/
I can't see them.
You mean not have been separated out.
- 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: Containerkit
Posted by Leo Simons <le...@apache.org>.
Paul Hammant wrote:
> Leo,
>
>> Containerkit is not 'alpha' in the sense of code quality. It _is_
>> alpha in the sense of "we're not guaranteeing backwards compatibility
>> on this stuff (we're not done yet with the meta model disucssion)".
>>
>> As such I think it fits in sandbox.
>
> Fine, start some other project.
eh? don't follow you here...
> It was refactored out of Phoenix. Phoenix is shipping. Phoenix is not
> alpha.
Making containerkit a seperate release gives it additional weight it
doesn't have if it is just part of phoenix. If containerkit is just part
of phoenix, there's less need to support other containers that use it.
I'm okay with phoenix using containerkit (after all, it's basically
refactoring going on). I'm not too happy about other containers doing
so. That's the difference.
>> but the info package in sandbox is, so the principal discussion is the
>> same), and it's alpha state is hampering phoenix development (which is
>> why you're posting this message, innit?), we need to find a way
>> arround that.
>
> This is not about info versus containerkit. It is about Phoenix.
my point was that I didn't see containerkit in there (due to not looking
very well ;), but did see info, and that it didn't matter for the
discussion, as along the same thoughtline we'll probably want to do the
same for excalibur-info (now in avalon-sandbox) as for containerkit.
Nevermind.
>>> b) absorbing of containerkit into Phoenix (giving it x.x.phoenix
>>> packages).
>>
>> Given the speed the "common ground" discussions are taking I think
>> this is the best compromise. I am a bit concerned about later
>> backwards compatibility (if the final "common meta setup" we agree
>> upon deviates a lot from the one currently used in
>> containerkit/info/phoenix, it'll be a lot of work to get phoenix to
>> support both).
>
>
> We're gong for a scrap current (meta-model) design right for uber right?
dunno. Whatever compromise results in consensus I like. Point is we
don't have consensus right now.
>> Given recent developments at work, it is unlikely I'll have the time
>> to invest to do that conversion work (you might notice me working on
>> fortress though ;), so I won't give a +1, but if there's enough peeps
>> willing to commit to it, then I certainly don't have any other
>> objection, and I'll give an as-supportive-as-possible +0 on option (b).
>>
>> I would like to see the coupling between phoenix and a specific meta
>> model kept as small as possible though, with the eye on easing
>> migration to something else later.
>
> That will not change based on the location of container-kit will it?
which paragraph are you referring too, the +0 or the loose coupling? The
first para will, the second one is less likely to.
>> I'd also like to see some notice in the phoenix documentation that
>> although the meta materials are stable codewise (and supported as
>> such), we're not too sure about some aspects yet and thus that there
>> may be big changes in future versions (as we already know this, users
>> should know too :D).
>
> I don't see why Phonix has to carry adverts for meta (which it does not
> use). Meta is in sandbox right?
I ment "meta materials" as in the phoenix code that deals with it, not
the sandbox project.
>> I do think a version of containerkit should remain in avalon-sandbox
>> as there's stuff to harvest from it in the continuing "common meta
>> setup" area.
>
> Given you now understand it is used by Phoenix, do you have a modified
> opinion?
nope.
Let me rephrase (I think you were misunderstanding me):
1) I think the parts of containerkit that are used by phoenix should be
rolled back into phoenix, while making clear to phoenix users it is
intended as a temporary solution until we get a common 'containerkit' in
place. IOW:
cp -Rfp avalon-sandbox/containerkit jakarta-avalon-phoenix
echo 'This is temporarily here until we get a common avalon container
package in place yada yada' > \
jakarta-avalon-phoenix/containerkit/WARN.txt
2) I have some reservations about this move as outlined but I understand
the clearcut user need for it, so if there's enough developer support
I'm happy.
3) Containerkit should not be released as an independent package, but
only as part of a phoenix release.
4) I think that the containerkit package as it is now should remain
sitting around in sandbox regardless, for the sake of developing that
common containerkit.
5) I see some more packages sitting in the phoenix lib dir that have not
been released. For the libs that come from sandbox, I think they should
be given the same treatment.
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Containerkit
Posted by Paul Hammant <Pa...@yahoo.com>.
Leo,
> Containerkit is not 'alpha' in the sense of code quality. It _is_
> alpha in the sense of "we're not guaranteeing backwards compatibility
> on this stuff (we're not done yet with the meta model disucssion)".
>
> As such I think it fits in sandbox.
Fine, start some other project.
It was refactored out of Phoenix. Phoenix is shipping. Phoenix is not alpha.
> However, if containerkit is used and needed in phoenix (looking at my
> current phoenix lib dir, it's not,
Look again. lib/container/
> but the info package in sandbox is, so the principal discussion is the
> same), and it's alpha state is hampering phoenix development (which is
> why you're posting this message, innit?), we need to find a way
> arround that.
This is not about info versus containerkit. It is about Phoenix.
>> b) absorbing of containerkit into Phoenix (giving it x.x.phoenix
>> packages).
>
>
> Given the speed the "common ground" discussions are taking I think
> this is the best compromise. I am a bit concerned about later
> backwards compatibility (if the final "common meta setup" we agree
> upon deviates a lot from the one currently used in
> containerkit/info/phoenix, it'll be a lot of work to get phoenix to
> support both).
We're gong for a scrap current (meta-model) design right for uber right?
> Given recent developments at work, it is unlikely I'll have the time
> to invest to do that conversion work (you might notice me working on
> fortress though ;), so I won't give a +1, but if there's enough peeps
> willing to commit to it, then I certainly don't have any other
> objection, and I'll give an as-supportive-as-possible +0 on option (b).
>
> I would like to see the coupling between phoenix and a specific meta
> model kept as small as possible though, with the eye on easing
> migration to something else later.
That will not change based on the location of container-kit will it?
> I'd also like to see some notice in the phoenix documentation that
> although the meta materials are stable codewise (and supported as
> such), we're not too sure about some aspects yet and thus that there
> may be big changes in future versions (as we already know this, users
> should know too :D).
I don't see why Phonix has to carry adverts for meta (which it does not
use). Meta is in sandbox right?
> I do think a version of containerkit should remain in avalon-sandbox
> as there's stuff to harvest from it in the continuing "common meta
> setup" area.
Given you now understand it is used by Phoenix, do you have a modified
opinion?
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Containerkit
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 8 Jan 2003 19:51, Leo Simons wrote:
> Peter Donald wrote:
> > On Mon, 6 Jan 2003 22:10, Leo Simons wrote:
> >>I'd also like to see some notice in the phoenix documentation that
> >>although the meta materials are stable codewise (and supported as such),
> >>we're not too sure about some aspects yet and thus that there may be big
> >>changes in future versions (as we already know this, users should know
> >>too :D).
> >
> > You are kidding right?
>
> nope. You?
Well if we follow your philosophy we may aswell mark everything as unstable
and likely to change in future versions. There aint nothing that is fixed and
we have not even got close to where we have been heading for last 3 years I
been about.
> >>I do think a version of containerkit should remain in avalon-sandbox as
> >>there's stuff to harvest from it in the continuing "common meta setup"
> >>area.
> >
> > nah. Abandoned code should be removed.
>
> It's not abandoned. Just waiting for refactoring/reintegration.
If no one uses, developes or maintains it then it is abandoned. Someone can
always "refactor" from the actively maintained code or get the archaic code
out of history.
--
Cheers,
Peter Donald
"Man's mind stretched to a new idea never goes back to its original
dimensions." -Oliver Wendell Holmes
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Containerkit
Posted by Leo Simons <le...@apache.org>.
Peter Donald wrote:
> On Mon, 6 Jan 2003 22:10, Leo Simons wrote:
>
>>I'd also like to see some notice in the phoenix documentation that
>>although the meta materials are stable codewise (and supported as such),
>>we're not too sure about some aspects yet and thus that there may be big
>>changes in future versions (as we already know this, users should know
>>too :D).
>
> You are kidding right?
nope. You?
>>I do think a version of containerkit should remain in avalon-sandbox as
>>there's stuff to harvest from it in the continuing "common meta setup"
>>area.
>
> nah. Abandoned code should be removed.
It's not abandoned. Just waiting for refactoring/reintegration.
cheers!
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Containerkit
Posted by Peter Donald <pe...@realityforge.org>.
On Mon, 6 Jan 2003 22:10, Leo Simons wrote:
> I'd also like to see some notice in the phoenix documentation that
> although the meta materials are stable codewise (and supported as such),
> we're not too sure about some aspects yet and thus that there may be big
> changes in future versions (as we already know this, users should know
> too :D).
You are kidding right?
> I do think a version of containerkit should remain in avalon-sandbox as
> there's stuff to harvest from it in the continuing "common meta setup"
> area.
nah. Abandoned code should be removed.
--
Cheers,
Peter Donald
--------------------------------------------------
"An intellectual is someone who has been educated
beyond their intelligence."
--------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Containerkit
Posted by Leo Simons <le...@apache.org>.
Paul Hammant wrote:
> Folks,
>
> This package is now in avalon-sandbox. Given it is used in Phoenix, has
> code that was refactored from Phoenix, I think it is best not to mark
> this package with the 'alpha' status that sandbox affords.
Containerkit is not 'alpha' in the sense of code quality. It _is_ alpha
in the sense of "we're not guaranteeing backwards compatibility on this
stuff (we're not done yet with the meta model disucssion)".
As such I think it fits in sandbox.
However, if containerkit is used and needed in phoenix (looking at my
current phoenix lib dir, it's not, but the info package in sandbox is,
so the principal discussion is the same), and it's alpha state is
hampering phoenix development (which is why you're posting this message,
innit?), we need to find a way arround that.
> I'd like to see how people feel about ...
>
> a) removal of containerkit from sandbox to some place more fitting
I think it fits where it is right now :D
> b) absorbing of containerkit into Phoenix (giving it x.x.phoenix
> packages).
Given the speed the "common ground" discussions are taking I think this
is the best compromise. I am a bit concerned about later backwards
compatibility (if the final "common meta setup" we agree upon deviates a
lot from the one currently used in containerkit/info/phoenix, it'll be a
lot of work to get phoenix to support both).
Given recent developments at work, it is unlikely I'll have the time to
invest to do that conversion work (you might notice me working on
fortress though ;), so I won't give a +1, but if there's enough peeps
willing to commit to it, then I certainly don't have any other
objection, and I'll give an as-supportive-as-possible +0 on option (b).
I would like to see the coupling between phoenix and a specific meta
model kept as small as possible though, with the eye on easing migration
to something else later.
I'd also like to see some notice in the phoenix documentation that
although the meta materials are stable codewise (and supported as such),
we're not too sure about some aspects yet and thus that there may be big
changes in future versions (as we already know this, users should know
too :D).
I do think a version of containerkit should remain in avalon-sandbox as
there's stuff to harvest from it in the continuing "common meta setup" area.
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Containerkit
Posted by Stephen McConnell <mc...@apache.org>.
Paul Hammant wrote:
> Folks,
>
> This package is now in avalon-sandbox. Given it is used in Phoenix,
> has code that was refactored from Phoenix, I think it is best not to
> mark this package with the 'alpha' status that sandbox affords.
>
> I'd like to see how people feel about ...
>
> a) removal of containerkit fr om sandbox to some place more fitting
Hi Paul:
If you scoping containerkit outside of Phoenix then avalon-sandbox is
totally appropriate. Current Phoenix demands on containerkit are
minimal and does not consititute validation of the API. More to the
point - the recent process of unfolding "Context" has introduced a lot
of user content that has a direct impact on the meta model solutions.
The context issues and current direction have already created potential
requirements for evolving containerkit (and the other
avalon-sandbox/meta package). I expect this process to continue and
eventually address some meta-issues such as the real needs for
extendable meta solutions, the need to break the distinction of context
and service - and a bunch of other micro things that only come up when
you get into more complex application scenarios. Most importantly, the
meta area is still fair game for evolution and development - and as such
avalon-sandbox is where that should happen.
>
> or
>
> b) absorbing of containerkit into Phoenix (giving it x.x.phoenix
> packages).
This is probably the easiest option - although there is a downside. It
easiest because containerkit code is inside Phoenix and a little
reshuffling will not take much time. It's problamatic in the longer
term because I think containerkit will be transient as we move forward
on a common meta solution. This means that containerkit can be viewed
as an implementation mechanisms for the current Phoenix descriptors. I
would not like to see Phoenix meta descriptors updated in a release to
correspond to containerkit DTD - that would simply complicate things
unecessarily. The upside of absorbing is that the machinery inside
Phoenix will at least be closer to overall meta direction - and that's a
good thing.
>
> Thoughts gentlemen (and lurking ladies) please...
Something to keep in mind is that containerkit has some chrome to
plunder - but in terms of its role as the Avalon meta model - frankly -
no way. Why? Becuase there is so much discussion needed on this area.
It does not matter if continerkit is good, bad, or whatever. What does
matter is that an avalon meta solution evolves based on progressive
understanding and input from developers and users.
+1 on moving containerkit to Phoenix in the context of a current Phoenix
DTD implementation mechanism
-0 on evolving Phoenix to propergate the containerkit DTD
-1 on pushing containerkit up as a seperate released package
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Containerkit
Posted by Leo Simons <le...@apache.org>.
Nicola Ken Barozzi wrote:
> Peter Donald wrote:
>
> Spice? There is no project here called Spice.
google got me: http://sourceforge.net/projects/spice/
cheers!
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Containerkit
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote:
> On Mon, 6 Jan 2003 09:47, Paul Hammant wrote:
>
>> b) absorbing of containerkit into Phoenix (giving it x.x.phoenix
>>packages).
>>
>>Thoughts gentlemen (and lurking ladies) please...
>
> It may be best to move it into spice when that gets setup correctly. Theres a
> few people using different parts of it but because it is alpha we should be
> able to move it relatively easily. I think that in time parts will spin off
> into other products as they mature but until then we can go the big ball of
> mud approach.
Spice? There is no project here called Spice.
I know you are working on it, but it seams at least wierd to me that you
propose to move a component that a released project (Phoenix) depends
upon into an alpha container that for us is still vapor.
--
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: Containerkit
Posted by Peter Donald <pe...@realityforge.org>.
On Mon, 6 Jan 2003 09:47, Paul Hammant wrote:
> b) absorbing of containerkit into Phoenix (giving it x.x.phoenix
> packages).
>
> Thoughts gentlemen (and lurking ladies) please...
It may be best to move it into spice when that gets setup correctly. Theres a
few people using different parts of it but because it is alpha we should be
able to move it relatively easily. I think that in time parts will spin off
into other products as they mature but until then we can go the big ball of
mud approach.
--
Cheers,
Peter Donald
Einstein argued that there must be simplified explanations of nature, because
God is not capricious or arbitrary. No such faith comforts the software
engineer.
- Fred Brooks, Jr.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Containerkit
Posted by Paul Hammant <Pa...@yahoo.com>.
Jim,
>What other containers use containerkit outside phoenix?
>
>
Enterprise Object Broker (SourceForge) has started to. It is easy to
keep a (phoenix labelled) jar alive to keep that possibility.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Containerkit
Posted by Jim Alateras <ji...@intalio.com>.
What other containers use containerkit outside phoenix?
</jima>
> -----Original Message-----
> From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
> Sent: Monday, January 06, 2003 9:47 AM
> To: Avalon Developers List
> Subject: Containerkit
>
>
> Folks,
>
> This package is now in avalon-sandbox. Given it is used in Phoenix, has
> code that was refactored from Phoenix, I think it is best not to mark
> this package with the 'alpha' status that sandbox affords.
>
> I'd like to see how people feel about ...
>
> a) removal of containerkit from sandbox to some place more fitting
>
> or
>
> b) absorbing of containerkit into Phoenix (giving it x.x.phoenix
> packages).
>
> Thoughts gentlemen (and lurking ladies) please...
>
> - Paul
>
>
>
>
> --
> 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>