Re: [equinox-dev] [prov] Shared install filesystem layout

["Alex Blewitt" <alex.blewitt@xxxxxxxxx>]

On 13/08/07, Andrew Overholt <overholt@xxxxxxxxxx> wrote:
> * Alex Blewitt <alex.blewitt@xxxxxxxxx> [2007-08-10 18:47]:
> > There was some talk a while ago of creating a /usr/share/java for such
> > things. Given that the .jars are architecture independent (even if
> > some of their contents aren't) I'd vote for not splitting the bundles
> > arbitrarily.
>
> We have /usr/share/java for architecture-independent jars already.  If
> the contents aren't architecture-independent, I'd argue that the jars
> themselves shouldn't be considered architecture-independent.

I'd argue that the Jars should go there, even if the contents are
architecture dependent. The reason for this is that the Equinox
runtime selects which Jars to use based on the current OS's
architecture. Indeed, the OSGi spec allows for a single bundle/jar to
have multiple native libraries for different OSs. So in that sense,
the bundles themselves are architecture independent, even if you use a
subset of each.

One of the distinctions between this and the standard Unix library is
that there's a one-library-per-file in a single .dll or .so, whereas
in the Java case, the .jar is a container which may contain .dlls or
.sos for multiple platforms in the same package. And given a set of
OSGi bundles, you can run on all platforms anyway, as long as all
fragments are available; the runtime uses the one that's correct for
that platform.

On the other hand, splitting up the OSGi bundles arbitrarily will lead
to more difficult packaging for cross-platform installs, and runs all
manner of problems when you're trying to e.g. generate a
cross-platform build on any one platform. Having all the bundles in
one place makes it easy to cross-build a Mac OS X app from a Linux
box; having the bundles split across many places means that it's going
to be much more difficult (to the extent that it may be impossible,
given that there may be assumptions that the os-specific fragment and
the architecture-neutral bundle are in the same directory), not to
mention the issue of where you'd install the non-current-OS bundles
(where would the Mac specific bundles be installed on a Linux box in
order to enable cross-compilation?).

Alex.