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? -- 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-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjqwK0y_Gn%3DD-Ay%2BGD%2Bx-aUc2Fj-fB%2BtLYjNAbVWH5DegA%40mail.gmail.com.
