Hi Mel, So is the problem about maintaining the third party source? Gaining access to the source for Mockito, or to any open source mocking framework should not be a problem.
Please advise. Thanks in advance, Rey Malahay On 8 September 2011 08:44, Martinez, Mel - 1004 - MITLL < [email protected]> wrote: > 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 > -- My heroes are the ones who survived doing it wrong, who made mistakes, but recovered from them. - Bono
