Am I right in thinking/remembering that, with the exception of the *-dl.jar files, the only others that are needed are the jsk-*.jar ones.
I'm pretty sure that many of the JARs contain the same class files, I think that there's definitely scope to reduce the number JAR files that the build creates. On Sun, Jan 2, 2011 at 8:51 AM, Peter Firmstone <j...@zeus.net.au> 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? > > Cheers, > > Peter. > > 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 >> >> > >
