river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Trasuk <tras...@stratuscom.com>
Subject Re: river.jar
Date Sun, 02 Jan 2011 16:36:01 GMT

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 <jini@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.
> >
> > trasukg@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
> >>
> >>
> >
> >


Mime
View raw message