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
smime.p7s
Description: S/MIME cryptographic signature
