Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Subject: Re: river.jar
From: Greg Trasuk <trasukg@stratuscom.com>
To: river-dev@incubator.apache.org
In-Reply-To: <4D203C95.1010404@zeus.net.au>
References: 
	 <868267689-1293812305-cardhu_decombobulator_blackberry.rim.net-1615482016-@bda634.bisx.prod.on.blackberry>
	 <4D203C95.1010404@zeus.net.au>
Content-Type: text/plain; charset=iso-8859-1
Message-Id: <1293985847.3904.8.camel@cameron>
Mime-Version: 1.0
Date: Sun, 02 Jan 2011 11:30:47 -0500
Content-Transfer-Encoding: 7bit


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.

> 
> 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
> >
> >