On Wed, 11 Jan 2006, Mark Taylor wrote:
> 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.
In general I'd say if this isn't used a lot, keep it elsewhere and use a
<taskdef/> to pick it up, otherwise unbundle the source code and add it to
ant/src/main (yes, like the roxes stuff, reading on), that should make
sure it's always available.
>> 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.
My approach was to write some simple shell scripts that look at the
.properties files and output a list of dependencies for a package (see the
scripts directory).
The way to convert an extclasspath (or any other path) into a string is to
convert it to a property first:
<extclasspath id="installed.classpath">
<stuff.../>
</extclasspath>
<property name="test-extpath" refid="installed.classpath"/>
<echo message="${test-extpath}"/>
>> 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.
Note that you cannot dl-load a library in a jar file either, it has to be
unpacked first.
Cheers,
Peter.
|