Gradle plugin should run on `build` and not require `quarkus-build`

[vorburger]

I find it sub-optimal that the Gradle plugin requires you to remember to run the quarkus-build task explicitly. Would it not make sense to let users be able to simply run the regular Gradle build task? I do understand this is possible to do "manually" in a build.gradle - what I'm suggesting here is how about making that the default? There must be some way to "bind" it accordingly, although I wouldn't know exactly how to do this in the Gradle plugin code, without digging into it more.

Or is this intentional and better stay like this? If we had a look elsewhere, if I correctly understand e.g. Spring Boot's gradle-plugin doc, quote: "Configures the assemble task to depend on the bootJar task." that means they actually do something like what I'm suggest here?

@stalep @jnizet @renannprado @geoand @Sanne you may have some pro/con thoughts on this?

[renannprado]

I support the idea, then it means that only to build the native image we'd have to run a "special" command, right?
Unfortunately I don't have any hints I could give regarding the implementation 😔 . I do plan to contribute though, I just don't have time do it right now.
Thumbs up from me!

[jnizet]

As a Gradle user, I indeed expect the standard assemble life-cycle task to build the artifact(s) for my project. In a Spring Boot project, building the executable jar file is thus expected. In the case of Quarkus (which I know a whole lot less than Spring Boot), it's not clear what this artifact is, though. Is it the jar file that, I guess, is meant to be executed using the JVM, is it the native executable for GraalVM, or is it both?

I guess it should be both (at least if GraalVM is available or if the quarkus extension is configured to produce one)

Writing this, I realize that something else should really be changed: the name of the gradle tasks. The convention if to name them like Java methods, in camelCase. Gradle uses that to provide shortcuts. For example, instead of ./gradlew javaCompile, you can just use ./gradlew jC.
Tasks names become Groovy/Kotlin variables, and you should be able to reference the tasks directly, without using a string:

    assemble.dependsOn(quarkusBuild)

Having a dash in the name makes all this more difficult than it should, and breaks one additional Gradle best practice.

[geoand]

@vorburger This sounds like a very reasonable idea to me, especially given the fact that in the Maven world mvn package would indeed produce the desired artifact without one having to do quarkus:build.

@jnizet In the case of Quarkus, for normal JVM mode the artifact is the -runner jar along with the lib directory that contains the dependencies (of course it's also possible to configure the plugins to produce an uberJar but we don't do that by default).
The native binary can also be an artifact, but the way we prefer to produce is by opting in (in Maven we recommend activating a profile).

[vorburger]

Just to clarify, I did not mean this to be about gradle quarkus-native, just the regular Java build.

Writing this, I realize that something else should really be changed: the name of the gradle tasks.

do you want to open a separate issue about that? (And perhaps contribute a change proposing that?)

[jnizet]

@vorburger I've created the issue #1473.

I've tried modifying the code to submit a PR, but adding assertTrue(false) in the single unit test and running mvn test or mvn install doesn't make the build fail as it should, so I must be doing something wrong.
And running mvn install from the root project directory makes the build completely stall at Running io.quarkus.maven.it.DevMojoIT. So, without being able to make sure the test is really executed and passes after my changes, I don't want to submit a PR.

[vorburger]

I've tried modifying the code to submit a PR, but adding assertTrue(false) in the single unit test

Which unit test?

and running mvn test or mvn install doesn't make the build fail as it should, so I must be doing something wrong.

Have you seen #1405 ? I'm not clear if you tried before or after and with that?

And running mvn install from the root project directory makes the build completely stall at Running io.quarkus.maven.it.DevMojoIT.

So that's a Maven not Gradle related IT, and should have nothing to do with that, in theory.

So, without being able to make sure the test is really executed and passes after my changes, I don't want to submit a PR.

You can raise a PR with something like "[WIP] [DRAFT]" in the Title even if it's not completely final and ready to be merged, just so that others can look at and help with it - looking at concrete code proposals, even if not perfect, is often more productive than talking about code in PRs with words.

[vorburger]

You can raise a PR with something like "[WIP] [DRAFT]" in the Title

or, even better I guess, use the brand new https://github.blog/2019-02-14-introducing-draft-pull-requests/

[jnizet]

@vorburger Sorry for the confusion.

I'm talking about this test.
It's part of a Maven module which has a pom which seems to run gradle. I went to that directory and executed mvn install and mvn test. They both succeed even if I intentionally add assertTrue(false) in the QuarkusPluginTest unit test to make it fail.

I then tried building the whole project by running mvn install from the root directory as instructed in the contributing guide. The build stalls forever.

Given that renaming the tasks should just take a few minutes to someone able to build the project, and that it took me two hours already to just try building the project by following the instructions without success, I just decided to abandon.

[emmanuelbernard]

Hey @jnizet, please join Zulip, we definitely want you to be able to build Quarkus :) And at last we could improve the doc in that area

[vorburger]

succeed even if I intentionally add assertTrue(false) in the QuarkusPluginTest unit test to make it fail

Huh, well spotted - #1489 fixes that! 😈

[jnizet]

Thanks @vorburger. I just found out the issue 3 minutes ago :-)