1) CLASSPATH Repository Nick and I implemented a ClasspathRepository in Ruper days of old, the thinking being -- to allow updates to be sensitive to a [say] Gump context, and use Gumped jars (in Gump builds) in preference to downloading. I was considering this for Depot, but it dawned on me this was flawed.
There is really no 100% accurate way to analyse/parse all artefacts just from filename, etc. (no group position, no extra metadata, etc). With artefacts in a classpath this is all one gets, so although it would work for many, it'd no work for all. Since Gump is (if I get my way) to create local repositories of jars it creates, maybe we ought just pass those locations to Depot, and use them as normal. I prefer this approach. 2) .../.depot directory I like how CVS and SVN work by storing metadata (repository location., etc) into a dotted local directory. I wonder if we ought have the same (*as and when/if* we need it). We could store thing in there like, where it came from, MD5 checks, etc. I like the ability that CVS|SVN has to 'svn update' a local repository, to (cheaply) just go get updates to what is there without (in our case) hunting around randomly. That might be a nice future optimisation. 3) Put repositories into our SVN for http testing. I wonder if we ought create (under depot) some repositories, and check them in to SVN. We can do unit/integration/whatever testing against them via HTTP (even w/o HTTPS). regards, Adam -- Experience the Unwired Enterprise: http://www.sybase.com/unwiredenterprise Try Sybase: http://www.try.sybase.com
