On 08/15/2012 09:31 AM, Slide wrote:
I was thinking of making core have an interface that would be implemented by a plugin
Probably not helpful, since then core still needs to provide _some_ implementation. The actual mail task can be moved wholesale to a plugin, but for historical reasons some bits of API used by other code is mixed in with that. Really that was just sloppiness made possible by the fact that too many things started out in core rather than plugins.
Seems like most of the usages are of Mailer.DescriptorImpl, i.e. of global domain configuration not necessarily related to actually sending mail, which can just stay where it is for compatibility of both the Java API and of XStream persistence, but retaining GUI configuration only for those properties actually used by core: e.g. defaultSuffix, hudsonUrl, and adminAddress; but not properties used only by the mailer task: smtpAuthUsername, etc. The plugin would need to define its own UI config section for these properties.
MailCommand should be moved to the plugin, as should tests like MailerTest. MavenMailer might be tricky; maven-plugin reuses the standard config page. Could be copied I suppose. Not sure about use of Mailer.UserProperty from HudsonPrivateSecurityRealm.
