All,
The software store has build and runtime dependencies for the libraries, but
only runtime dependencies for the applications. I have found in the past
that the dependencies have been wrong, (build and runtime). I keep saying
that I will check all the possible downloads, but haven't had the
opportunity yet. I don't think that the dependencies have ever been checked
since the store was first created! I suspect that they change with time and
updates?
It's still the case that if someone needs to build a classic application,
then they more or less have to build everything that appears before it in
the top level makefile.
STARJAVA is available on the software store. I was going to make the
complete source available (USSC218 stable branch and latest source) plus the
latest built version. This service will be part of the nightly build.
It shouldn't be too much trouble to export the individual STARJAVA
applications/libraries from the nightly build, if the individual components
have export targets.
I am in the middle of putting the whole of the Starlink software under the
control of the nightly build. The idea is that you will be able to place the
tar.Z source in an allocated directory; the nightly build will then take
care of building it and placing the built version on the Web with news file.
Eventually the build system will just do a checkout of the CVS and do the
build from there.
You could say allot about how we structure/plan the Starlink software.
Mostly it would be about how the overall structure of the software should be
organised and a plan for doing it (do we have such a thing?). Our method of
creating a sticky lump works for us because we can use bits from other
applications/libraries in the collection to save time, effort and
application size. Mark has the best idea, disable the features within an
application if the other components are unavailable. This would be a good
way of reducing the sticky lump problem for STARJAVA. The only other way
would be to include all the required components (i.e. individual class
files) for an application in its jar file.
Steve.
-----Original Message-----
From: David Berry [mailto:[log in to unmask]]
Sent: 26 September 2003 13:01
To: [log in to unmask]
Subject: Re: Obtaining individual components of STARJAVA
Mark,
> 2. Just as with starlink classic, you can't pick up an arbitrary
> jar file (library) and expect to use it straight off, since it
> may have dependencies on other libraries (jar files and native
> shared libraries).
I must be missing something. Isn't that exactly what the software store
does for classic starlink? If you ask for NDF, you also get all the stuff
which NDF depends on. This is what we should have for the java stuff.
As an actualy example of the need for this, Paul Harrison (who used to be
"one of us" a decade ago - a Starlink application programmer [Dr PONGO]
based at Jodrell - and is now an Astrogrid application programmer based at
Jodrell) recently asked about using JNIAST. Mark, did you give him some
directions about how to get JNIAST? If so, what were they?
David
|