On your point - if it is a requirement to be able to build and test the library from source, then, no, the problems of inclusion can persist.
As part of our mission we archive all source for all 3rd party components and have to show the ability to build and support such. All artifacts required for the build have to be traceable and approved If the test harness requires some new artifact then that will have to be approved. Mel -----Original Message----- From: Jukka Zitting [mailto:[email protected]] Sent: Thursday, September 08, 2011 3:31 AM To: [email protected] Subject: Re: Mocking Frameworks Hi, On Wed, Sep 7, 2011 at 4:13 PM, Martinez, Mel - 1004 - MITLL <[email protected]> wrote: > The interests Adam alluded to extend beyond just the direct interests of the > ASF. Adding any new third party code or package is often a very, very big > deal for those of us who depend on ASF components such as PDFBox. Note that a testing tool is by definition not included in the jar artifacts used downstream, so their licensing impact is minimal. The only problem is if the license of the testing tool would virally affect the license of the test code within PDFBox, but that won't be the case at least with the MIT-licensed Mockito. > However the disadvantages of including yet-another-package in the > distribution outweigh the benefits, imho. I disagree based on the above point. Better testing tools help improve quality and their impact on licensing is minimal. So, FWIW, +1 to using a mock tool in unit tests. BR, Jukka Zitting
smime.p7s
Description: S/MIME cryptographic signature
