commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <>
Subject Re: [email] FIXED commons-email tests for nightly builds script
Date Wed, 15 Jun 2005 05:05:43 GMT
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!!!


On 6/14/05, Simon Kitching <> 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 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
> >,
> > 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message