Re: [Classpathx-discuss] Help needed gnu classpathx mail

[Chris B.]

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 which
> > > classes in gnumail.jar not in sun's mail.jar?
> >
> >
> > gnu/mail/treeutil/StatusSource
>
>
> ok. 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?