+1 for the mocking framework. :-)
On Fri, Sep 9, 2011 at 10:41 AM, Martinez, Mel - 1004 - MITLL <[email protected]> wrote: > That sounds reasonable. I fully concur that our project's audit and > oversight level is not the norm. We thus already accept that we have more > work to do in dealing with added dependencies than normal. This isn't just > in regards to PDFBox, btw. > > My expression of concern here is in the spirit of "If I can avoid increasing > that work, I will!" :-D > > The truth is, given the time frames, I'm really looking out for someone else > who will end up with that work dumped on them. I would not be a good team > player if I didn't advocate for conservatism on this point. > > Mel > > -----Original Message----- > From: Jukka Zitting [mailto:[email protected]] > Sent: Friday, September 09, 2011 9:49 AM > To: [email protected] > Subject: Re: Mocking Frameworks > > Hi, > > On Fri, Sep 9, 2011 at 3:19 PM, Martinez, Mel - 1004 - MITLL > <[email protected]> wrote: >> Jukka - It isn't about what I 'want' to go through. > > Yeah, sorry for picking on you specifically. My point is that what > you're describing is a rather high level of oversight that isn't > mandatory or even desirable for the average PDFBox user. Thus while I > do understand your reluctance on new dependencies (even test ones), in > the bigger picture it seems to me like a rather marginal concern when > balanced against the potential benefit to all PDFBox users through > better test coverage. > >> As I said before, the committers have final say, not I. If this gets > added, >> then when we upgrade to that version of PDFBox, we will simply have to go >> through the necessary bureaucratic hoops. > > Note that PDFBox 1.7 will in any case have a lot of new code and > dependencies thanks to the recent integration of the preflight and > xmpbox components. > > Anyway, if you want to avoid the extra test dependency, I suggest you > look at the patch Rey's planning to submit and then submit a followup > patch that modifies the new test cases to not require the mock > library. That's the Apache way of resolving conflicts like these. > > BR, > > Jukka Zitting >
