This is a new module contained in 2 new files plus a unit test, so it's understandable that it would be a larger commit.
Your code style and documentation is great, despite Java being a verbose beast. I'm spending most of my time making sure it meshes well with the current code base and that functionality isn't duplicated or could be consolidated. The main issue (brought up previously) are the overlaps with the class you considered replacing. For the sake of backwards compatibility, if I could fit your changes into an existing class without creating a jackalope, it'll be easiest for implementers to find your features. I'm less familiar with cell styles in POI, so I'm having to familiarize myself with existing capabilities before I can figure out how your patch best fits. I understand your desire to get your code mainlined so you don't have to maintain forks at your $DAYJOB, and also wanting to contribute to the community. Thanks for the many months of patience! On Mar 31, 2016 2:11 PM, "Nick Burch" <n...@apache.org> wrote: > On Thu, 31 Mar 2016, Murphy, Mark wrote: > >> If you have any questions or comments, I would love to hear your feedback. >> > > I haven't looked at this patch of yours. However... > > Several small patches are easier to review and apply than one big, for > un-related fixes or improvements. However, one big patch is often easier to > review for a big change. Patches with unit tests are safer than those > without > > Using a git fork can help with some of these things. It's possible to work > on a bunch of stuff at once, committing locally, then edit (squashing + > cherry-picking) into a logical set of changes to review. However, you can > also shoot your own feet off easier with git, so do beware ;-) > > Nick > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > For additional commands, e-mail: dev-h...@poi.apache.org > >
