mind you; if we start requiring build to happen first it will force quarkus run to be slow as it first has to check.

I believe that's why it is assumed to not do the check.

Hi @ia3andy
I would like to contribute to this issue.

Implementation requirement is to add --clean (boolean) option to quarkus run to force build process, right?

comment.

@pn03 sorry, I missed your message, what do you think of this issue instead #40471

It would be a very good feature

Hey @ia3andy , sure I'll take a look at that issue #40471

If this is not picked, I'd like to do this one.

@baranowb any update on this?

@ia3andy yep, a bit.
"it should build before run" - its tad problematic, since CLI only delegates and 'run' does(?) not support build options - it has no way of detecting custom build output, though it might not be that bad, its just part I did not look into. Unless its supposed to be simplistic build, however this could lead to a problem if user does build.
"build with --clean" - SImplest way here would be to switch prepare action from 'resources:resources' to 'install', better approach would be to refactor build command to be more of an utility. Though I got baffled why its defaults to 'resource:resource'
This week I will have bit more time to get hands on.
EDIT: different build target/file name, might be just misinterpretation on my part.

Just to explain clean = false. In current impl there is sort of a bug/nonsense. Run command defaults to "resource:resource" and than "quarkus:run" in two distinct backend invocations.
Not sure why prep defaults to resource:resource, but thats minor thing. Major bug here is that in current setup, it means two triggers:
clean resources:resources
clean quarkus:run
This essentially cleans twice. So whatever resources:resources is supposed to do is null.