[Classpathx-javamail] [Fwd: [JPackage-discuss] classpathx-mail: inetlib dependencies in mailapi.jar]

[Fernando Nasser]

Any chance to implement this for the next release?

Best regards,
Fernando


From a thread on another list:

-------- Original Message --------


mailapi.jar from classpathx-mail depends on the following
inetlib/org.jpackage classes which are currently in its providers.jar:

org.jpackage.mail.inet.util.Logger
org.jpackage.mail.inet.util.LineInputStream

Additionally, the above Logger depends on
org.jpackage.mail.inet.util.StdErrLogger.

Since this is an API jar, IMHO no other dependencies or classpath
tweaking should be necessary, so these three classes should probably be
copied/moved from providers.jar to mailapi.jar.

Some might say it's an upstream bug to have API classes depend on a
particular implementation, and even worse, something that isn't even
included in the package (upstream mail<->inetlib)...

Thoughts?  Copy or move the three classes?  Or leave as is and declare
that mailapi.jar can never be used alone, but one must do a
"build-classpath javamail" instead?

_______________________________________________


>> mailapi.jar from classpathx-mail depends on the following
>> inetlib/org.jpackage classes which are currently in its providers.jar:
>>
>> org.jpackage.mail.inet.util.Logger
>> org.jpackage.mail.inet.util.LineInputStream
>>
>> Additionally, the above Logger depends on
>> org.jpackage.mail.inet.util.StdErrLogger.
>>
>> Since this is an API jar, IMHO no other dependencies or classpath
>> tweaking should be necessary, so these three classes should probably be
>> copied/moved from providers.jar to mailapi.jar.
>>
>> Some might say it's an upstream bug to have API classes depend on a
>> particular implementation, and even worse, something that isn't even
>> included in the package (upstream mail<->inetlib)...
>>


Yes, this looks like an upstream bug.  I think gnu.mail.util should have
its own Logger, StderrLogger and LineInputStream implementations.  All
three classes are quite simple so it should be easy to keep them in sync
with their inetlib counterparts.


>> Thoughts?  Copy or move the three classes?  Or leave as is and declare
>> that mailapi.jar can never be used alone, but one must do a
>> "build-classpath javamail" instead?
>>


Until this is fixed upstream, I think we should either copy the classes
into mailapi.jar or write a patch that introduces gnu.mail.util
implementations.