geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <l...@toolazydogs.com>
Subject Re: Reorganizing javamai (revisited)
Date Thu, 08 Jun 2006 18:32:34 GMT
Rick McGuire wrote:
> Alan D. Cabrera wrote:
>> Rick McGuire wrote:
>>> I brought this up a couple of months ago, and I believe we reached a 
>>> consensus on what should be done but the work was put off until 
>>> after 1.1 shipped.  Since then, I have a new factor to introduce 
>>> into this discussion, so I want to make sure we've got good 
>>> agreement on what needs to be done.  To refresh, I proposed that the 
>>> javamail code needed to be reorganized so that the 
>>> javamail-transport jar (which is currently part of the Geronimo 
>>> build) is separated from Geronimo and available with the 
>>> geronimo-javamail-spec jar.  The consensus seemed to lean toward the 
>>> following approach:
>>>
>>> 1)  keep the javamail spec jar/build the way it is.
>>> 2)  create a separate repository for the javamail-transport module 
>>> and continue to build a javamail-transport jar file.
>>> 3)  as part of the javamail-transport build, also build an uber-jar 
>>> that combines the spec jar and the transport jar.
>>>
>>> I think this will work ok, but I think a slight modification is 
>>> required.  Over the last couple of days, I created a javamail 1.4 
>>> version of the spec jar, with the intent that this version could be 
>>> made an optional plugin.  However, the javamail 1.3 spec jar is 
>>> going to need to be kept around, since it's required to pass the 
>>> tck.  The javamail 1.4 jar can't be used, since it will fail the tck 
>>> signature tests.  It looks like the best approach here would be to 
>>> rename the existing javamail spec module to 
>>> "geronimo-javamail-spec-1.3" and introduce a new 
>>> "geronimo-javamail-spec-1.4" module to create the other version.
>>>
>>> In lock-step with that, there are some dependencies between the 
>>> transport jar file and the corresponding spec version.  So the 
>>> transport repository will also need modules to build the matching 
>>> provider jar.
>>> So, given all that, here's what I think should be done:
>>>
>>> 1)  rename the geronimo-spec-javamail module to 
>>> geronimo-spec-javamail-1.3.  This already builds a 
>>> geronimo-javamail_1.3.1_spec-${geronimoSpecsJavamailVersion} jar 
>>> file, which is what we want.
>>>
>>> 2) create a new geronimo-spec-javamail-1.4 module, which will build 
>>> a geronimo-javamail_1.4_spec-${geronimoSpecsJavamailVersion} jar file.
>>>
>>> 3) create a new javamail-provider repository (note the name 
>>> change...javamail-transport might have made sense when it only 
>>> contained smtp, but now that it also has Store providers, it doesn't 
>>> really fit).  This will have two modules for the 1.3 and 1.4 
>>> versions of the providers, and will build  
>>> geronimo-javamail_1.3.1_provider-${geronimoProviderJavamailVersion} 
>>> and 
>>> geronimo-javamail_1.4_provider-${geronimoProviderJavamailVersion} 
>>> jar files.
>>>
>>> 4)  Additionally, the javamail-provider build will create two 
>>> uber-jars containing the specs and providers combined:  
>>> geronimo-javamail_1.3.1_mail-${geronimoProviderJavamailVersion} and 
>>> geronimo-javamail_1.4_mail-${geronimoProviderJavamailVersion}
>>>
>>> Rick
>>>
>> +1 Sounds good!
> So, in light of the other conversation going on with the 1.3.1 spec 
> jar version, can I assume the version number for the 1.4 spec jar 
> should be 1.2-SNAPSHOT also, and the provider jars (and the uber 
> jars), because they're in a new repo should start out at 1.0-SNAPSHOT?
I'm not sure why we would tie the spec jars and the provider jar 
versions together.  I just reread your proposal w/ a more careful 
attention to the version macros.  We might want to restate the proposal:

1)  rename the geronimo-spec-javamail module to 
geronimo-spec-javamail-1.3.  This already builds a 
geronimo-javamail_1.3.1_spec-${geronimoSpecsJavamail13Version} jar file, 
which is what we want.

2) create a new geronimo-spec-javamail-1.4 module, which will build a 
geronimo-javamail_1.4_spec-${geronimoSpecsJavamail14Version} jar file.

3) create a new javamail-provider repository (note the name 
change...javamail-transport might have made sense when it only contained 
smtp, but now that it also has Store providers, it doesn't really fit).  
This will have two modules for the 1.3 and 1.4 versions of the 
providers, and will build  
geronimo-javamail_1.3.1_provider-${geronimoProviderJavamail13Version} 
and geronimo-javamail_1.4_provider-${geronimoProviderJavamail14Version} 
jar files.

4)  Additionally, the javamail-provider build will create two uber-jars 
containing the specs and providers combined:  
geronimo-javamail_1.3.1_mail-${geronimoProviderJavamail13Version} and 
geronimo-javamail_1.4_mail-${geronimoProviderJavamail14Version}

geronimoSpecsJavamail13Version=1.2-SNAPSHOT
geronimoSpecsJavamail14Version=1.0-SNAPSHOT
geronimoProviderJavamail13Version=1.0-SNAPSHOT
geronimoProviderJavamail14Version=1.0-SNAPSHOT


Thoughts?


Regards,
Alan


Mime
View raw message