I'd certainly support moving the transports out of the Geronimo server SVN tree and into a separate repos/asf/geronimo/mail-transports tree or something. That way they could be independently versioned along with the spec JARs and you wouldn't ever have to pull something out of a server snapshot to get a working set of JARs. (I don't much like putting transports into the spec module.)
I also think Dain's suggestion is a good one to offer a mail uberjar with activation, mail, and transports. Aaron On 5/2/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
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 >> >> >> >>
