Clarify the library depends on classpath ordering

[gaeljw]

Describe your use-case which is not covered by existing documentation.

I started using the library for tests in some projects but I encountered an issue in IntelliJ where tests were still using the real email library (see initial bug report at IntelliJ team).

After troubleshooting by Jetbrains team, it seems that the behaviour is highly dependent on classpath ordering: depending on which order libs are loaded, you might be using the mock-javamail or the real email stack.

That sounds kinda risky and IMHO should be at least explicitly stated in the documentation (I guess the README is a good start).

Reference any relevant documentation, other materials or issues/pull requests that can be used for inspiration.

No response

[basil]

Per the JavaMail API docs:

Checks mail.<protocol>.class property first and if it exists, returns the Provider associated with this implementation. If it doesn't exist, returns the Provider that appeared first in the configuration files.

So I think you should be able to define the Java system properties

• mail.smtp.class set to org.jvnet.mock_javamail.MockTransport
• mail.pop3.class set to org.jvnet.mock_javamail.MockStore
• mail.imap.class set to org.jvnet.mock_javamail.MockStore

in your test runner (see this page for a Maven example) to eliminate the classpath order fragility. Play around with this in the debugger; if you get it to work, we would love a pull request updating the documentation!

[gaeljw]

Ah right, this is what I was looking for.

I'll provide a PR to make this clear in the documentation.