To conclude our milestone C for the time being (we could do so much more with the bootstrap scripts and refactor them into smaller, reusable pieces), an option to configure your mail MTA with Dataverse directly needs to be implemented. Here we go: https://github.com/IQSS/dataverse/pull/9939
Wow, look at create-javamail-resource going away!
I just put it on tomorrow's agenda: https://ct.gdcc.io
Thanks!
Philip Durbin said:
I just put it on tomorrow's agenda: https://ct.gdcc.io
Please note: I will not attend tomorrow - schedule conflict, need to do kids logistics.
Oliver Bertuch said:
To conclude our milestone C ... https://github.com/IQSS/dataverse/pull/9939
Ok, good. This is what I said in the meeting today. That we can declare milestone C done when we merge this. (@Ellen K had asked what else we need for milestone C.)
Hey that's what I thought! :smile_cat:
Awesome. Can't wait to close that milestone.
@Philip Durbin @Don Sizemore would you agree that someone configuring the system mail via MPCONFIG wants it to take precedence over the database setting (which is going to be deprecated)?
Yep.
Oliver Bertuch I... think so? (do jvm-options still take precedence?)
The "from" of the create-javamail-resource will be gone and no longer work once people migrate their settings. I'm adding backward compatibility to make the transition smoother
I want to add a startup check to look into the session and see if a "from" is present. If so and different from the setting, will fail deployment.
Gosh the MailServiceBean is really something. :see_no_evil:
@Don Sizemore @Philip Durbin it looks like until now, the system email address was kind of optional. If you don't set it, fine, just don't expect any mails. Is that how it's supposed to be? Because then the future startup check will only print warnings, but not fail the deployment.
(Example where things are mentioned and/or programmed as being optional are here and here - also it is not consistent... The sendMail() used by feedback feature does not skip when it's not there... (might result in interesting errors))
That second "here" is the one I'm familiar with. In a classic dev environment, :SystemEmail is not set and a developer can relax, knowing that no emails are being sent.
Oliver Bertuch @Philip Durbin I've honestly never installed Dataverse _without_ those two settings in place (and the service available) - I've always assumed they were required. I've seen Dataverse block on certain actions when the SMTP relay wasn't available, for instance.
Well, my money is on most of the core devs not having :SystemEmail set.
It sounds like that this would be a setting that is kind of required in a production context, but not in a dev context.
But fine. There will be a warning in the logs. The current mail code does only do "fine" logging when skipping, so a one time warning when deploying should be more than what people get now...
(So a prod env can see and react, a dev can ignore)
Does that sound like a good compromise?
Actually this is becoming kind of a more general dev topic, moving it to that stream...
Sure. Sounds fine. I mean, until only a few months ago when we got Docker and MailDev, I was one of the core developers who had :SystemEmail not set and the assumption that I wasn't sending out email inadvertently. So until we get most devs moved over to Docker it probably makes sense to support the old behavior they expect.
Of course. Always stay backward compatible and try not to create breaking changes in behaviour when not doing a major release
Principle of least surprise :grinning:
PR #9939 merged! Thanks, Oliver!
Finally!
Took us long enough
Oliver Bertuch has marked this topic as resolved.
Last updated: Nov 01 2025 at 14:11 UTC