Le mercredi 09 mars 2005 à 13:17 -0500, Thomas Fitzsimmons a écrit : > On Wed, 2005-03-09 at 09:20 -0800, Anthony Green wrote: > >On Wed, 2005-03-09 at 11:24 -0500, Thomas Fitzsimmons wrote: > >> I've been seeing that message too. First of all, why does the urls > >> field of VMClassLoader not print *all* jars in the extensions directory? > >> Is this a libgcj bug? > > > >It certainly looks that way. > > > >> The other annoying thing is the difference > >> between /usr/share/java-ext, /usr/lib/java-ext and /usr/share/java/ext. > >> We either need to change the JPackage standard to point > >> to /usr/share/java/ext or we need to hard-code /usr/share/java-ext > >> and /usr/lib/java-ext into libgcj as extensions directories. Defining > >> java.ext.dirs in all the wrapper scripts is turning out to be quite > >> fragile. In this case the mx4j jar probably installs > >> in /usr/share/java-ext and it doesn't look like java.ext.dirs is getting > >> set properly (to /usr/share/java-ext:/usr/lib/java-ext) for you. > > > >I don't think that's really the problem, since mx4j doesn't install in > >any extensions directory. It probably should for gcj at least, since > >it's included in Sun's rt.jar. > > > >But it seems that gcj should have it's own extension directory. > > > > That's a good idea. Then we wouldn't have all these problems associated > with trying to match Sun's JAR layouts (e.g. classpathx-mail embedding > an inetlib implementation, ugh). We could just create jar file symlinks > (mostly to libgcj.jar) for programs that look for the actual jars. > Everything else they needed (e.g. providers) would transparently be > included on CLASSPATH by way of the gcj extensions directory. In fact, > we could just keep using /usr/share/java/ext for that purpose. What are > the ramifications of putting jars in the extension directories? Please don't use /usr/share/java/ext. You'll get into big problems the day two gcj versions are deployed in parallel (think gcc4) if they share the same extension dir. It's much easier to have separate dirs (possibly with symlinks pointing to a common pool) than to handle things like "I want to include all the jars in this dir except this one which is used by another version". This being said, the way JPackage does stuff is not fixed in stone, it can change for the next release if people think it could get better. (only please remember we have already a full repo built around the current rules, so don't ask for changes just for cosmetic value) Regards, -- Nicolas Mailhot
Attachment:
signature.asc
Description: This is a digitally signed message part
