Open gsmet opened 2 years ago
/cc @cescoffier
We only it for tests so we will update it when subethasmtp moves to it.
@gsmet what is the plan here actually? Are you planning to have an Angus Mail extension by any chance? I am looking for a place to consolidate the Angus mail code we have in Camel Quarkus and CXF.
After our latest meeting, the idea is to have a quarkus-angus
extension in Quarkiverse
@gastaldi would you please create a qverse repo for angus mail?
I'm not sure if having quarkus-angus
makes sense. They live in different projects even if they share the same prefix. So probably better to create a quarkus-angus-mail
extension.
@gastaldi I see that the repo exists, but it is empty. Your magic provisioning templates are still to be run?
You can use quarkus create extension angus-mail
to create the skeleton
Please don't close my issue, it has nothing to do with the availability of the extension :).
You can use quarkus create extension angus-mail to create the skeleton
I think you need to specify the groupId to create a Quarkiverse one?
@gsmet no need to. The default is already io.quarkiverse.<PROJECT.NAME>
Hm, it generates the groupId as <groupId>io.quarkiverse.angus-mail</groupId>
, but I guess it should be io.quarkiverse.angus.mail
? WDYT
It should either be angusmail
or angus.mail
if we want to stay consistent with the rest of the extensions.
The dot would make sense if we expect several angus
extensions and that might be the case but in general we decided to go with io.quarkiverse.githubapp:quarkus-github-app
for instance. Not all the extensions are consistent but most follow this pattern.
issue for angus mail extension is here: https://github.com/quarkusio/quarkus/issues/31285
https://github.com/quarkiverse/quarkus-angus-mail repo is empty.
What are the plans with Angus / Jakarta Mail 2.1?
It's still in @ppalaga's TODO list. See https://quarkusio.zulipchat.com/#narrow/stream/187038-dev/topic/Quarkiverse.20Angus.20Mail
What are the plans with angus?
@ppalaga Any progress?
For now, we are using the old implementation targeting EE 9.
EE 10 and Jakarta Mail 2.1 introduced a new implementation called Angus.
Note that there are 2 different artifacts:
We need to choose what's more practical for us but in general I would recommend to use the implementation that does NOT contain the API because otherwise we would have to add exclusions for all artifacts depending on the API.