Re: Containerkit

[Leo Simons]

 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: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>