Well perhaps I wasn't very clear.
What I was suggesting is that jars be used /except/ in the case where
one needed to expose the classes to remote Java clients -- and that even
there one should try to stick to jars. What you don't want to end up
with here is huge jars which mostly contain classes of no interest to
Java clients with a smattering of classes used by Java clients -- and
then force the Java clients to download MB's of stuff they'll never
use. Again, this is not an issue if nothing in your jars is used from
clients. If it is, then you can refactor your large jars into smaller,
more targeted jars. You could also expand /part /of your jar to
codebase for selective inclusion in client jars produced by MakeJar.xml,
though this is certainly not as tidy (and should be rigorously
controlled by a build or deployment script).
--
Jess Holle
