Actually, Ramiro is pointing in *exactly* the right direction ... I was indeed pointing my "javamail-1.3.2.url" property at the "lib/mailapi.jar" file of my JavaMail 1.3.2 distribution.
The only problem (in my case) is that my distro doesn't have a mail.jar in the "lib" directory -- it only contains imap.jar, mailapi.jar, pop3.jar, and smtp.jar there. Of course, there *is* a mail.jar in the main distro directory :-). Amazing what happens when you point at the correct JAR file ... tonight's build and upload of the email package should succeed! Thanks Ramiro!!! Craig On 6/14/05, Simon Kitching <[EMAIL PROTECTED]> wrote: > On Wed, 2005-06-15 at 01:31 -0300, Ramiro Pereira de Magalhaes wrote: > > Craig, > > > > after having some fight with the commons-email project I discovered the > > problem that breaks it: you're compiling the project with the > > <javamail_path>/lib/mailapi.jar package instead of > > <javamail_path>/mail.jar (check the build.properties file). The first > > one does not have the necessary Providers (in this case the SMTP > > provider) required by Dumbster, the fake mail server used for testing. > > The other one does. Once I fixed this, all tests passed. > > > > My source of information was > > http://www.javaworld.com/javaworld/jw-10-2001/jw-1026-javamail.html, > > quoted below: > > "The |mailapi.jar| file contains the core API classes, while the > > |pop3.jar| and |smtp.jar| files contain the provider implementations for > > the respective mail protocols. (We won't use the |imap.jar| file in this > > article.) Think of the provider implementations as similar to JDBC (Java > > Database Connectivity) drivers, but for messaging systems rather than > > databases. As for the |mail.jar| file, it contains each of the above jar > > files, so you could restrict your classpath to just the |mail.jar| and > > |activation.jar| files." > > > > I hope this helps make things move again... > > Sorry, Ramiro, but to use an old expression: I think you're beating a > dead horse. > > Craig kindly runs the nightly builds for commons projects, but isn't an > email developer. And while your fix may well be right, no-one should > make that change without spending some time thinking about what the > implications are, and why it wasn't done that way before. And no-one > seems to have the enthusiasm or time to do that. > > In any case, that would just make the nightly builds work again. That > isn't much use when there are no changes being applied to the project > source. > > Unless an existing commons committer is willing to volunteer their time > to work on this for no particular reason, or a committer happens to > *need* the email project in some of their other work, or some > non-committer with a good open-source track record comes along (someone > we could feel comfortable with granting committer access to immediately) > there just isn't likely to be any progress on commons-email here. > > Regards, > > Simon > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
