On Sun, 2011-01-02 at 11:15, Tom Hobbs wrote: > 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. >
I think you might be mistaken about that. The *-dl.jar files often contain duplications of classes in *.jar files, but that's reasonable and expected. The few service implementation jar files that I've looked at contain ClassPath manifest attributes that reference jsk-lib etc. The only real duplication I'm aware of is in the jini-core.jar, jini-ext.jar and sun-utils.jar files, that duplicate the contents of jsk-platform and jsk-lib. This is done for backwards compatability (that's the way it was in Jini 1.0-days), and could probably be deprecated at this point, after consulting with the user community. Cheers, Greg. > On Sun, Jan 2, 2011 at 8:51 AM, Peter Firmstone <[email protected]> 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. > > > > [email protected] 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: [email protected] > >> ReplyTo: [email protected] > >> 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 > >> > >> > > > >
