The case for quarkus:run

Stuart Douglas

unread,

Jun 1, 2021, 5:27:40 AM6/1/21

to Quarkus Development mailing list

Hi everyone,

In the past we have had requests for a run goal, however there has never really been a strong use case as it's simple to run the app directly.

I think that DevServices may actually be that use case, to allow you to run production applications locally without configuring the DB etc. We already have the facilities in place to make this work (we use it for native tests), so it would really just be wiring up pieces that we already have.

We could also make it work like @QuarkusIntegrationTest and launch native and docker images as well (depending on what was built last). This means you could write an app using devservices, build the container image and then run it locally without needing to configure anything.

Thoughts?

Stuart

Max Rydahl Andersen

unread,

Jun 1, 2021, 6:13:29 AM6/1/21

to Stuart Douglas, Quarkus Development mailing list

I always been +1 for a quarkus:run thus +1 in general from me :)

not following what this means - having a build action depend on what was
last built feels wrong.

why would that not be explicitly controlled which thing you ask to run ?

/max

>
> Thoughts?
>
> Stuart
>
> --
> You received this message because you are subscribed to the Google
> Groups "Quarkus Development mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to quarkus-dev...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/quarkus-dev/CAD%2BL2cyXDH7ERF%3Dth-%3DqTaHF3SQeZ43J-gpa-%2BOg6EYmOOSt7g%40mail.gmail.com.

/max
https://xam.dk/about

Georgios Andrianakis

unread,

Jun 1, 2021, 6:19:44 AM6/1/21

to Max Rydahl Andersen, Stuart Douglas, Quarkus Development mailing list

I've been against this, but now with the various pieces we have in place, I think it makes sense.

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/549924C5-F1DA-4408-B2A5-F12D328F7EE8%40redhat.com.

Stuart Douglas

unread,

Jun 1, 2021, 6:30:54 AM6/1/21

to Max Rydahl Andersen, Quarkus Development mailing list

On Tue, 1 Jun 2021 at 20:13, Max Rydahl Andersen <mand...@redhat.com> wrote:

I always been +1 for a quarkus:run thus +1 in general from me :)

For some background I have always been against this because maven is a lot slower to start than Quarkus, so running through maven just seems like a compromise.

I think DevServices support, plus the ability to directly launch container images is enough of a benefit to make it worthwhile.

> Hi everyone,
>
> In the past we have had requests for a run goal, however there has
> never
> really been a strong use case as it's simple to run the app directly.
>
> I think that DevServices may actually be that use case, to allow you
> to run
> production applications locally without configuring the DB etc. We
> already
> have the facilities in place to make this work (we use it for native
> tests), so it would really just be wiring up pieces that we already
> have.
>
> We could also make it work like @QuarkusIntegrationTest and launch
> native
> and docker images as well (depending on what was built last). This
> means
> you could write an app using devservices, build the container image
> and
> then run it locally without needing to configure anything.

not following what this means - having a build action depend on what was
last built feels wrong.

why would that not be explicitly controlled which thing you ask to run ?

Well if I run:

mvn package -Dquarkus.package.type=native

then run:

mvn quarkus:run

It would run the native image I just built, rather than an older jar based app that may have been hanging around. Same with docker, if I built with quarkus.container-image.build=true then ran mvn quarkus:run it would launch that image.

Stuart

Alexey Loubyansky

unread,

Jun 1, 2021, 7:40:21 AM6/1/21

to sdou...@redhat.com, Max Rydahl Andersen, Quarkus Development mailing list

That'd be great, imo.

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAD%2BL2cwbhOC6W1DfNLHg7wDpb%3D6vjObXbHY2Y3wLQk7nL5nwTg%40mail.gmail.com.

Daniel Oh

unread,

Jun 1, 2021, 7:50:21 AM6/1/21

to Stuart Douglas, Quarkus Development mailing list

Sounds like a good idea for devs:)

--

You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAD%2BL2cyXDH7ERF%3Dth-%3DqTaHF3SQeZ43J-gpa-%2BOg6EYmOOSt7g%40mail.gmail.com.

--

Daniel oh

Senior PRINCIPAL TECHNICAL MARKETING MANAGER

agile & devops COMMUNITY OF PRACTICE manager

Red Hat Inc

d...@redhat.com M: +1-(617)717.8732 @danieloh30

Loïc MATHIEU

unread,

Jun 1, 2021, 8:14:42 AM6/1/21

to d...@redhat.com, Stuart Douglas, Quarkus Development mailing list

Seems like a good idea to me, being able to run a "production" build of Quarkus with devservices (so half prod / half dev). This can have some useful usage.

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAPp4%3DaFjWcuZ0WaeDC8cQYXXWZXdpPU8E0RvbXeSy1XWYmERgw%40mail.gmail.com.

Knut Wannheden

unread,

Jun 1, 2021, 8:39:47 AM6/1/21

to loik...@gmail.com, d...@redhat.com, Stuart Douglas, Quarkus Development mailing list

This coupled with "Dev Services 2.0" sounds very interesting and is in fact very similar to an in-house development we have been working on over the last few weeks, which allows us to write integration tests which get executed against a set of Docker containers (communicating over a custom Docker network). Unfortunately we had missed the addition of @QuarkusIntegrationTest and we also wanted support for persistent containers, so we went ahead and rolled our own (building on Testcontainers). But all of this in Quarkus coming together will hopefully allow us to scrap our own development again!

