On May 19, 2010, at 1007AM, Patrick Wright wrote: > It seems you would want > - the service to post a hash of the required dependency/DL JAR file > that it expects you to use; this not only helps guarantee > authenticity,
True, but I suggest that in general you already know what these are. You would need to in order to build your client (or service) that uses the associated service. > but also allows the client to recognize when it already > has the correct version available, and when a DL JAR has been updated > (e.g. the local version needs to be replaced or updated with a new > version) I suppose conventions could also be used that include version information as part of (DL) jar construction. Versioning information could also be obtained from a jar's manifest, and checked prior to downloading. > > - some sort of naming/coordinate system for the JAR files. Several JVM > lang communities seem to be agreeing that whatever its other faults, > Maven's means of identifying artifacts is convenient > (groupId:artifactId:version:classifier:scope etc). This is already fairly well established with conventions like Maven (as you point out). > > - some flexibility in how the install of the JAR takes place. There > are several toolchains already in place, such as Maven, and Sun is > working on one for Project Jigsaw which also installs "modules" to the > local system. Sure. This could certainly be abstracted, and the only real agreement needs to be that whatever resolver is put in place to resolve (read download & install) jars (artifacts), and produces a classpath from the resolved artifacts. > > At our shop we haven't ever had the need to update the service DL JAR > on-the-fly, In practice I havent seen the need to do this either. Which makes me think that 9 times out of 10 (if not more) the use cases here generally surround the need for dynamic distributed computing, but dont address completely unknown services where you dont have (or cannot easily get) the requisite service DL jar deps at build & deployment time. This may change if River ever 'really' enters the internet, but in general we're addressing LAN (sometimes (WAN) type deployments. Regards Dennis
