Hi,
The response below was part of the response in the "Re: Problem with
Display.ZAxis Using Different Colors for same Z" thread. I am making it a
separate topic.
In response to my request:
That helps, but I would like to get the [VisAD] version from the program.
The main reason is to check that you are running the version you think you
are. But there are others, like helping a person who is using your
application and having problems. Thanks,
Curtis Rueden responded:
As far as I know, there is no API call to retrieve the version
programmatically. But it would be a simple matter to retrieve the DATE file
with a getResource call (it is stored within visad.jar), then extract the
version string from it. You could then display the string in your software.
VisAD is not numbered according to any other versioning scheme other than
datestamps (the Java version has always been "2.0").
It wasn't so simple. I tried that with the following code:
Class cls = Display.class;
URL url = cls.getResource("DATE");
if(url == null) url = cls.getResource("Date");
if(url == null) url = ClassLoader.getSystemResource("DATE");
if(url == null) url = ClassLoader.getSystemResource("Date");
if(url == null) return "Version not found";
There are some problems:
It works fine if the classpath points to the source distribution, since
there is a DATE file in the visad directory. It seems to have the date of
the latest *source* JAR creation. It gets found as a class resource (first
try above). All is good.
According to the makefiles, there should be a file named DATE in the
top-level directory of the visad.jar file, the one with the classes. It has
the date the *classes* JAR was created. The visad/DATE "resource" is not
copied (or recreated) with the classes into this JAR. In addition, in my
Feb 15 version of visad.jar, this file is named Date, instead of DATE. (I
conclude the JAR was created on Windows, since that is the OS that can't
tell the difference.)
In addition to having the wrong name, there is the problem that it can't be
found as a class resource from a VisAD class, probably since there are no
classes at the top level in visad.jar. I added the getSystemResources lines
above to get around this. This works if the classpath is visad.jar.
However, doing it this way in general presumably relies on no other
applications having a DATE file. It doesn't seem to be the right way to go
to define a VisAD resource. It should not be a system resource.
Finally, it does not work at all when my application is an Eclipse RCP
application. The reason is that Eclipse uses its own classloaders, and does
not use the usual classpath. (It has to find things in its plug-in
directories.) Not surprisingly, it doesn't find DATE (or Date). In
general, it may not work with other, non-default classloaders.
Sorry to be a pain (and I may have overlooked something ;-),
-Ken
==============================================================================
To unsubscribe visad, visit:
http://www.unidata.ucar.edu/mailing-list-delete-form.html
==============================================================================
