RFR: gradle buildscript improvements

[Maurizio Cimadamore]

On Thu, 28 Apr 2022 12:25:50 GMT, danieljarabek <duke at openjdk.java.net> wrote:

>> "jtreg" target requires additional toolset (cmake, C compiler, jtreg) at the user end. This is not the usual pure Java project "tests" which don't need any of these. Already "verify" doesn't depend on "jtreg" (verify is just build of jextract image + a simple integration test to extract a test.h). "jtreg" perhaps can skip the "project jextract image" + "integration test" step. i.e., after jar straight build test JDK image with jextract and run all jextract tests. But, not sure how much is saved by that.
>
> To me at least, it would make sense for the "build" task to create the final artifact designed for users. This help would avoid confusion from people who didn't fully read the README, and try to simply run the "build" task (then try to run the jar in build/libs or otherwise do something incorrect/unsupported). Perhaps it may even be best to print a message announcing the correct location of the final artifact since developers familiar with gradle may assume that it just builds a executable jar like most projects. However I also understand how this project doesn't fully fit into the gradle build lifecycle. I'll leave it up to you two to decide what we want the final build process to look like. I'm happy to implement whatever approach you decide on in this PR.

At the moment it is:

build -> build the jextract classes
verify -> build jextract image and run small integration test - depends on build
jtreg -> run all jtreg tests - depends on verify

Now, we don't want "jtreg" be part of the build pipeline, because running tests require setting up compilation of native libraries, which might not be possible for users. 

That said, on "verify" we're more flexible. I think another good stacking could be:

build -> build the jextract classes and image
verify -> run small integration test - depends on build
jtreg -> run all jtreg tests - depends on verify

This means that doing `gradle build` (which is probably what majority of users will reach out for first) will produce something useful.

-------------

PR: https://git.openjdk.java.net/jextract/pull/25