Thanks Guys, I appreciate the fact that this issue is still under discussion. In the meantime, I will put my work, which I intended to submit to the project, on the backburners. I refuse to submit work that has not been properly unit tested. I hope for an outcome in favour of a mocking framework which developers will use in conjunction with their unit tests.
Kind regards, Rey Malahay On 8 September 2011 18:30, Adam Nichols <[email protected]> wrote: > If there's a way to make it "excluded by default" when building a > release version of the jar, then that should alleviate my concerns of > adding another dependency. I'm not at all familiar with Maven, so I'm > not sure how optional dependencies are handled. I believe > bouncycastle is handled this way. I searched the Internet downloaded > all the jar files manually until it compiled when I was first setting > up the project. I know bc isn't required until runtime, but I haven't > really looked into why and how all that works. > > Better (automated) testing makes it much easier to track down bugs, > and I fully support that. Whenever I fix a bug, I try to include a > sample PDF and write a JUnit test case demonstrates the fix actually > does fix the issue. I mainly do this to prove to myself that my patch > is fixing the issue I believe it is, but it also allows anyone else to > run the test before the patch and after, plus it may head off some > regression bugs down the road. > > Just my 2c. I'll wait for implementation specifics before I vote up or > down. > > --Adam > > On Thu, Sep 8, 2011 at 8:05 PM, rey malahay <[email protected]> wrote: > > 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 > > > -- My heroes are the ones who survived doing it wrong, who made mistakes, but recovered from them. - Bono
