On Fri, 26 Sep 2003, Mark Taylor wrote:

> > both of which are deadends (no ../ relative parts in their
> > class-path manifests). So this tells us that JNIAST also needs the UTIL,
> > JUNIT and ANT packages.
>
> true, and this would work, but it is often the case that they explode
> to reference pretty much everything. For instance TABLE uses just one
> class from FITS, but FITS references ARRAY, NDX, HDS, JNIHDS, JNIAST,
> HDX ... none of which TABLE requires. So it may not be very efficient
> in a lot of cases.
>
> > The simplest way to manage this is therefore to extract this information
> > from the package build files (probably best to put this in a local file
> > that is read during the build and can be easily found/parsed by any
>
> util.SuperJar automates this process by looking in the manifests
> themselves, though I'm not saying it's necessarily the best way to
> do it (I knocked that class up for my own purposes and it may not be
> bulletproof).

Hi Mark,

I'm a little concerned that you want to peek within a package and decide
what to lift, without some kind of formal mechanism to say this is OK.
Packages are the real atoms of our system.

However, I can see that producing a standalone jar file for people just
wanting a single application could be useful, so I'm not going to argue
against judicious use of your approach.

> > supporting process). Any takers to hack the (currently) 36 build files to
> > do this?
>
> that sounds like my cue to remember I'm working for ESO till december.

But I have decided to offer my alternative for finding out a package's
dependencies, and to this end have made some changes to the build system.

For all the packages with Class-Path entries pushed into the main jar file
manifest, I've extracted this information into the local ".properties"
file as the property "jar.class.path", so this information is now still
easily available to ANT, but clearly identified.

To complement this I've written three small shell scripts (couldn't work
out how to make ANT do this job, probably just a mindset issue), that list
the immediate dependencies of a package, list all the dependencies and run
an ANT target on all the dependent packages (so it's also a useful way to
make sure everything you depend on has been recently built/installed).

So:

   % ./scripts/echodeps splat/.properties

outputs the jar.class.path parameter reformatted as a list of the packages
that SPLAT depends directly on.

   % ./scripts/packagedeps splat

List all the dependencies of SPLAT (the results are reported to the
screen and to a file splat.depends).

Finally:

   % ./scripts/targetdeps splat export-runonly

will execute the export-runonly target of SPLAT and all the packages that
it depends on (a interesting alternative would be "install" to an empty
directory, that could be just tarred up as an immediate alternative to
SuperJar).

What's missing is some way of putting the tarballs/zip files together in a
larger container, controls for unpacking them and setting up the necessary
variables etc. to get it all to run. Sounds like some body else's problem.

Note these script must be run from the "source" directory as show above.

Cheers,

Peter.