On Tue, Jan 26, 2010 at 2:17 PM, Alessio Stalla alessiostalla@gmail.com wrote:
On Tue, Jan 26, 2010 at 1:21 PM, Axel Rauschmayer axel@rauschma.de wrote:
Incidentally, we may be able to autodiscover .asd files by scanning the classpath, and suitably update asdf:*central-registry*.
We first need to agree on a convention to wedge the concept of Pathname into CLASSPATH. I now support your earlier proposal to keep the two separate, as it makes more sense. And I'd like to get the "jar:" part of my changes into the trunk, and tested for a bit before introducing another the next step. Right now, wildcards (and DIRECTORY) don't work inside JARs which would be the first step to autodiscovery.
With Java resources, one is always warned against using the classpath that way. Looking for a particular path is possible, but listing paths (or files) not. It might be safer to introduce an additional concept. This could be an explicit list of Java resource paths or a new kind of ASDF classpath.
Scanning the entire "classpath" (or better, the resources known to classloaders) in general is impossible, since a classloader can create a resource from anywhere (e.g. from a buffer in memory, like ABCL itself does for runtime compilation).
However, it is possible to scan the classpath in the most common cases, i.e. when the resources are either on the filesystem or in some Jar loaded by a regular URLClassLoader.
I agree that doing it right, for some value of right, is far from easy as there are tricky cases (e.g. classloaders used by some application servers) that you might still want to handle.
FWIW, DWIMming the classpath doesn't seem worth the effort. If we can do directory inside and outside jars and get access to the classpath then people can easily build things on top of that.
-Alan