commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dion Gillard <dion.gill...@gmail.com>
Subject Re: [email] FIXED commons-email tests for nightly builds script
Date Wed, 15 Jun 2005 05:18:18 GMT
I think it's a bit pessimistic to say it's a dead horse.

I should have some free time for email later this week....

On 6/15/05, Simon Kitching <skitching@apache.org> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
> 


-- 
http://www.multitask.com.au/people/dion/
"You are going to let the fear of poverty govern your life and your
reward will be that you will eat, but you will not live." - George
Bernard Shaw

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message