Finding the files produced by a PL/Java build

The PL/Java build process using mvn clean install produces files needed to install the language in PostgreSQL, which need to be copied to appropriate permanent locations, and their pathnames may have to be set in pljava.* variables, as the installation page describes.

They are produced in different locations in the build tree and their exact names can depend on platform and version details, so these tips may help in finding them.

The packaged jar file

The pljava-packaging subproject builds a single .jar file. At one time, it was in the business of trying to decide whether Windows, Unix, or Mac users would like .zip or .tar.gz files better, but if you are planning to use PL/Java then you certainly have Java around, and can work with a .jar file no matter what.

Relative to the root of the build tree, the jar file is found at

pljava-packaging/target/pljava-${pgversion}-${naraol}.jar

where ${pgversion} resembles pg9.4 and ${naraol} is an architecture-os-linker triple, for example amd64-Linux-gpp or amd64-Windows-msvc. It contains these things:

pljava/pkglibdir/libpljava-${project.version}.so (or .dll, etc.)
The architecture-dependent, native library portion of the PL/Java implementation (more below). The name might end in .so or .dll or .bundle or something else, and might or might not start with lib.
pljava/sharedir/pljava/pljava-${project.version}.jar
The architecture-independent, Java portion of the PL/Java implementation (more below).
pljava/sharedir/pljava/pljava-api-${project.version}.jar
The jar file that should be named on the javac module path when compiling code for PL/Java (see “How to compile against the PL/Java API” in the user guide).
pljava/sharedir/pljava/pljava-examples-${project.version}.jar
A set of examples demonstrating PL/Java usage, usable also as rudimentary tests.
pljava/sharedir/extension/pljava.control
The file that tells CREATE EXTENSION what’s what.
pljava/sharedir/pljava/pljava--*.sql
Various files scripting what CREATE EXTENSION or ALTER EXTENSION ... UPDATE really do.

It could happen that future versions add more files in the jar before updating this page. Also, every jar file has a MANIFEST.MF, and this file also contains a JarX.class to make it self-extracting; these are not otherwise important to PL/Java. See the installation page for how to control the self-extraction.

Extract the needed files from this archive and place them in appropriate locations, then complete the installation.

Naming the built files directly

When the only purpose is to quickly check the built PL/Java, it may be faster not to extract files from the packaged archive into some other location, but simply to SET the pljava.* variables to point to the files right where they were generated in the build tree.

The PL/Java API jar file

This file is built by the pljava-api subproject, so relative to the source root where the build was done, it will be found in pljava-api/target/pljava-api-${project.version}.jar with ${project.version} replaced in the obvious way, for example 1.6.4.

This file needs to be named in pljava.module_path along with the internals jar file below. If convenient, check the default value of pljava.module_path and place both these files where it expects them to be; then it will not need to be set.

The architecture-independent PL/Java jar file

This file is built by the pljava subproject, so relative to the source root where the build was done, it will be found in pljava/target/pljava-${project.version}.jar with ${project.version} replaced in the obvious way, for example 1.6.4.

In the simplest installation, determine the default value of pljava.module_path and place the jar file at that exact name, alongside the PL/Java API jar described above. In a typical distribution, the default will be $sharedir/pljava/pljava-${project.version}.jar.

The architecture-dependent PL/Java native library

This is built by the pljava-so subproject. Its filename extension can depend on the operating system: .so on many systems, .dll on Windows, .bundle on Mac OS X / Darwin. Relative to the source root where the build was performed, it is at the end of a long and redundant path that contains the project version (twice), an “architecture-OS-linker” string (twice), and a build type (“plugin”), also twice.

An example, for version 1.6.4 and arch-os-linker of amd64-Linux-gpp is (very deep breath):

pljava-so/target/nar/pljava-so-1.6.4-amd64-Linux-gpp-plugin/lib/amd64-Linux-gpp/plugin/libpljava-so-1.6.4.so