[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Classpathx-discuss] Help needed gnu classpathx mail
From: |
Nic Ferrier |
Subject: |
Re: [Classpathx-discuss] Help needed gnu classpathx mail |
Date: |
07 Jan 2004 21:39:17 +0000 |
Chris Burdess <address@hidden> 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