Re: [Springframework-developer] Testing JavaMail

[Colin S. <col...@ex...>]

Unfortunately we couldn't bundle it up (or any other GPL library) with 
Spring, or Spring itself would have to become GPL. With GPL code (as 
opposed to LGPL), this applies even if trying to use reflection to not 
do direct imports of library classes; just the act of bundling the stuff 
together is viral, to the best of my knowledge. However, one option 
would be to provide information on where it could be pulled down, and 
have that part of the testsuite become conditional.

This strategy would work with any library which is GPL and which doesn't 
actually have to be referred to by Java code (ie there is no need for 
imports).

It's obviously easier and cleaner to use a non-GPL alternative, if one 
can be found. One other possiblity is to approach the dumbster author an 
ask if he is ammenable to switching licenses from GPL to LGPL. I have 
had some success with this strategy in the past.

Regards,
Colin


Alef Arendsen (JTeam) wrote:

>I've taken a look at the JavaMail package and it's tested right now.
>However, I could not find the mailer we used internally anymore, so I've
>snatched another mockup mailserver form the net. However, the library is
>licensed under GPL. I've never really understood how to handle GPL
>licenses when you're just using the library for testing purposes and
>stuff... Any objections?
>
>Furthermore, I was wondering why not all of the properties JavaMail
>specified can be set in the MailSetings object. For instance
>mail.smtp.port cannot be set?
>
>Any comments?
>
>Alef
>
>P.s. the mail library is located at
>http://sourceforge.net/projects/dumbster
>
>-----Oorspronkelijk bericht-----
>Van: spr...@li...
>[mailto:spr...@li...] Namens
>Rod Johnson
>Verzonden: Tuesday, September 23, 2003 8:50 AM
>Aan: al...@jt...; spr...@li...
>Onderwerp: Re: [Springframework-developer] Test coverage
>
>
>I took a look and mocking JavaMail isn't really an option (superbly
>untestable API, with static methods and final classes).
>
>So this is probably the only way to go... Thanks.
>
>Regards,
>Rod
>
>----- Original Message ----- 
>From: "Alef Arendsen (JTeam)" <al...@jt...>
>To: "'Rod Johnson'" <rod...@in...>;
><spr...@li...>
>Sent: Monday, September 22, 2003 10:48 PM
>Subject: RE: [Springframework-developer] Test coverage
>
>
>  
>
>>If nobody's busy doing it already, I'll see what I can do on the 
>>javamail package. I've got a devnull mailer lying around somewhere 
>>that we use for testing, maybe I can integrate it somehow...
>>
>>By the way, up to 76,7 now...
>>
>>Alef
>>
>>-----Oorspronkelijk bericht-----
>>Van: spr...@li...
>>[mailto:spr...@li...] Namens 
>>Rod Johnson
>>Verzonden: Saturday, September 20, 2003 11:17 PM
>>Aan: spr...@li...
>>Onderwerp: [Springframework-developer] Test coverage
>>
>>
>>I think one of the things that has contributed to the success and 
>>quality of Spring is our commitment to a good test suite. I've put a 
>>fair bit more work into the test suite over the weekend, with the 
>>upgrade to EasyMock 1.0 and new test suites for Velocity etc.
>>
>>I'm really pleased that everyone is emphasising tests in new coding, 
>>but there is a still a bit of catchup to do.
>>
>>With this and Alef's new tag tests, test coverage is now 75.8%. I'd 
>>like to see this go above 80% before 1.0RC1.
>>
>>So I think we should all kick in and add tests to our areas of 
>>interest. Please run the Clover analysis as a starting point.
>>
>>Current major gaps include:
>>- XSLT support. I wrote this code so I guess I really should do the 
>>tests but I'm not sure I have time. (These days I work entirely test 
>>first, but I wrote that last year.) If any of the dev team are using 
>>this, maybe they could take a look? It might require some refactoring.
>>- jdbc.core.support: No tests for incrementer support. Can the 
>>developers looking after this please try to add some tests?
>>
>>Any volunteers for these or other areas in which tests can be 
>>improved?
>>
>>Regards,
>>Rod
>>
>>    
>>