RFR: gradle buildscript improvements

[danieljarabek]

On Wed, 27 Apr 2022 09:35:00 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

>> I guess I understand both concerns: on one hand, what @sundararajana says it's true: our tests do not fit in the gradle workflow nicely, as they can only be run after an integration step (e.g. the build of the image used to run jextract).
>> 
>> That said, I also get the spirit of the changes here: we're asking developers to say "verify" when in reality what they'd like to be able to say is probably "build". So, if we just s/verify/build and keep "jtreg" as an optional task, what would go wrong?
>
> "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.

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

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