[Pljava-dev] PL/Java build/installation rework ready to merge

This morning I made a pull request at the PL/Java GitHub repo
to improve the build/installation experience in a bunch of ways
first laid out back in July:

https://github.com/tada/pljava/pull/76

On 07/19/15 16:11, Chapman Flack wrote:

> maven setup easily builds me a working pljava every time and seems quite
> solid. ... maybe other
> platforms have build issues that could be improved.

The pull request resolves the build/install issues that were open for
Windows, Mac OS X, and Centos, confirmed by testing on those platforms.

> For a new user, the process of getting
> it set up in postgres, the first time, is more fiddly than it could be,
> and that's where some valuable improvements could be made.
> ...
> * The wiki is way overdue for some love. For example, the maven-based
> build is working great as far as I can tell, and the makefiles are
> obsolete, but the wiki 'building' page doesn't even say maven yet
> (issue 18).

A lot of brand new build/install/use documentation comes with this pull
request. It will become the http://tada.github.io/pljava/ site once the
branch has been merged. (Before that, it can be viewed by running
mvn clean install ; mvn site site:stage
in the branch, and pointing a web browser locally at target/staging.)

> * The javadocs aren't viewable on the github site. There is plenty of
> good javadoc in the code,

Javadocs at the http://tada.github.io/pljava/ site since September.

> * The issue tracker doesn't have a huge number of issues, but some are
> rather old.

19 issues (some back to 2013) have been closed since July, leaving 16.
This pull request will close 9 more, and partly address another 2.

> * Issue 11, about regression testing, is super important, because a
> lack of good regression testing can have a chilling effect on
> participation. It is scary to dive in and start banging on code

An earlier-discussed plan for testing was half-implemented in
early October with pull request 56. There's half still to go, easier
to implement after this PR.

> TIME TO REVISIT BACKWARD COMPATIBILITY TARGETS ?

Current compatibility targets in this branch:
Java SE 8, 7, 6; PostgreSQL 9.5, 9.4, 9.3, 9.2. With minor
function loss: 9.1, 9.0, 8.4.
8.3, 8.2 aren't tested but I've tried not to knowingly break
them - there's a large 8.2-derived project recently returned to
open source, with a really old PL/Java variant, and I'd like an
upgraded PL/Java to be an option there.

> 8.1 added SET ROLE; PL/Java still only understands the three IDs
> a session had before 8.1 ... That leads to strangeness like:
> ...
> => SET ROLE schemaowner;
> SET ROLE
> => CREATE TABLE foostuff.test;
> CREATE TABLE
> => SELECT sqlj.install_jar('foo.jar', 'foo', true);
> ERROR: permission denied for schema foostuff

Fixed in this branch.

> 9.1 brought the extension-packaging system, which could offer a
> target for PL/Java's various deployment methods to converge on.
> One thing it can do is automatically select and run schema-updating
> scripts, which is an outstanding PL/Java issue (#12).

This pull request includes automatic schema updating (from any schema
PL/Java has used since 12/2006), but /not/ built on the 9.1 extension
facility, and working even on versions before 9.1. A thin wrapper can
make it usable via the extension facility too; that's not in this patch,
but forthcoming.

> STREAMLINING INSTALLATION/DEPLOYMENT
>
> As PL/Java has been getting built, there is one part of installation
> that doesn't quite fit with the others. *Almost* everything about
> PL/Java gets configured using PostgreSQL's own mechanisms
> ... but the location of libjvm itself has not been.... pick one of the
> solutions from the wiki that are all system-dependent and outside of
> PostgreSQL (from the "installing on linux" page, edit LD_LIBRARY_PATH
> in a PostgreSQL startup script, or tweak /etc/ld.conf.so, or, from
> the "building pljava" page, figure out the right link options to build
> the native library with an RPATH).

Now specified with a configuration variable, pljava.libjvm_location,
just like anything else configurable in PL/Java. If the setting isn't
right and the library isn't successfully loaded, a clear PostgreSQL
error identifies the problem and a familiar PostgreSQL SET command
fixes it.

This also gets around an annoying Mac OS X misfeature of an Apple
download dialog being interposed in requests for the Java runtime.

> ... It could do the same with
> pljava.classpath if the jar isn't found, and then even complete the SQL
> installation steps if the objects aren't there yet. It could then
> log those working settings and remind you to add them into
> postgresql.conf, or (in 9.4+) even use ALTER SYSTEM to do that directly.
>
> As a result, it could be possible to quickly try out PL/Java without
> editing any configs at all: just start with
>
> LOAD /path/to/pljava.so;
>
> and then issue SET pljava.libjvm_location and SET pljava.classpath
> commands as the messages suggest, and watch it go.

That's what it does, ending the need for the Deployer or install.sql
formerly used.

Testing reports, impressions of the new documentation, etc., are
welcome. In an earlier pljava-dev thread there was discussion of
advancing the version number in Maven to 1.5.0-SNAPSHOT and setting
the wheels in motion for a 1.5.0 release. After this pull request is
merged, I think it could be about time, modulo a few quite small things.

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