Provide an uberjar with mail impl relocated

[rmannibucau]

Hi,

when using another impl than javax.mail, greenmail fails because it finds the wrong stores.

Is it possible to deliver an uber jar relocating config+classes in 1.6 to ensure it becomes compatible?

Thanks,
Romain

[marcelmay]

Hi @rmannibucau !

Which other impl?

[rmannibucau]

I use geronimo-javamail.

[marcelmay]

GreenMail will go for JavaMail 1.6.x with next GreenMail 1.6 release.

This might be a problem, as geronimo-java seems to implement only up to JavaMail 1.5.x releases, and also does not show much of recent activity.... ?

[rmannibucau]

@marcelmay there are two points:

1. is greenmail an option for alternative impl?
2. several users want to test with their actual impl and they dont always choose it (if you have an app server typically)

It also does not cost much to greenmail to not depend hard on an impl thanks shadowing and would make it a generic product.
Same applies for new javamail API like setAddress(String) (vs setAddress(InternetAddress)) which used in utilities. It does not bring anything to end users since it is internal details but can prevent the usage/upgrade in several environments. So long story short, this request is to make greenmail usage of javax.mail stable when possible and encapsulated at least.

Side note/bonus: if a jakarta API arrives it will also support it transparently ;).

[rmannibucau]

FYI https://issues.apache.org/jira/browse/TOMEE-2606 and geronimo-javamail 1.5 will likely be released in the coming days

[marcelmay]

@rmannibucau , sorry for the delay.

To summarize (please correct me):

Make GreenMail independent of SUN/Oracle specific classes, so that GreenMail only uses JavaMail-API and therefore can use different JavaMail-API implementations.

Examples:

• TomEE-provided JavaMail (must be of same minor version)
• Apache Geronimo

I'd prefer this approach, instead of re-packing/-locating JavaMail (which is also a licensing issue, with the internal vendor extension of com.sun.* alias Oracle packages).

[rmannibucau]

@marcelmay sounds perfect to me, just thought relocation was a 15mn work vs supporting other stores but I like your proposal better

[rmannibucau]

Up, any news on this one? I'm hitting this again and with this jakarta renaming thing it gets more and more complicated to manage the dependencies overrides/exclusions so would be awesome to have greenmail + greenmail- deps.

[marcelmay]

@rmannibucau , I'll try to look into this over xmas vacation. I am curious about separating out the mail implementation.