Re: Containerkit

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