On Fri, 6 May 2011, Stefan Stern wrote:
Additionally, I try to split my changes to several patches, sorted into according bug entries, so my proposals won't come in as a huge patch. Hopefully, this will ease up your integration efforts.
Wonderful, thanks. The quicker it is to review the patch, generally the quicker it will be applied :)
Where possible, do please include unit tests if you can (I think you've already been doing this in many cases, please keep it going!)
Also, as you may have noticed, a lot of XWPF has evolved from user contributions, rather than being pre-planned . If you feel something needs a big re-write, it might be best to explain why on the dev list, then if we agree work up a patch for that independent of new features. That makes it easier to review.
As next great step, I would like to remove all "Cursor"-Usage from XWPF API and keep XML handling inside the XWPF classes. This will take place during the next 2 months.
In general this sounds good to me. Ideally we'd do almost everthing with usermodel classes (as we do with XSSF), but anything to make life easier would be good.
In order to provide code with least difference, are there any coding guidelines concerning where paranthesis are supposed to be placed, whether to use tabs or space, etc.? I tried to define an Eclipse formatter configuration, that does least "damage" to existing classes. But among the classes, paranthesis are placed different, indention is made with tabs or spaces, has the size of 2 or 4, line wrapping is different, etc., so formtatting a class with my formatter almost always ends up in many differences.
Alas we've not had a standard in a while, so different people have done different things. I'm tempted to say that we should go for the same code layout that Tika uses, since there's overlap in the committership and code, and it's a fairly standard one. Does anyone have strong opinions either way?
Nick --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
