commons-dev mailing list archives

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

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.



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

View raw message