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 17:25:40 GMT

On Feb 9, 2006, at 9:43 AM, Bruce Snyder wrote:

> On 2/9/06, Kevan Miller <> wrote:
>> 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.
> Thanks for doing this, Kevan, but shouldn't we put the entire specs
> project in there instead of just a single module? I'm not sure if
> other modules are going to be moving as much as JavaMail.
> Also, I'm not sure if GBuild will know to build the spec using Maven 2
> or not - do you know? If not, as David Blevins advised me, we may need
> to just create a small shell script that calls mvn clean install,
> check it into the specs SVN base dir and then set up the JavaMail
> build as a shell script that calls the script.

Hi Bruce,
I was thinking of adding the entire specs project also. However,  
David Blevins advised against it and convinced me that it's not a  
wise thing to do. Let's see how I can do... ;-)

The basic issue is that the specs project is composed of SNAPSHOT and  
non-SNAPSHOT modules. If we add the entire specs project to GBuild,  
we'll start publishing both types of modules (or it will be hard not  
to do so...). This seems unwise. Plus, if we update a spec without  
updating the spec version in pom.xml, we might start publishing non- 
SNAPSHOT modules with new content. Doubly unwise.

I think it's best that we only add individual SNAPSHOT spec modules  
to GBuild. When these modules are released, we'll need to remove them  
from GBuild. This process could use a bit more rigor, but shouldn't  
be too hard to manage...


FYI, after 1 misstep, javamail is building on GBuild. Now, just need  
to add specs to the rsync that's moving things to apache...


View raw message