Re: Help needed gnu classpathx mail

Chris Burdess <[email protected]> writes:

> 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?

These days I take the view that the fewer the files the better. I
think that 2 files: providers.jar and api.jar (though I don't care
about the names) would be a good idea.


Nic