Create a DevService for the mailer extension

[iocanel]

Description

It would be great if I could experiment with the mail sender without spamming emails through an actual provider. A DevService could possibly help.

Other DevServices might be able to benefit from this too. Out of my mind I can think of Keycloak that could use something like it.

Implementation ideas

No response

[geoand]

I think this has been proposed before, but I can't seem to find it

[melloware]

This would be cool it could start up MailHog which has a great web UI for inspecting emails sent during DEV mode.

https://github.com/mailhog/MailHog

  mailhog:
    image: mailhog/mailhog:latest
    container_name: mail
    logging:
      driver: 'none' # disable saving logs
    volumes:
      - 'mail_data:/var/opt/mail'
    ports:
      - '1025:1025' # smtp server
      - '8025:8025' # web ui

I guess it could technically use GreenMail as well which is a pure java based Mail Server.

https://greenmail-mail-test.github.io/greenmail/

[GregJohnStewart]

@gsmet I made a very similar proposal before, but similarly cannot find it for some reason.... It was before Quarkus3 and the dev ui rewrite, and was suggested that it wait for the dev ui rewrite.

I circled back today to poke that issue again but, again, seems lost?

Having a mail server instance sounds like a good idea for implementing, though in my initial issue I was thinking just displaying the emails sent by the server, as you don't need full e-mail service in devmode

[GregJohnStewart]

Nevermind, found it: #28700

[melloware]

But @GregJohnStewart wouldn't it have to implement the mail server to respect the full RFC of what people are doing in their code?

[GregJohnStewart]

I'd agree with you there, at least from an integration-type test standpoint.

The current recommended way to write tests is to use the mocks, my suggestion in the other ticket was to extend the mocking to the dev ui essentially.

I think your take has merit though for sure. I definitely see a use case, and would like to see it for integration type testing, or at least an easy option for it.

[GregJohnStewart]

One could easily write their own test resource manager that would leverage testcontainers too, there is the generic testcontainer class. Not as nice as a full devservice, but to get that full integration test it checks the box

[melloware]

Yep I have not looked too far into it but most of the time when I develop locally I startup MailHog in Docker and I just set my quarkus mail server to point to localhost so it's captured by MailHog and I can inspect what is coming out of my real server to a real SMTP server.

# ------------------------------------------------------------------
# E-MAIL
# ------------------------------------------------------------------
quarkus.mailer.host=localhost
quarkus.mailer.port=1025
quarkus.mailer.from=${quarkus.application.name}@melloware.com
quarkus.mailer.mock=false

[GregJohnStewart]

https://github.com/dasniko/testcontainers-mailhog

Check that out, looks like a testcontainer exists for mailhog.

[melloware]

OK team! I decided to use MailPit instead of MailHog for a few reasons:

1. MailHog looks like it is dormant: THIS PROJECT IS DEAD! mailhog/MailHog#442 (comment)
2. Mailpit is based on MailHog but is a complete rewrite in Go using Vue as UI
3. has the same features and more than MailHog
4. Actively Maintained.

DevUI:

And if you click on the Mailpit UI you can see the UI right in the Dev UI! So you can browse all your captured emails.

[geoand]

Very nice!

[melloware]

cc @gastaldi can we tag this ticket as "extension" request?

[gastaldi]

Done. That's awesome! I wonder if we should make it a DevService in the mailer extension or a separate Quarkiverse extension. Both seems to work but the former seems more intuitive, WDYT @geoand @gsmet @cescoffier ?

[melloware]

@gastaldi we talked about having me do this as an extension so we can burn it in and test it and then move it once its all solid and everyone likes it into the mailer Dev Service?

I designed it right now like it is the Mailer Dev Service and it actually uses the quarkus.mailer.port to determine how to map the Mailpit listening port!

But I am OK with whatever you guys want to do.

My next task is figuring out how we can plug in @Test so you can simply ask for your messages in testing without having to know the Mailpit REST API.

[gastaldi]

I created quarkiverse/quarkiverse-devops#185 and made @melloware the extension lead. Let me know if that works for you

[melloware]

OK by me 👍🏻

[melloware]

Version 0.0.1 is in Maven Central if anyone is brave enough to test it.

https://github.com/quarkiverse/quarkus-mailpit