Should the geronimo-activation module be rolled into the javamail providers?

[Rick McGuire <ri...@gmail.com>]

I ran into a situation where somebody wishing to use the Geronimo 
javamail implementation also need to extract the geroinimo-activation 
jar file from the server assembly.  This was needed because the various 
activation datahandlers are not included in the mail uber-jar that gets 
built.  I thought this problem had been fixed when the uber jar had been 
created, but there were other classes I didn't really know about until 
this came up. 

So, currently, to using the Sun javamail implementation requires 2 jar 
files, mail.jar and activation .jar.  To use the Geronimo version with 
equivalent function, you need the Geronimo activation spec jar, the 
Geronimo javamail mail jar (which includes the javamail spec and 
javamail providers), AND the geronimo-activation-1.0 jar, which adds in 
data source handlers that that Sun includes in their mail.jar. 

This is a bit awkward, as the spec jars and the provider jars are built 
outside of Geronimo, while the geronimo-activation module is part of the 
server build, even though it is code that's completely independent of 
Geronimo (no dependencies on Geronimo code at all).

Based on Sun's precedent, and what we did earlier with the javamail 
provider code (formerly the geronimo-javamail-transport module), the 
code in the current geronimo-activation module should be moved to the 
javamail provider code tree so that all of these classes get bundled in 
the jar file that makes up the javamail implementation. 

Are there any objects to doing this?

Rick

Re: Should the geronimo-activation module be rolled into the javamail providers?

[Donald Woods <dw...@apache.org>]

Sounds good.  +1

-Donald

Rick McGuire wrote:
> I ran into a situation where somebody wishing to use the Geronimo 
> javamail implementation also need to extract the geroinimo-activation 
> jar file from the server assembly.  This was needed because the various 
> activation datahandlers are not included in the mail uber-jar that gets 
> built.  I thought this problem had been fixed when the uber jar had been 
> created, but there were other classes I didn't really know about until 
> this came up.
> So, currently, to using the Sun javamail implementation requires 2 jar 
> files, mail.jar and activation .jar.  To use the Geronimo version with 
> equivalent function, you need the Geronimo activation spec jar, the 
> Geronimo javamail mail jar (which includes the javamail spec and 
> javamail providers), AND the geronimo-activation-1.0 jar, which adds in 
> data source handlers that that Sun includes in their mail.jar.
> This is a bit awkward, as the spec jars and the provider jars are built 
> outside of Geronimo, while the geronimo-activation module is part of the 
> server build, even though it is code that's completely independent of 
> Geronimo (no dependencies on Geronimo code at all).
> 
> Based on Sun's precedent, and what we did earlier with the javamail 
> provider code (formerly the geronimo-javamail-transport module), the 
> code in the current geronimo-activation module should be moved to the 
> javamail provider code tree so that all of these classes get bundled in 
> the jar file that makes up the javamail implementation.
> Are there any objects to doing this?
> 
> Rick
> 
>