|
From: | Chris B. |
Subject: | Re: [Classpathx-discuss] Help needed gnu classpathx mail |
Date: | Thu, 08 Jan 2004 17:18:26 +1100 |
User-agent: | Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 |
Admittedly I havn't looked at this problem close enough to see exactly what's going on here, but I think I roughly understand the situation...
But it seems to me the problem could probably be solved pretty easily by dropping the "implements StatusSource" from MboxStore, and creating a new class "MboxStoreWithStatusSource" that implements the interface StatusSource and extends MboxStore. Leave the actual implementation inside MboxStore. MboxStoreWithStatusSource would be an empty class.
That way people can use their config file to use either one. If they use the plain MboxStore, I don't think Java will try and pull in StatusSource and everything will be groovy.
Chris Burdess wrote:
Chris wrote:However I noticed that the classpathx implementation of mbox requires the gnumail.jar gnu javamail implementation.if so it may be a packaging error. which classes in mbox.jar depend on whichclasses in gnumail.jar not in sun's mail.jar?gnu/mail/treeutil/StatusSourceok. this is a bit of a pain, since even if nobody uses the treeutil (progress listener) classes, there will still be other utility classes that will be used by provider implementations. clearly there are 2 ways to go: modularise everything even further, or just live with it (in this instance having gnumail.jar on the classpath as well).if we were to just live with it, we might as well reduce the complexity of having a separate jar file for each provider, and just use configure options to determine which providers should be included in gnumail.jar. this makes deployment and provider management considerably easier. does anyone have any strong feelings on whether to do this or aggressively modularise (almost) every package into its own jar file?
[Prev in Thread] | Current Thread | [Next in Thread] |