RE: VisAD Version


     I want to apologize on two counts:

1. It is not true that the file in visad.jar is called Date instead of DATE.
I was using WinZip to look at the JARs, and that is what it lists as the
file name.  It must be a holdover from early Windows days, when Explorer did
that to files with uppercase names.  Other means of viewing the file
contents indicate the file is named DATE as it is expected to be.

2.  I do not need to use getSystemResource().  Using "/DATE" with
getResource() works for visad.jar and "DATE" works for the source
distribution.  "/DATE" also works with the Eclipse classloaders.  I have
fixed my build to make a DATE file at the same level as the visad directory
in the source tree, so I can distinguish versions now -- what I wanted.

     What I am using is:

    Class cls = Display.class;
    URL url = cls.getResource("/DATE");
    if(url == null) url = cls.getResource("DATE");
    if(url == null)  return "Version not found";

     The bottom line is that the suggestion to use the DATE file is good and
solves my problem.  One does need to realize when the DATE file is changed,
however.  Sorry for the static.


-----Original Message-----
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.

To unsubscribe visad, visit: