David Blevins wrote:
On Feb 8, 2006, at 4:26 PM, Rick McGuire wrote:
David Blevins wrote:
On Feb 8, 2006, at 2:35 PM, Rick McGuire wrote:
David Blevins wrote:
At first blush it looks like there are just three util classes
that make the javamail-transport module dependent on our specific
javamail implementation.
Do you think it makes much sense to try and keep them separate? Or
are they too coupled already to be worth it?
It's kind of a PITA to have to have a tight (i.e. snapshot)
dependency on a spec project. But obviously javamail is a mess and
it may just be too hard.
I'm starting to think it was a mistake to have javamail-transport be
a separate jar file from the spec code. In the Sun case, all of the
code is in a single jar, so you only need the javamail jar and the
activation jar to use it. Because of our current split, we require 3
jars. It might make sense to move the transport/store code into the
spec jar since they are so tightly coupled.
If they are fundamentally one unit and completely tied together, it
may make more sense to put them together. Course, I may not
understand the implications of what I say :)
The javamail-transport module got created, I believe, from a combination
and history. The SMTP transport code was not originally included with
the spec code, but resided in the sandbox for a while. When it got
promoted out of the sandbox, it was placed into it's own module in the
Geronimo tree rather than rolled into the spec code. Probably ok if
this is only used bundled with Geronimo, but makes less sense if we
believe this might be used standalone.
I guess if the javamail-transport module is going to be where all the
change occurs, then having it outside specs kind of handy -- provided
the javamail module itself calms down and doesn't keep changing right
along with it.
I believe it's going to be a while before the spec module calms down.
I'm finding more and more unimplemented/incompletely implemented
features all the time.
Could go a couple ways.
-David
