Chiming in here, perhaps off topic... Sometime back (maybe within the past year?) there seemed to be agreement on removing the ClassPath manifest attributes moving forward in order to not make assumptions concerning relative jar locations (e.g. classpath built from local Maven repo).
-jeff On Sun, Jan 2, 2011 at 8:36 AM, Greg Trasuk <tras...@stratuscom.com> wrote: > > 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 <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 >> >> >> >> >> > >> > > >
