avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Hammant <paul_hamm...@yahoo.com>
Subject Re: Containerkit
Date Tue, 07 Jan 2003 10:41:20 GMT
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:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message