Re: Renovating the PL/Java build process

On 08/31/20 04:12, Kartik Ohri wrote:
> It is the time of the summer when GSoC participants look back on the work
> done in the past few months and so here are we. The original project idea
> and the project proposal had three major components. Each of these has been
> discussed in detail below.
>
> 1) Continuous Integration
> 2) PL/Java API Artifact
> 3) Replacing nar-maven-plugin

A hearty thank you to Kartik, whose work has provided a renovated build
process that removes many sources of pain in the old one, and should also,
I think, be much more approachable for any newcomer trying to see how
the native code is being built. The plugins formerly used were configured
'declaratively', which can be elegant in simple cases, but once the question
becomes "what do I 'declare' to trick this plugin into doing what it wasn't
made for?", the simple approach here becomes easier to follow.

The new process also picks up the same compiler options that were used
building PostgreSQL, addressing our issue #152, and allows the
-Dpljava.libjvmlocation option to be given at build time even in Windows
(our issue #190) to build a package that will not need that setting
configured at install time when the packaged location for Java is known.

Another thank you to Thomas, who has enabled the main tada/pljava repo
for the Travis-CI and AppVeyor services Kartik used, so that new pull
requests on the master branch (leading toward the 1.6 release) are
automatically checked.

None of this work applies to the currently-released, 1.5.x branch, but
the benefits will appear when the first 1.6 release happens. That is
also when item #2, a pljava-api artifact deployed to Maven Central,
should be expected.

There is one unintended consequence of the current work. It now relies
on the compiling information reported by pg_config as used to build
PostgreSQL (as requested in issue #152), but that information is not
recorded if PostgreSQL was built with MSVC on Windows. Therefore, when
building with MSVC, we use hardcoded options, as before.

A consequence is that building PL/Java with MinGW-w64 against a
PostgreSQL instance built with MSVC is not now possible, because our
MinGW build process relies on pg_config information that the MSVC build
did not record.

I would probably never have dared to try building PL/Java with MinGW
when PostgreSQL was built with MSVC, but it happened by accident for
a while as we worked on CI this summer, and it did in fact work. So,
perhaps, someone may be relying on it.

If so, it will be simple to add back into the new process; it would
just be another set of rules for Windows-MinGW-PGMSVC, and would have
to hardcode the compiling options as the MSVC rules do.

Again, thank you to Kartik. It has been a pleasure collaborating on
this work.

Regards,
-Chap