Why not create an additional geronimo-javamail-nodep-x.x.jar artifact
that has all the jars merged together?
-dain
On May 2, 2006, at 1:57 AM, Rick McGuire wrote:
> Alan D. Cabrera wrote:
>> Rick McGuire wrote:
>>> The more the geronimo javamail support is starting to get used,
>>> the more uncomfortable I'm getting with the current structure of
>>> the javamail code. Let me level-set the situation first, so
>>> everybody understands the issues.
>>>
>>> To start with, the Sun impl of javamail is not really like other
>>> jar files we consider "spec" code. This jar files contains lots
>>> of classes in the javax.mail.* package tree, but it also contains
>>> a number of backing classes in a com.sun.mail.* tree that help
>>> implement certain features. For example, there are various
>>> encoders/decoders used by the MimeUtility class. These classes
>>> are undocumented, and are separate from the public javamail api
>>> classes.
>>>
>>> In addition to those classes, the Sun javamail jar file contains
>>> the Sun implementations of the protocol transports and stores
>>> (smtp, pop3, and imap are supported). In order to use the Sun
>>> version of javamail, you only need to javamail jar and the jaf
>>> (activation jar).
>>>
>>> For the Geronimo implementation, things are split up a little
>>> more. The geronimo-spec-javamail jar file contains all of the
>>> javax.mail.* classes, plus whatever backing utility classes are
>>> needed to implement some of the features (with
>>> org.apache.geronimo.* package structure). The jar does NOT
>>> however, contain any of the protocol implementations.
>>>
>>> The Geronimo protocol implementations are contained in the
>>> javamail-transport module of the main Geronimo code tree. This
>>> jar contains only the protocol implementations, plus some utility
>>> classes shared between the protocols. In order to use the
>>> Geronimo javamail support, you need 3 jar files: 1) the
>>> activation jar, 2) the javamail jar, and 3) the javamail-
>>> transport jar. 1) and 2) are available separately, but 3) IIUC,
>>> is only available within a Geronimo snapshot jar.
>>> And just to confuse matters even more, there is another Geronimo
>>> mail module. This module contains GBeans for configuring various
>>> mail resources. These GBeans are independent of which javamail
>>> implementation is being used, so we can keep these out of the
>>> discussion.
>> This is normal for just about all the spec implementations for
>> Geronimo. 1) spec jar, 2) impl, 3) GBean-mumbo-jumbo. Hopefully,
>> w/ XBean, the GBean stuff will go away.
>>>
>>> There is a major problem with the current Geronimo structure.
>>> The implementation of the protocol handlers (transports and
>>> stores) is highly dependent on the version of the api they are
>>> written to. I ran into this problem just today. Jira
>>> GERONIMO-1957 addressed the fact that changes in the geronimo 1.1
>>> javamail spec jar broke the 1.0 version of the SMTP transport.
>>> However, the current 1.1 codebase was running with this obsolete
>>> code, so I had to back port the trunk version of the SMTP
>>> transport into the 1.1 code tree. This also raised the question
>>> of whether we should pull back the other transport/store
>>> implementations into 1.1.
>>>
>>> Now this is an issue that never arises with the Sun
>>> implementation. Since the protocol handlers are contained within
>>> the API jar, you can never get these packages out of sync. They
>>> travel around together by definition. In order for somebody to
>>> make use of the Geronimo javamail stack, you'd need to pull down
>>> the javamail and activation spec jars, then extract a javamail-
>>> transport jar from a Geronimo snapshot that was using a matching
>>> spec level. Lots of opportunity for error here, and it makes it
>>> difficult for other projects to use the javamail support. Axis
>>> is already doing this, but fortunately, they are only using the
>>> javax.mail.* stuff for Mime encoding support and are not
>>> dependent on transport or store implementations.
>>>
>>> It seems, at a minimum, that the javamail-transport code should
>>> be moved from being a Geronimo module to a spec component.
>>> Ideally, it really should be merged into the javamail spec module
>>> to mirror how the Sun implementation works.
>>> Am I missing something? Is there some compelling reason why this
>>> should be structured this way? I really suspect we ended up at
>>> this point through a combination of ignorance and historical
>>> accident. Originally, the smtp transport code was just a sandbox
>>> component. It was upgraded into working code because the console
>>> wanted to implement a portlet for configuring mail resouces
>>> configurations. When this code was promoted out of the sandbox,
>>> a new javamail-transport module was created because we weren't
>>> really sure where it really belonged....and we named it badly to
>>> boot. It really should have been called javamail-protocol. The
>>> transport portion of the name starting looking silly when we add
>>> the pop3 STORE protocol handler.
>>
>> I look at things from a different viewpoint. I never really
>> understood why any part of the implementation had to be bundled
>> with the JavaMail spec jar. Folklore has it that the
>> specification implies that this must be the case. This flies in
>> the face of my experience w/ many of the Java JSR specs that I am
>> familiar with; I have not read the spec for fear of being asked to
>> support it. :) IMO, doing something because Sun does it that way
>> is not a good argument.
>>
>> Can you explain why *any* part of the implementation needs to be a
>> part of the spec jar? My personal preference is to keep the
>> protocol handlers out of it.
> I think part of my concern with javamail is the growing desire to
> use it decoupled from Geronimo. Axis is already doing this, but
> only using the base API classes (which are more implementation than
> "spec". There's a lot of executable code in the base API
> classes). Axis is already doing this for their attachment
> support. I hear rumblings that Harmony would like to use this
> package as well. As currently bundled, there is no one place you
> can go to obtain just the complete Geronimo javamail
> implementation. Right now, you need to download 2 spec jars +
> extract the javamail-transport jar from a Geronimo snapshot in
> order to do this. The code in javamail-transport has no
> dependencies on any other part of Geronimo, so that coupling is a
> bit artificial.
>
> The other reason is just one of pragmatics. Users seem to be
> tripping over this all the time, getting errors about unable to
> load the smtp protocol because the javamail-transport is missing
> from there configuration. If the protocol handlers and the API
> classes are together, as with the Sun jars, these errors will no
> longer occur.
>
>
>>
>>
>> Regards,
>> Alan
>>
>>
>>
>>
