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 <reymala...@gmail.com> 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 < > m.marti...@ll.mit.edu> 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:jukka.zitt...@gmail.com] >> Sent: Thursday, September 08, 2011 3:31 AM >> To: dev@pdfbox.apache.org >> Subject: Re: Mocking Frameworks >> >> Hi, >> >> On Wed, Sep 7, 2011 at 4:13 PM, Martinez, Mel - 1004 - MITLL >> <m.marti...@ll.mit.edu> 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 >
