Bill,
Bill Shannon wrote:
> 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.
>
Has anything changed recently? When we had made the necessary changes in
your private JavaMail project to add OSGi metadata, you had marked this
package as private. The packages that you wanted to be exported from
mail.jar were:
javax.mail.*; version=${mail.spec.version},
com.sun.mail.imap,
com.sun.mail.pop3,
com.sun.mail.smtp
> 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.
>
We are eagerly waiting for this switch to happen.
Thanks,
Sahoo