On Mar 29, 2005, at 16:40, Dan Streetman wrote:
Hi Dan:
How about referencing the property via the class-path attribute in the jar files for javax.usb? This property works even when using the -jar option (it is designed for this kind of applications).
I'm not familiar with that, is it part of the META info/file?
Yes, it is. It allows you to specify absolute or relative paths to be added to your CLASSPATH dynamically. It doesn't actually change the environment variable itself, but is part of the constructed classpath the JRE builds at runtime.
It's part of that construction whether or not you start an application via the -jar parameter, which is why it would solve the problem in this case.
One thing I'd urge is that if you are going to use this to solve this situation, use relative paths as opposed to absolute paths. Not all platforms are going to have a "/opt" directory, either because of how drives are mounted (ie: OS/2 and Windows), or because it's not really a standard directory on the system and doesn't fit into how the system handles property files (Mac OS X). Indeed, this whole system if applied to the JAR files would be equally problematic, as your chosen path is tied to Unix-style OS directory naming schemes.
I'll think on this for a bit. We had to go through similar design difficulties with the jSyncManager Project some time back.
One possible solution -- have your RPM install-time script create symbolic links of the JARs and the property files inside your /opt/javax-usb directory tree into the jre/lib/ext directory, using relative paths to reference the properties file. This would absolve you from having to have different JAR builds for different OS platforms.
I'll play around with it a bit, and will let you know what works well across different platforms.
Brad BARCLAY
=-=-=-=-=-=-=-=-=-= From the Mac OS X Desktop of Brad BARCLAY E-Mail: [EMAIL PROTECTED] Web: http://www.jsyncmanager.org
smime.p7s
Description: S/MIME cryptographic signature
