On Jan 3, 2011, at 647PM, Peter Firmstone wrote: > Dennis Reedy wrote: >> I'm slogging through classes and jars attempting some modularization of the >> River codebase. Its going fairly well. I'm sitting here scratching my head >> whilst looking at jsk-dl.jar. My question is as follows: >> >> In general jsk-lib.jar is either in the classpath of a service, as well as >> in the classpath of a client. The inclusion of jsk-lib.jar (from a client's >> point of view) brings along helpful utilities like ServiceDiscoveryManager >> and the like. From a service developers point of view, you can't really get >> around not using it. >> >> If jsk-lib.jar is in the classpath (and by inclusion jsk-platform.jar), why >> do we need jsk-dl.jar? Unless I'm mistaken all of the classes that are in >> jsk-dl.jar are already in jsk-lib.jar, why is it needed? >> >> What have I forgotten? >> >> Regards >> >> Dennis >> > I was alluding to that earlier myself, it seems to be there for proxy's to > utilise when clients lack jsk-lib.jar, but in a modular environment this > could cause versioning issues, if the client already has it installed > locally, the release notes simply states: > > The codebase JAR file for |jsk-lib.jar|. An application that includes > |jsk-lib.jar| in its class-path
Yep, saw that. I'm not at all certain that we would ever have a client that does not include jsk-lib.jar in its classpath? > may also need to include |jsk-dl.jar| in its codebase. I find the above statement rather strange. Why would this need to be done if jsk-dl.jar is a subset of jsk-lib.jar? > > Oddly enough a diff reveals that there is one class present in jsk-dl.jar > missing from jsk-lib.jar: > > < com/sun/jini/jeri/internal/http/HttpParseException.class This class is part of jsk-platform.jar (which needs to be in the classpath anyway). So why do we need jsk-dl.jar again?
