Re: the ScriptingMojo

From: Chapman Flack <chap(at)anastigmatix(dot)net>
To: Kartik Ohri <kartikohri13(at)gmail(dot)com>
Cc: pljava-dev(at)lists(dot)postgresql(dot)org
Subject: Re: the ScriptingMojo
Date: 2020-08-28 12:13:21
Message-ID: 5F48F4E1.4020400@anastigmatix.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pljava-dev

On 08/27/20 23:59, Kartik Ohri wrote:
>> How about compile() and link() returning int, and just returning the
>> exit status of the command, so the common code can compare to zero
>> or throw MojoFailureException. Just info()ing it isn't enough; yes,
>> the build would probably fail at a later step, but it wouldn't be
>> immediately clear where it had gone wrong.
>>
> Regarding this, I was thinking if we could return a ProcessBuilder rather
> and execute the command in the common code. The only issue I thought that
> may arise is when we try to PIPE the output of the ProcessBuilder because I
> am sure how that is done. What do you think ?

I think that when reading the piped output from the process, the different
platform implementations will want to process it differently, because the
messages from different compilers will match different patterns. That
might involve having runCommand take another parameter that is a filter
for messages, and each implementation would pass its own filter. That
means it is probably easier to continue invoking runCommand within the
implementation.

But returning the exit code so the common code can check it and throw
MojoFailureException would be easy.

It occurs to me that now that the pljava.libjvmdefault business is
implemented in the script, it would be worth testing to make sure
it works on all platforms. After #289 is merged, that would just
mean passing the -Dpljava.libjvmdefault="$libjvm" on the mvn command
line (after computing the right $libjvm), and removing the
pljava.libjvm_location settings from [1] and [2], and making sure
everything still passes.

Also, unit testing. Have you added jUnit tests in a Maven-built
project before? It is fairly straightforward; you can add some
Java files under src/test/java and if Maven finds any there, it
will build them and run them as tests.

There are, so far, very few examples in the PL/Java codebase, so there
is not a very high existing bar for you to meet, but it would be
worthwhile to start the ball rolling by having at least one file in
pljava-pgxs/src/test/java with a small handful of tests in it.

An existing example you can look at is in pljava-api/src/test/java.

One good candidate for testing would be getPgConfigPropertyAsList.
It should be tested on some systematically-constructed examples
as well as on a real-world example like [3].

Regards,
-Chap

[1] https://github.com/tada/pljava/blob/943152b/.travis.yml#L112
[2] https://github.com/tada/pljava/blob/943152b/appveyor.yml#L130
[3] https://travis-ci.com/github/amCap1712/pljava/jobs/378459461#L2217

In response to

Responses

Browse pljava-dev by date

  From Date Subject
Next Message Thomas Hallgren 2020-08-29 07:25:17 Re: Travis and AppVeyor continuous integration [Re: feature/master/ci]
Previous Message Kartik Ohri 2020-08-28 03:59:54 Re: the ScriptingMojo