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 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.).so or .dll
or .bundle or something else, and might or might not start with lib.pljava/sharedir/pljava/pljava-${project.version}.jarpljava/sharedir/pljava/pljava-api-${project.version}.jarjavac 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}.jarpljava/sharedir/extension/pljava.controlCREATE EXTENSION what's what.pljava/sharedir/pljava/pljava--*.sqlCREATE 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.
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.
jar fileThis 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.7.
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.
jar fileThis 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.7.
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.
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.7 and arch-os-linker of
amd64-Linux-gpp is (very deep breath):
pljava-so/target/nar/pljava-so-1.6.7-amd64-Linux-gpp-plugin/lib/amd64-Linux-gpp/plugin/libpljava-so-1.6.7.so