On Sun, 2011-01-02 at 03:51, Peter Firmstone wrote: > I agree that dynamic proxy classes should remain dynamic downloads, > however much of net.jini.* isn't in the jsk-platform.jar > > Should we expand the platform to contain all net.jini.*? > > Except for providers? (com.sun.jini.resource.Service, similar to Java's > sun.misc.Service and java.util.ServiceLoader) > > Perhaps we can include more in the platform and reduce the number of jar > archives we've got? > > Any thoughts? >
I'll grant you that I generally use 'jsk-platform.jar' and 'jsk-lib.jar' together. Having said that, I can picture a minimal client that doesn't use eventing, etc, so could get by with just 'jsk-platform.jar' (for instance a web application), and I don't see anything wrong with the platform jar reasoning in 'doc/release-notes/index.html' so I'm not inclined to change it. Most of the other jars in the lib directory are the contents of service implementations or command line utilities packaged as executable jars, so I don't really see a great problem with them. > Cheers, > > Peter. Cheers, Greg. > > tras...@trasuk.com wrote: > > Isn't that already jsk-platform.jar? I would object to anything that > > subverts the dynamic proxy loading concept that is central to Jini. > > > > It is imperative that people don't, for instance, get the service-registrar > > proxy impls in their local class path. That would break compatibility with > > future or alternate impls. > > > > Cheers, > > Greg > > ------Original Message------ > > From: Sim IJskes - QCG > > To: river-dev@incubator.apache.org > > ReplyTo: river-dev@incubator.apache.org > > Subject: river.jar > > Sent: Dec 31, 2010 10:07 AM > > > > Hello, > > > > anybody have an objection against a river.jar in the build that contains > > all river runtime classes? > > > > Gr. Sim > > > >
