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.
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.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.
dunno. Whatever compromise results in consensus I like. Point is we don't have consensus right now.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?
which paragraph are you referring too, the +0 or the loose coupling? The first para will, the second one is less likely to.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 ment "meta materials" as in the phoenix code that deals with it, not the sandbox project.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?
nope.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?
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: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
