> > I don't doubt it's useful. I'm just afraid that as > /usr/pkg/share/classpath and /usr/pkg/lib/java fills up with jars you'd > end up with a twisting maze of little packages, all the same. Is there > some particular application that forces you to work around with JARPATH?
nope, it's my own invention. JARPATH is an user-defined environment, the JARPATH definition in my script was just an example. > Unfortunately, some projects use CVS snapshot JARs of other projects in > their releases, some projects break binary compatiblity in their JAR > releases, and so on. So if you undiscriminately put all JARS on the same > CLASSPATH, you can have interesting problems, to say the least. I know. But this is the work that user must do. He can put all their jar files there and all will work ok. what do you think? it's just a feature, JARPATH doesn't exist, is just a simple idea to bring this capability. User must know what is doing when defining this env-var. Isn't standard. but kaffe isn't java ;) remember? > In the long run, I'd rather propose to switch gradually to Classpath's > ClassLoader code, fix whatever is broken with it, and extend it to > support resolution of Class-Path: entries in the manifest. Then it would > be much easier to run applications 'the way the developers intended'. ok _______________________________________________ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
