Jakarta Mail and Jakarta Activation

530 views
Skip to first unread message

Basil Crow

unread,
Jan 2, 2022, 4:36:20 PM1/2/22
to jenkin...@googlegroups.com
Core currently ships JavaMail and JavaBeans Activation Framework
(JAF), a dependency of JavaMail. Core only consumes this functionality
in a tiny validation routine
(JenkinsLocationConfiguration#doCheckAdminAddress), but many plugins
consume this functionality via core. Both libraries are subject to
Jakarta package renaming changes. This raises questions about our
migration plan.

It seems to me that the best course of action is to drop this
dependency from core. Suppose we release four new plugins:

- javax-activation-api, bundling javax.activation
- javax-mail-api, bundling javax.mail and depending on javax-activation-api
- jakarta-activation-api, bundling jakarta.activation
- jakarta-mail-api, bundling jakarta.mail and depending on
jakarta-activation-api

Then we could detach the JavaMail and JAF JARs from core into
javax-mail-api and javax-activation-api. Existing plugins would
continue to work. Upon upgrading their core baseline, plugins could
retain their use of Java EE (by adding an explicit dependency on
javax-mail-api and/or javax-activation-api) or migrate to Jakarta EE
(by adding an explicit dependency on jakarta-mail-api and/or
jakarta-activation-api) as desired. The pesky validation routine in
JenkinsLocationConfiguration#doCheckAdminAddress could be reworked to
use UberClassLoader to invoke that same functionality from
javax-mail-api and/or jakarta-mail-api (if installed), or the
validation could be dropped entirely.

Can anyone see a flaw with this plan?

Jesse Glick

unread,
Jan 3, 2022, 3:41:10 PM1/3/22
to jenkin...@googlegroups.com
On Sun, Jan 2, 2022 at 4:36 PM Basil Crow <m...@basilcrow.com> wrote:
The pesky validation routine in
JenkinsLocationConfiguration#doCheckAdminAddress could be reworked to
use UberClassLoader to invoke that same functionality from
javax-mail-api and/or jakarta-mail-api (if installed), or the
validation could be dropped entirely.

Or just replaced with a simple regexp like /.+@.+/ to check that something that might be an email address was entered.

The plan sounds OK to me. Are there enough plugins actually using one of these javax.* packages that it would be impractical to just switch them all to Jakarta now?

Basil Crow

unread,
Jan 3, 2022, 3:58:27 PM1/3/22
to jenkin...@googlegroups.com
On Mon, Jan 3, 2022 at 12:41 PM 'Jesse Glick' via Jenkins Developers
<jenkin...@googlegroups.com> wrote:
>
> Are there enough plugins actually using one of these javax.* packages that it would be impractical to just switch them all to Jakarta now?

Yeah, there are 41 such plugins, the most notable of which are Mailer,
Email Extension, and Pipeline: Basic Steps.

Basil Crow

unread,
Jan 4, 2022, 12:40:36 PM1/4/22
to jenkin...@googlegroups.com
On Mon, Jan 3, 2022 at 12:57 PM Basil Crow <m...@basilcrow.com> wrote:
>
> Yeah, there are 41 such plugins, the most notable of which are Mailer,
> Email Extension, and Pipeline: Basic Steps.

I maintain Email Extension, so I looked into migrating it to Jakarta
Mail. Unfortunately the test suite depends on mock-javamail, which is
an old Kohsuke project that (like args4j and a number of other odds
and ends) does not seem to be as actively maintained as it once was. I
think the needs of the Jenkins project would be best served if we had
the ability to merge and release PRs for those odds and ends, but this
isn't simple to arrange because they generally live in Kohsuke's own
GitHub organization rather than ours. Needless to say, I am very
grateful for Kohsuke's contributions and I do not mean to imply
anything negative about the current state of affairs, but as he has
stepped away from Jenkins it is becoming a bit of a pain point. I
would love to help get these odds and ends back in shape in whatever
way Kohsuke and the Jenkins project consider appropriate, regardless
of which GitHub organization the repositories belong to.

Tim Jacomb

unread,
Jan 4, 2022, 1:01:47 PM1/4/22
to jenkin...@googlegroups.com
It’s no problem to get those transferred in, we did a few last year

Generally just raise an issue in the repo about transferring to jenkinsci feel free to ping me on them 

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjppXutFmNOeAEuFNbtVmFAC0Rkyh--Wkjo5R%3DzhLu07wg%40mail.gmail.com.

Jesse Glick

unread,
Jan 4, 2022, 2:20:58 PM1/4/22
to jenkin...@googlegroups.com
On Tue, Jan 4, 2022 at 12:40 PM Basil Crow <m...@basilcrow.com> wrote:
I think the needs of the Jenkins project would be best served if we had
the ability to merge and release PRs for those odds and ends, but this
isn't simple to arrange because they generally live in Kohsuke's own
GitHub organization rather than ours.

Reply all
Reply to author
Forward
0 new messages