Hi Norman.
> 1. I've ended up using a specialised ant task for this <http://
> www.loomcom.com/jarbundler/> -- is that OK, and what should I do as
> regards this and the repository. Given that it should be checked in,
> where should it go? In java/source/ant? It's no great problem if we
> can't use this, however, as I'd almost fully done it by hand already,
> and it was I think only the problem below which forced me to start
> googling.
java/source/ant sounds reasonable enough, but what goes there is
Peter's domain really, he may have an opinion.
> 2. Is there a way, in ant, of converting a classpath (in fact an
> extclasspath) into a FileSet, so that I can produce a list of all the
> jar files which have to be copied into the bundle? My impression
> from the ant docs was that there was not, and that the classpath and
> fileset types were fully distinct, but is there therefore a different
> way of going from the carefully constructed extclasspath, containing
> the full set of dependencies, to the list of jars. What I ended up
> doing was using XSLT to grub through the .jnlp files in java/lib, and
> using the result in an <includesfile>. But it's not obvious how to
> automate that within ant, and it doesn't seem a terribly robust
> solution, since the set of dependencies in the .jnlp files, and the
> largely equivalent dependencies in the Treeview build.xml, are
> apparently being maintained in parallel. Am I missing something?
I don't know how to do that in ant - my usual recourse if I'm trying
to do something in ant that ant doesn't seem to want to help with
is to do it in java and use the <java> task - I'm not sure that's
a recommended approach though.
There's a file in each of the source directories (e.g. java/source/treeview)
called .properties. This contains a list of all the jar files
on which that package is dependent. You may be able to use these
recursively to do what you want to do.
The approach I've taken in TOPCAT to packaging is to stuff everything
into one big jar file for distribution. I do this using
uk.ac.starlink.util.SuperJar, which goes through jar files looking
at their MANIFEST.MFs to find the class paths. See the build-standalone
targets in topcat/build.xml. I'm not sure whether this is basically
what you're doing or not.
> 3. Oh, I used the TREE27.gif image, that you use in the Treeview
> documentation pane, as the application item -- is that all right, Mark?
fine.
> Java-related problems:
>
> 4. When I try running the generated application, I get the results
> below. These show, first, Treeview failing to find libjniast.jnilib
> and libjnihds.jnilib. But is it looking for them in the correct
> way? It's looking in .../Treeview.app/Contents/Resources/lib/ppc/
> libjniast.jnilib for the first one; that's not far off, but it should
> instead be looking inside .../Treeview.app/Contents/Resources/Java/
> ppc/jniast_libs.jar, which is in the classpath. I'm not sure how to
> debug this, but is it possible that whatever it is that's loading
> this is making an unwarranted assumption about library layouts (I'd
> guess not, since the JNLP stuff has been sorted out, but...).
Native library loading is done in uk.ac.starlink.util.Loader.loadLibrary().
It first looks in the directory named by the java.library.path
system property, which is the standard place. If it can't find
it there, then it makes up a likely path ending in lib/{os.arch}
and tries that. So what you ought to do is ensure that java.library.path
gives the actual location of the native libraries.
> 5. Part of the point of all this was that Treeview seemed to have
> stopped working when the application menus were moved to the screen
> menubar on OS X. Well, it's still not working. In the dump below,
> Treeview is halting with an ArrayIndedOutOfBounds exception (as
> before), which appears to be at the pack() in Treeview's
> StaticTreeViewer.java. Is it possible, Mark, that there's actually
> something amiss round here, which possibly changed fairly recently,
> and which somehow hasn't been exercised before? I haven't made any
> changes to Util's tweakGuiForMac, but I can see that's a no-op at
> present.
Not sure I understand the question. It works fine on other platforms,
and it's continuing to fail in the same way on mac only when the
apple.laf.useScreenMenuBar is set true. I'm not sure why you think
it might be anything other than a mac-specific bug related to
apple.laf.useScreenMenuBar. As for changed fairly recently: no.
Mark
--
Mark Taylor Astronomical Programmer Physics, Bristol University, UK
[log in to unmask] +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/
|