Sahoo wrote:
> Two issues:
> 1. I don't think com.sun.mail.util package is intended to be exported.
> Let's wait for Bill Shannon, who is the owner of JavaMail, to confirm
> this. At the moment, can you mark that import as optional
> (resolution:=optional)?
It needs to be exported, for two reasons...
Like the sun.* classes in the JDK, for better or for worse, some customers
use some classes in that package directly.
The JavaMail API implementation *and* the JavaMail protocol providers use
classes in that package. When everything is packaged in one mail.jar,
that's not an issue. But when the API classes are packaged in an API
jar file, and the protocol providers are packaged separately, that would
be an issue.
> 2. Today we are repackaging JavaMail artifact in v3 workspace to add
> OSGi metadata. We will eventually just use the OSGied artifact that
> JavaMail project produces. So, the fix (if any) has to go in the source
> project as well.
Yup.
I've told many of you this before, but...
The JavaMail module source code is now in a Mercurial repository.
As soon as we have public hosting support for Mercurial, I'll expose
it outside. At that point I'd like GlassFish to switch to importing
that version, rather than building it as a part of the GlassFish build.
I've had a few people review the new JavaMail build process, and Sahoo
has helped with the OSGi part. I'd be happy to have others review it,
and when GlassFish switches to this new version I'll certainly need
help to make sure I'm doing the right thing with Maven and OSGi.