[Pljava-dev] the archive produced by pljava-packaging

Since the move to Maven, an end-product of the build has been an archive
named something like pljava-pgM.N-arch-os-linker(.tar.gz|.zip) where the
.zip format is chosen if building on Windows, .tar.gz anywhere else, and
the archive contents are otherwise the same. The contents are the
important build artifacts, under fixed names: pljava/pljava.so (or .dll,
etc.), pljava/pljava.jar, pljava/examples.jar, ....

As far as what PL/Java 1.5.0 will need for successful execution, the aim
has been to have no hardcoded requirements for where the important files
can go, but rather to have GUC variables that can point to them wherever
they are. That's deliberate because there can be database admins who don't
have root on the server box, or don't otherwise have permission to plant
files in particular standard places, or are setting up unusual installations
(multi-tenant, for example) and have reasons to want different locations
for the PL/Java library, jar, and supporting files. PL/Java itself is
designed to work in any of those situations as long as the GUC variables
are properly set.

All that being said, some well-chosen default locations would simplify
installation in common, uncomplicated, "sudo install something and go"
situations. Looking at existing PG extensions, it seems common to assume
write access to PKGLIBDIR to put the native library there, and to
SHAREDIR/... for other supporting files, particularly SHAREDIR/extension
for .control and .sql files. By choosing default locations and making those
the default values of PL/Java's GUC variables, there could be an
uncomplicated installation without having to set those variables.

The way pljava-packaging currently builds the package archive, you
would still have to extract the few necessary files from it
and manually scatter them out to the 'standard' locations.

Here is a proposal:

1. Build the package archive with directory prefixes based on the
pg_config keys for standard locations. The contents would be
something like:

pljava/PKGLIBDIR/pljava-so-1.5.0.so
pljava/SHAREDIR/pljava/pljava-1.5.0.jar
pljava/SHAREDIR/pljava/pljava-examples-1.5.0.jar
pljava/SHAREDIR/extension/pljava.control
...

The paths are based on pg_config keys (and not what those keys
expand to on the build system) so the archive can be built once
and used on other systems where the versions are compatible but
the filesystem locations might be different.

2. Build the archive in one format always, instead of somewhat
arbitrarily choosing .zip for Windows and .tar.gz for anything
else. Rationale: Q. What software component will *all*
prospective users of PL/Java be sure to have? A. A Java runtime.
Q. What archive format is always supported by a Java runtime
even with no other tools present? A. zip (or jar, based on zip).

3. Build the archive to contain extraction code. Again, every
prospective user has Java, any jar file can have a main class, and
the class format is platform independent. A simple extractor can
be written in Java that executes pg_config to find the locations on
the target system and extracts the archive, rewriting the directory
keys to the correct locations.

That way, a "standard" installation can be done with just the command:

java -jar pljava-pgM.N-arch-os-linker.jar

while for any other installation it would be treated as an ordinary
zip or jar file and extracted, and the files manually moved to where
they are wanted. (Or, allow the built-in extractor to accept commandline
arguments like PKGLIBDIR=... to override what it would obtain from
pg_config.)

I think this would address issue #6.

Thoughts?

-Chap
_______________________________________________
Pljava-dev mailing list
Pljava-dev(at)lists(dot)pgfoundry(dot)org
http://lists.pgfoundry.org/mailman/listinfo/pljava-dev