Berin, > I would be retisent to split the jars at this point because users > *expect* everything to be in there. I am not a fan of splitting > interface/implementation jars unless the interface jar is used for > compilation purposes and not distribution purposes.
For application servers (Phoenix, EOB etc), implementation hiding is *very* important. This is achieved with two things : 1) Use of dynamic proxy 2) hiving off impl to a different (invisible to client) classloader. [To All]: All people embroiled in these discussions, must try to go back a year or two and read out threads on K/HC/CAPI (or was it K/CAPI/HC, darn, I'm muddying google's water now just talking about it). Peter, you have a summary handy? > For instance, I see the number of jars necessary for AltRMI as too many > for deployment. I only need the interfaces to compile, but the > implementation is necessary for the deployment. I would much rather > have the only the Client/Server/Common jars as opposed to Client-API, > Client-Impl, Server-Api, Server-Impl, Common, Generator. That is > my preference. I agree there are alot. I think we could reasonably get it down to three. -ph __________________________________________________ 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