At the moment we place the integration tests in a separate Maven module, because we -- for historical reasons -- want to be able to forbid any dependencies to the Quarkus application. I assume this setup would not be possible with @QuarkusIntegrationTest, Dev Services, and quarkus:run, but I think we could live without that.

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAJLxjVFuasrdT%3D%3DcR9WpUFcW7fLuBB9cqjxAhiF3%2B9mdA5q%2BTw%40mail.gmail.com.

Eduardo Ramirez Ronco

unread,

Jun 1, 2021, 8:48:51 AM6/1/21

to Quarkus Development mailing list

> At the moment we place the integration tests in a separate Maven module, because we -- for historical reasons -- want to be able to forbid any dependencies to the Quarkus application.

If I understand the problem correctly, you could use ArchUnit [1] to create tests that verify that Integration Tests do not access any forbidden code.

[1] https://www.archunit.org/

Eduardo Ramírez ronco

Services Content Architect

Red Hat Global Learning Service

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAFx%3DKgceU10FXa0naLkbaeQdQOif%2B-E63fn%2Bqjki9X%3DNA9d%2BTw%40mail.gmail.com.

Stephane Epardaud

unread,

Jun 1, 2021, 11:24:43 AM6/1/21

to eram...@redhat.com, Quarkus Development mailing list

I'm not sure I understand the use-case, though. It's one thing to be able to start the app and have its data sources spun up like in dev mode, but quite another to have this be useful, as the data sources will be empty.

Is this for prod usage? So for initial deployments where there's no initial legacy data? If so, we need to figure out exactly what happens to the data containers between restarts, and upgrade paths if the users want to migrate to a non-containerised DB.

Is this for some other use-case that I missed?

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAFif860%2Bm2J%2BckgzeLnwUJtJkPJKkMF1S4LAs0_p2f-Wzv3d%3DQ%40mail.gmail.com.

--

Stéphane Épardaud

Max Andersen

unread,

Jun 3, 2021, 5:47:07 AM6/3/21

to eram...@redhat.com, stephane...@gmail.com, Quarkus Development mailing list

It’s so you don’t have to remember nor care which jar you need to pass to Java -jar target/…

/max

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAKU9E9tbwmVMYNbAhO%2B9kUDxHXjs9X%3DUuNgz4EK5iTF%3DTV2o2g%40mail.gmail.com.

Martin Kouba

unread,

Jun 3, 2021, 7:34:50 AM6/3/21

to mand...@redhat.com, eram...@redhat.com, stephane...@gmail.com, Quarkus Development mailing list

On 03. 06. 21 11:46, Max Andersen wrote:
> It’s so you don’t have to remember nor care which jar you need to pass
> to Java -jar target/…

Well, Stuart's proposal is more than that. It includes automagical
startup/init/destroy of DevServices. And I believe that these services
should be always configured explicitly in production mode. Maybe I'm too
paranoid but I smell a misuse that may result in unexpected failures of
all kinds.

In other words, I think that DevServices should be used in some kind of
dev mode and not in anything that is perceived as and used as a
"production facility".

>
> /max
> On 1 Jun 2021, 17:24 +0200, Stephane Epardaud
> <stephane...@gmail.com>, wrote:
>> I'm not sure I understand the use-case, though. It's one thing to be
>> able to start the app and have its data sources spun up like in dev
>> mode, but quite another to have this be useful, as the data sources
>> will be empty.
>>
>> Is this for prod usage? So for initial deployments where there's no
>> initial legacy data? If so, we need to figure out exactly what happens
>> to the data containers between restarts, and upgrade paths if the
>> users want to migrate to a non-containerised DB.
>>
>> Is this for some other use-case that I missed?
>>
>> On Tue, 1 Jun 2021 at 14:48, Eduardo Ramirez Ronco
>> <eram...@redhat.com <mailto:eram...@redhat.com>> wrote:
>>
>> > At the moment we place the integration tests in a separate Maven
>> module, because we -- for historical reasons -- want to be able to
>> forbid any dependencies to the Quarkus application.
>>
>> If I understand the problem correctly, you could use ArchUnit [1]
>> to create tests that verify that Integration Tests do not access
>> any forbidden code.
>>
>>

>> [1] https://www.archunit.org/ <https://www.archunit.org/>

>>
>> Eduardo Ramírez ronco
>>
>> Services Content Architect
>>

>> Red Hat Global Learning Service <https://www.redhat.com>
>>
>> <https://www.redhat.com>

>> <mailto:d...@redhat.com>> a écrit :

>> <mailto:quarkus-dev...@googlegroups.com>.

>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/quarkus-dev/CAD%2BL2cyXDH7ERF%3Dth-%3DqTaHF3SQeZ43J-gpa-%2BOg6EYmOOSt7g%40mail.gmail.com

>> <https://groups.google.com/d/msgid/quarkus-dev/CAD%2BL2cyXDH7ERF%3Dth-%3DqTaHF3SQeZ43J-gpa-%2BOg6EYmOOSt7g%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>>
>>
>>
>> --
>>
>> Daniel oh
>>
>> Senior PRINCIPAL TECHNICAL MARKETING MANAGER
>>
>> agile & devops COMMUNITY OF PRACTICE manager
>>

>> Red Hat Inc <https://www.redhat.com/>
>>
>> d...@redhat.com <mailto:d...@redhat.com> M:
>> +1-(617)717.8732 <tel:+1-617-717-8732> @danieloh30
>> <https://twitter.com/danieloh30>
>>
>> <https://red.ht/sig>

>>
>> --
>> You received this message because you are subscribed
>> to the Google Groups "Quarkus Development mailing
>> list" group.
>> To unsubscribe from this group and stop receiving
>> emails from it, send an email to
>> quarkus-dev...@googlegroups.com

>> <mailto:quarkus-dev...@googlegroups.com>.