geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <>
Subject Re: Compilation errors in module javamail-transport
Date Thu, 09 Feb 2006 13:34:34 GMT

On Feb 9, 2006, at 5:06 AM, Rick McGuire wrote:

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

Hi Rick,
I started to look at adding the javamail spec to GBuild, yesterday,  
before seeing this thread. Two benefits -- 1) forced me to look at  
how projects get added to continuum and 2) more importantly, should  
be much easier to make spec changes generally available.

This will still require the occasional online build (or manual  
download) when the javamail spec changes, but is still better than  
the current situation.

Since I'm ready to go, I'll go ahead and commit my changes and get  
things running.


>> Could go a couple ways.
>> -David

View raw message