RE: [VOTE] Apache POI 3.15 (RC2)
With the exception of the ppt master slide text, the content looks consistent across the POI file types. Found two bugs in my eval code, but no regressions that would hold up the release :)
RE: [VOTE] Apache POI 3.15 (RC2)
All thanks to Luis Filipe Nassif for diagnosis and the patch! > I have some minor modifications/simplifications Y, I wanted to change as little as possible. It is probably better to move all of the checks we do for "is this a cleaner" in unmap() up to the point where we add to the buffer. It felt suboptimal (but completely reasonable for now) to rely on ByteBuffer.allocate() to create something that didn't need to be cleaned...across all versions of Java, etc. -Original Message- From: Dominik Stadler [mailto:dominik.stad...@gmx.at] Sent: Thursday, September 15, 2016 9:15 AM To: POI Developers List <dev@poi.apache.org> Subject: Re: [VOTE] Apache POI 3.15 (RC2) Hi, The mem-leak patch looks good and sane! I am still not sure how they end up with such a large amount of allocated memory for one file, but it is surely better to not keep the buffers if we do not need the special handling during close() anyway. I have some minor modifications/simplifications around these statements that I will apply post-release Dominik. On Thu, Sep 15, 2016 at 2:01 PM, Allison, Timothy B. <talli...@mitre.org> wrote: > >* I'll take a look at the patch on TIKA-2058, if it's low-risk it can > >go > in > I committed Luis Filipe Nassif's patch last night (BUG 60140). Please > do take a look to make sure the change doesn't cause any unforeseen problems. > > >> * I could do with input from those who use HSLF about whether to > >> hold > up another RC for the issue below. > > I've already patched the HSLF issue yesterday > > Thank you, Andi! > > > -Original Message- > From: David North [mailto:dtn-...@corefiling.co.uk] > Sent: Thursday, September 15, 2016 4:16 AM > To: dev@poi.apache.org > Subject: Re: [VOTE] Apache POI 3.15 (RC2) > > OK, current status: > > * I'll take a look at the patch on TIKA-2058, if it's low-risk it can > go in > * I could do with input from those who use HSLF about whether to hold > up another RC for the issue below. > > I may not have time to roll RC3 tonight; if not I'll do it tomorrow > night which gives us all the weekend to try it out. > > Thanks, > David > > On 14/09/16 21:39, Javen O'Neal wrote: > > The HSLF footer text regression is still open. > > https://bz.apache.org/bugzilla/show_bug.cgi?id=60003 > > https://issues.apache.org/jira/browse/TIKA-2013 > > > > On Sep 14, 2016 12:43 PM, "Dominik Stadler" <dominik.stad...@gmx.at> > wrote: > > > >> Hi, > >> > >> I'd also rather keep it as is to not break it multiple times. > >> > >> Dominik. > >> > >> On Wed, Sep 14, 2016 at 4:23 AM, Javen O'Neal > >> <javenon...@gmail.com> > >> wrote: > >> > >>> CellValue#getCellType was changed to return an enum after the 3.14 > >> release. > >>> I reverted that signature change in r1760607 (see bug 59791 > >>> comment > 13). > >>> > >>> For bug 59907, I broke backwards compatibility for ClientAnchor > >>> (both > >> HSSF > >>> and XSSF) in r1716313 (first appeared in POI 3.14 beta 1 and > >>> included in POI 3.14 final) without the usual 2 release > >>> deprecation warning. The question is do I restore the behavior of > >>> 3.13 (breaking code a second > >> time > >>> for anyone who upgraded their code to 3.14, and a third time > >>> whenever we retire the int code), or do we leave it as is and ask > >>> users to upgrade to the enum getter now? > >>> > >>> Looking at the code example from bug 59907 comment 1, the fix for > >>> them is > >>> simple: delete ".getValue()". > >>> > >>> On Sep 13, 2016 09:06, "Javen O'Neal" <javenon...@gmail.com> wrote: > >>> > >>>> I will commit a fix for this today with the goal for backwards > >>>> compatibility. > >>>> > >>>> Here's the plan: > >>>> getX() returns int > >>>> getXEnum() returns enum > >>>> setX(int) > >>>> setX(enum) > >>>> > >>>> I will also take a look at bug 59907 (client anchor enum) > >>>> > >>>> On Sep 13, 2016 6:58 AM, "David North" <dtn-...@corefiling.co.uk> > >> wrote: > >>>> > >>>>> Javen, any thoughts on this one? > >>>>> > >>>>> On 13/09/16 12:14, Dominik Stadler wrote: > >>>>>> Hi, > >>>>>> > >>&g
RE: [VOTE] Apache POI 3.15 (RC2)
I'm finally taking a look at the new exceptions from the reports. Most of the new exceptions seem to be on attachments within ppt. We recently changed how we handle embedded ole-wrapped attachments in ppt, and we're discovering new embedded file types. [1] Next...to look at the content report... [1] https://issues.apache.org/jira/browse/TIKA-2079 - To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
Re: [VOTE] Apache POI 3.15 (RC2)
Hi, The mem-leak patch looks good and sane! I am still not sure how they end up with such a large amount of allocated memory for one file, but it is surely better to not keep the buffers if we do not need the special handling during close() anyway. I have some minor modifications/simplifications around these statements that I will apply post-release Dominik. On Thu, Sep 15, 2016 at 2:01 PM, Allison, Timothy B. <talli...@mitre.org> wrote: > >* I'll take a look at the patch on TIKA-2058, if it's low-risk it can go > in > I committed Luis Filipe Nassif's patch last night (BUG 60140). Please do > take a look to make sure the change doesn't cause any unforeseen problems. > > >> * I could do with input from those who use HSLF about whether to hold > up another RC for the issue below. > > I've already patched the HSLF issue yesterday > > Thank you, Andi! > > > -Original Message- > From: David North [mailto:dtn-...@corefiling.co.uk] > Sent: Thursday, September 15, 2016 4:16 AM > To: dev@poi.apache.org > Subject: Re: [VOTE] Apache POI 3.15 (RC2) > > OK, current status: > > * I'll take a look at the patch on TIKA-2058, if it's low-risk it can go in > * I could do with input from those who use HSLF about whether to hold up > another RC for the issue below. > > I may not have time to roll RC3 tonight; if not I'll do it tomorrow night > which gives us all the weekend to try it out. > > Thanks, > David > > On 14/09/16 21:39, Javen O'Neal wrote: > > The HSLF footer text regression is still open. > > https://bz.apache.org/bugzilla/show_bug.cgi?id=60003 > > https://issues.apache.org/jira/browse/TIKA-2013 > > > > On Sep 14, 2016 12:43 PM, "Dominik Stadler" <dominik.stad...@gmx.at> > wrote: > > > >> Hi, > >> > >> I'd also rather keep it as is to not break it multiple times. > >> > >> Dominik. > >> > >> On Wed, Sep 14, 2016 at 4:23 AM, Javen O'Neal <javenon...@gmail.com> > >> wrote: > >> > >>> CellValue#getCellType was changed to return an enum after the 3.14 > >> release. > >>> I reverted that signature change in r1760607 (see bug 59791 comment > 13). > >>> > >>> For bug 59907, I broke backwards compatibility for ClientAnchor > >>> (both > >> HSSF > >>> and XSSF) in r1716313 (first appeared in POI 3.14 beta 1 and > >>> included in POI 3.14 final) without the usual 2 release deprecation > >>> warning. The question is do I restore the behavior of 3.13 (breaking > >>> code a second > >> time > >>> for anyone who upgraded their code to 3.14, and a third time > >>> whenever we retire the int code), or do we leave it as is and ask > >>> users to upgrade to the enum getter now? > >>> > >>> Looking at the code example from bug 59907 comment 1, the fix for > >>> them is > >>> simple: delete ".getValue()". > >>> > >>> On Sep 13, 2016 09:06, "Javen O'Neal" <javenon...@gmail.com> wrote: > >>> > >>>> I will commit a fix for this today with the goal for backwards > >>>> compatibility. > >>>> > >>>> Here's the plan: > >>>> getX() returns int > >>>> getXEnum() returns enum > >>>> setX(int) > >>>> setX(enum) > >>>> > >>>> I will also take a look at bug 59907 (client anchor enum) > >>>> > >>>> On Sep 13, 2016 6:58 AM, "David North" <dtn-...@corefiling.co.uk> > >> wrote: > >>>> > >>>>> Javen, any thoughts on this one? > >>>>> > >>>>> On 13/09/16 12:14, Dominik Stadler wrote: > >>>>>> Hi, > >>>>>> > >>>>>> I really hate to delay this further, but unfortunately we have a > >>> similar > >>>>>> problem in class CellValue as we tried to fix in Cell in RC2, the > >>>>>> getCellType() is now an enum whereas it was an int before, so > >>> something > >>>>>> like the following in user-code does break in POI 3.15: > >>>>>> > >>>>>> CellValue cellValue = checkAndGetCellValue(evaluator, sheet, > >>>>>> line); > >>>>>> > >>>>>> switch (cellValue.getCellType()) { > >>>>>> case Cell.CELL_TYPE_STRING: > >>>>>> > >>>>>> >
RE: [VOTE] Apache POI 3.15 (RC2)
>* I'll take a look at the patch on TIKA-2058, if it's low-risk it can go in I committed Luis Filipe Nassif's patch last night (BUG 60140). Please do take a look to make sure the change doesn't cause any unforeseen problems. >> * I could do with input from those who use HSLF about whether to hold up >> another RC for the issue below. > I've already patched the HSLF issue yesterday Thank you, Andi! -Original Message- From: David North [mailto:dtn-...@corefiling.co.uk] Sent: Thursday, September 15, 2016 4:16 AM To: dev@poi.apache.org Subject: Re: [VOTE] Apache POI 3.15 (RC2) OK, current status: * I'll take a look at the patch on TIKA-2058, if it's low-risk it can go in * I could do with input from those who use HSLF about whether to hold up another RC for the issue below. I may not have time to roll RC3 tonight; if not I'll do it tomorrow night which gives us all the weekend to try it out. Thanks, David On 14/09/16 21:39, Javen O'Neal wrote: > The HSLF footer text regression is still open. > https://bz.apache.org/bugzilla/show_bug.cgi?id=60003 > https://issues.apache.org/jira/browse/TIKA-2013 > > On Sep 14, 2016 12:43 PM, "Dominik Stadler" <dominik.stad...@gmx.at> wrote: > >> Hi, >> >> I'd also rather keep it as is to not break it multiple times. >> >> Dominik. >> >> On Wed, Sep 14, 2016 at 4:23 AM, Javen O'Neal <javenon...@gmail.com> >> wrote: >> >>> CellValue#getCellType was changed to return an enum after the 3.14 >> release. >>> I reverted that signature change in r1760607 (see bug 59791 comment 13). >>> >>> For bug 59907, I broke backwards compatibility for ClientAnchor >>> (both >> HSSF >>> and XSSF) in r1716313 (first appeared in POI 3.14 beta 1 and >>> included in POI 3.14 final) without the usual 2 release deprecation >>> warning. The question is do I restore the behavior of 3.13 (breaking >>> code a second >> time >>> for anyone who upgraded their code to 3.14, and a third time >>> whenever we retire the int code), or do we leave it as is and ask >>> users to upgrade to the enum getter now? >>> >>> Looking at the code example from bug 59907 comment 1, the fix for >>> them is >>> simple: delete ".getValue()". >>> >>> On Sep 13, 2016 09:06, "Javen O'Neal" <javenon...@gmail.com> wrote: >>> >>>> I will commit a fix for this today with the goal for backwards >>>> compatibility. >>>> >>>> Here's the plan: >>>> getX() returns int >>>> getXEnum() returns enum >>>> setX(int) >>>> setX(enum) >>>> >>>> I will also take a look at bug 59907 (client anchor enum) >>>> >>>> On Sep 13, 2016 6:58 AM, "David North" <dtn-...@corefiling.co.uk> >> wrote: >>>> >>>>> Javen, any thoughts on this one? >>>>> >>>>> On 13/09/16 12:14, Dominik Stadler wrote: >>>>>> Hi, >>>>>> >>>>>> I really hate to delay this further, but unfortunately we have a >>> similar >>>>>> problem in class CellValue as we tried to fix in Cell in RC2, the >>>>>> getCellType() is now an enum whereas it was an int before, so >>> something >>>>>> like the following in user-code does break in POI 3.15: >>>>>> >>>>>> CellValue cellValue = checkAndGetCellValue(evaluator, sheet, >>>>>> line); >>>>>> >>>>>> switch (cellValue.getCellType()) { >>>>>> case Cell.CELL_TYPE_STRING: >>>>>> >>>>>> >>>>>> I am sorry that I did not see this earlier but this can lead to >>>>>> the >>> same >>>>>> incompatibility as we had in Cell before. >>>>>> >>>>>> Dominik. >>>>>> >>>>>> On Sun, Sep 11, 2016 at 9:46 PM, David North <dno...@apache.org> >>> wrote: >>>>>> >>>>>>> Hi everyone, >>>>>>> >>>>>>> My apologies for going AWOL in the middle of the last release >>> attempt. >>>>> I >>>>>>> didn't anticipate that we'd find problems in review twice in a >>>>>>> row, >>> and >>>>>>> things have been very busy for me at work lately. However, I've >>>>>>> now rolled a second RC for 3.1
Re: [VOTE] Apache POI 3.15 (RC2)
David North wrote > * I could do with input from those who use HSLF about whether to hold up > another RC for the issue below. I've already patched the HSLF issue yesterday, based on the placeholder being a metroblob shape, but I wanted to think about it, if this is really a good idea or if a different indicator can be used, e.g. the placeholder only containing a predefined field. Regardless of the solution, I don't think, this is necessary to be fixed for the final, as it simply doesn't show up in the PPT and is only nice-to-have metadata. David North wrote > I may not have time to roll RC3 tonight ... As we have elapsed the anniversary date, we don't need to rush it now ... Andi -- View this message in context: http://apache-poi.1045710.n5.nabble.com/VOTE-Apache-POI-3-15-RC2-tp5724676p5724770.html Sent from the POI - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
Re: [VOTE] Apache POI 3.15 (RC2)
OK, current status: * I'll take a look at the patch on TIKA-2058, if it's low-risk it can go in * I could do with input from those who use HSLF about whether to hold up another RC for the issue below. I may not have time to roll RC3 tonight; if not I'll do it tomorrow night which gives us all the weekend to try it out. Thanks, David On 14/09/16 21:39, Javen O'Neal wrote: > The HSLF footer text regression is still open. > https://bz.apache.org/bugzilla/show_bug.cgi?id=60003 > https://issues.apache.org/jira/browse/TIKA-2013 > > On Sep 14, 2016 12:43 PM, "Dominik Stadler"wrote: > >> Hi, >> >> I'd also rather keep it as is to not break it multiple times. >> >> Dominik. >> >> On Wed, Sep 14, 2016 at 4:23 AM, Javen O'Neal >> wrote: >> >>> CellValue#getCellType was changed to return an enum after the 3.14 >> release. >>> I reverted that signature change in r1760607 (see bug 59791 comment 13). >>> >>> For bug 59907, I broke backwards compatibility for ClientAnchor (both >> HSSF >>> and XSSF) in r1716313 (first appeared in POI 3.14 beta 1 and included in >>> POI 3.14 final) without the usual 2 release deprecation warning. The >>> question is do I restore the behavior of 3.13 (breaking code a second >> time >>> for anyone who upgraded their code to 3.14, and a third time whenever we >>> retire the int code), or do we leave it as is and ask users to upgrade to >>> the enum getter now? >>> >>> Looking at the code example from bug 59907 comment 1, the fix for them is >>> simple: delete ".getValue()". >>> >>> On Sep 13, 2016 09:06, "Javen O'Neal" wrote: >>> I will commit a fix for this today with the goal for backwards compatibility. Here's the plan: getX() returns int getXEnum() returns enum setX(int) setX(enum) I will also take a look at bug 59907 (client anchor enum) On Sep 13, 2016 6:58 AM, "David North" >> wrote: > Javen, any thoughts on this one? > > On 13/09/16 12:14, Dominik Stadler wrote: >> Hi, >> >> I really hate to delay this further, but unfortunately we have a >>> similar >> problem in class CellValue as we tried to fix in Cell in RC2, the >> getCellType() is now an enum whereas it was an int before, so >>> something >> like the following in user-code does break in POI 3.15: >> >> CellValue cellValue = checkAndGetCellValue(evaluator, sheet, line); >> >> switch (cellValue.getCellType()) { >> case Cell.CELL_TYPE_STRING: >> >> >> I am sorry that I did not see this earlier but this can lead to the >>> same >> incompatibility as we had in Cell before. >> >> Dominik. >> >> On Sun, Sep 11, 2016 at 9:46 PM, David North >>> wrote: >> >>> Hi everyone, >>> >>> My apologies for going AWOL in the middle of the last release >>> attempt. > I >>> didn't anticipate that we'd find problems in review twice in a row, >>> and >>> things have been very busy for me at work lately. However, I've now >>> rolled a second RC for 3.15. >>> >>> https://dist.apache.org/repos/dist/dev/poi/3.15-RC2/ >>> >>> Areas to review: >>> >>> * Does it work? >>> * Are the sigs and hashes valid? >>> * Have the issues with the last RC been fixed? >>> * Are the release notes now in good shape? >>> >>> The vote starts now and ends at 20:55 BST on Tuesday 13 September >>> 2016. >>> >>> Here is my +1. >>> >>> After this release is done, I'll try and find some time to profile >>> the >>> build & tests - 15 minutes is quite a wait on an SSD (it's possible >>> we >>> might want some multi-threaded options on the tests). >>> >>> Thanks, >>> >>> -- >>> David North | www.dnorth.net >>> >>> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > For additional commands, e-mail: dev-h...@poi.apache.org > > >>> >> > - To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
Re: [VOTE] Apache POI 3.15 (RC2)
The HSLF footer text regression is still open. https://bz.apache.org/bugzilla/show_bug.cgi?id=60003 https://issues.apache.org/jira/browse/TIKA-2013 On Sep 14, 2016 12:43 PM, "Dominik Stadler"wrote: > Hi, > > I'd also rather keep it as is to not break it multiple times. > > Dominik. > > On Wed, Sep 14, 2016 at 4:23 AM, Javen O'Neal > wrote: > > > CellValue#getCellType was changed to return an enum after the 3.14 > release. > > I reverted that signature change in r1760607 (see bug 59791 comment 13). > > > > For bug 59907, I broke backwards compatibility for ClientAnchor (both > HSSF > > and XSSF) in r1716313 (first appeared in POI 3.14 beta 1 and included in > > POI 3.14 final) without the usual 2 release deprecation warning. The > > question is do I restore the behavior of 3.13 (breaking code a second > time > > for anyone who upgraded their code to 3.14, and a third time whenever we > > retire the int code), or do we leave it as is and ask users to upgrade to > > the enum getter now? > > > > Looking at the code example from bug 59907 comment 1, the fix for them is > > simple: delete ".getValue()". > > > > On Sep 13, 2016 09:06, "Javen O'Neal" wrote: > > > > > I will commit a fix for this today with the goal for backwards > > > compatibility. > > > > > > Here's the plan: > > > getX() returns int > > > getXEnum() returns enum > > > setX(int) > > > setX(enum) > > > > > > I will also take a look at bug 59907 (client anchor enum) > > > > > > On Sep 13, 2016 6:58 AM, "David North" > wrote: > > > > > >> Javen, any thoughts on this one? > > >> > > >> On 13/09/16 12:14, Dominik Stadler wrote: > > >> > Hi, > > >> > > > >> > I really hate to delay this further, but unfortunately we have a > > similar > > >> > problem in class CellValue as we tried to fix in Cell in RC2, the > > >> > getCellType() is now an enum whereas it was an int before, so > > something > > >> > like the following in user-code does break in POI 3.15: > > >> > > > >> > CellValue cellValue = checkAndGetCellValue(evaluator, sheet, line); > > >> > > > >> > switch (cellValue.getCellType()) { > > >> > case Cell.CELL_TYPE_STRING: > > >> > > > >> > > > >> > I am sorry that I did not see this earlier but this can lead to the > > same > > >> > incompatibility as we had in Cell before. > > >> > > > >> > Dominik. > > >> > > > >> > On Sun, Sep 11, 2016 at 9:46 PM, David North > > wrote: > > >> > > > >> >> Hi everyone, > > >> >> > > >> >> My apologies for going AWOL in the middle of the last release > > attempt. > > >> I > > >> >> didn't anticipate that we'd find problems in review twice in a row, > > and > > >> >> things have been very busy for me at work lately. However, I've now > > >> >> rolled a second RC for 3.15. > > >> >> > > >> >> https://dist.apache.org/repos/dist/dev/poi/3.15-RC2/ > > >> >> > > >> >> Areas to review: > > >> >> > > >> >> * Does it work? > > >> >> * Are the sigs and hashes valid? > > >> >> * Have the issues with the last RC been fixed? > > >> >> * Are the release notes now in good shape? > > >> >> > > >> >> The vote starts now and ends at 20:55 BST on Tuesday 13 September > > 2016. > > >> >> > > >> >> Here is my +1. > > >> >> > > >> >> After this release is done, I'll try and find some time to profile > > the > > >> >> build & tests - 15 minutes is quite a wait on an SSD (it's possible > > we > > >> >> might want some multi-threaded options on the tests). > > >> >> > > >> >> Thanks, > > >> >> > > >> >> -- > > >> >> David North | www.dnorth.net > > >> >> > > >> >> > > >> > > > >> > > >> - > > >> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > > >> For additional commands, e-mail: dev-h...@poi.apache.org > > >> > > >> > > >
Re: [VOTE] Apache POI 3.15 (RC2)
Hi, I'd also rather keep it as is to not break it multiple times. Dominik. On Wed, Sep 14, 2016 at 4:23 AM, Javen O'Nealwrote: > CellValue#getCellType was changed to return an enum after the 3.14 release. > I reverted that signature change in r1760607 (see bug 59791 comment 13). > > For bug 59907, I broke backwards compatibility for ClientAnchor (both HSSF > and XSSF) in r1716313 (first appeared in POI 3.14 beta 1 and included in > POI 3.14 final) without the usual 2 release deprecation warning. The > question is do I restore the behavior of 3.13 (breaking code a second time > for anyone who upgraded their code to 3.14, and a third time whenever we > retire the int code), or do we leave it as is and ask users to upgrade to > the enum getter now? > > Looking at the code example from bug 59907 comment 1, the fix for them is > simple: delete ".getValue()". > > On Sep 13, 2016 09:06, "Javen O'Neal" wrote: > > > I will commit a fix for this today with the goal for backwards > > compatibility. > > > > Here's the plan: > > getX() returns int > > getXEnum() returns enum > > setX(int) > > setX(enum) > > > > I will also take a look at bug 59907 (client anchor enum) > > > > On Sep 13, 2016 6:58 AM, "David North" wrote: > > > >> Javen, any thoughts on this one? > >> > >> On 13/09/16 12:14, Dominik Stadler wrote: > >> > Hi, > >> > > >> > I really hate to delay this further, but unfortunately we have a > similar > >> > problem in class CellValue as we tried to fix in Cell in RC2, the > >> > getCellType() is now an enum whereas it was an int before, so > something > >> > like the following in user-code does break in POI 3.15: > >> > > >> > CellValue cellValue = checkAndGetCellValue(evaluator, sheet, line); > >> > > >> > switch (cellValue.getCellType()) { > >> > case Cell.CELL_TYPE_STRING: > >> > > >> > > >> > I am sorry that I did not see this earlier but this can lead to the > same > >> > incompatibility as we had in Cell before. > >> > > >> > Dominik. > >> > > >> > On Sun, Sep 11, 2016 at 9:46 PM, David North > wrote: > >> > > >> >> Hi everyone, > >> >> > >> >> My apologies for going AWOL in the middle of the last release > attempt. > >> I > >> >> didn't anticipate that we'd find problems in review twice in a row, > and > >> >> things have been very busy for me at work lately. However, I've now > >> >> rolled a second RC for 3.15. > >> >> > >> >> https://dist.apache.org/repos/dist/dev/poi/3.15-RC2/ > >> >> > >> >> Areas to review: > >> >> > >> >> * Does it work? > >> >> * Are the sigs and hashes valid? > >> >> * Have the issues with the last RC been fixed? > >> >> * Are the release notes now in good shape? > >> >> > >> >> The vote starts now and ends at 20:55 BST on Tuesday 13 September > 2016. > >> >> > >> >> Here is my +1. > >> >> > >> >> After this release is done, I'll try and find some time to profile > the > >> >> build & tests - 15 minutes is quite a wait on an SSD (it's possible > we > >> >> might want some multi-threaded options on the tests). > >> >> > >> >> Thanks, > >> >> > >> >> -- > >> >> David North | www.dnorth.net > >> >> > >> >> > >> > > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > >> For additional commands, e-mail: dev-h...@poi.apache.org > >> > >> >
Re: [VOTE] Apache POI 3.15 (RC2)
Hi, I would rather look at using some tools like https://github.com/siom79/japicmp on the CI machine and check the output on a regular basis or fail the build if there are incompatible changes. This way we do not rely on having unit-tests for a method and the old source often will not compile any more with newer code for arbitrary reasonshttps://bz.apache.org/bugzilla/show_bug.cgi?id=60134. I have created https://bz.apache.org/bugzilla/show_bug.cgi?id=60134 to track this idea. Dominik. On Wed, Sep 14, 2016 at 2:27 AM, Javen O'Nealwrote: > Could we do some checks for backwards compatibility? We need to test an > application written for a previous version of POI that exercises most or > all of the features, and what better than to use the unit tests from a > previous release plus the latest source code? This will include false > positives such as removal and rename of deprecated classes and methods. > > $ svn co https://svn.apache.org/repos/asf/tag/REL_3_15_FINAL > $ cd REL_3_15_FINAL > $ svn up -r1732982 src/testcases src/ooxml/testcases > src/scratchpad/testcases > $ ant clean jenkins > > This doesn't compile due to deletion of deprecated features and any > backwards incompatibilities. > > Is there a better way of doing this? > > On Sep 13, 2016 09:06, "Javen O'Neal" wrote: > > > I will commit a fix for this today with the goal for backwards > > compatibility. > > > > Here's the plan: > > getX() returns int > > getXEnum() returns enum > > setX(int) > > setX(enum) > > > > I will also take a look at bug 59907 (client anchor enum) > > > > On Sep 13, 2016 6:58 AM, "David North" wrote: > > > >> Javen, any thoughts on this one? > >> > >> On 13/09/16 12:14, Dominik Stadler wrote: > >> > Hi, > >> > > >> > I really hate to delay this further, but unfortunately we have a > similar > >> > problem in class CellValue as we tried to fix in Cell in RC2, the > >> > getCellType() is now an enum whereas it was an int before, so > something > >> > like the following in user-code does break in POI 3.15: > >> > > >> > CellValue cellValue = checkAndGetCellValue(evaluator, sheet, line); > >> > > >> > switch (cellValue.getCellType()) { > >> > case Cell.CELL_TYPE_STRING: > >> > > >> > > >> > I am sorry that I did not see this earlier but this can lead to the > same > >> > incompatibility as we had in Cell before. > >> > > >> > Dominik. > >> > > >> > On Sun, Sep 11, 2016 at 9:46 PM, David North > wrote: > >> > > >> >> Hi everyone, > >> >> > >> >> My apologies for going AWOL in the middle of the last release > attempt. > >> I > >> >> didn't anticipate that we'd find problems in review twice in a row, > and > >> >> things have been very busy for me at work lately. However, I've now > >> >> rolled a second RC for 3.15. > >> >> > >> >> https://dist.apache.org/repos/dist/dev/poi/3.15-RC2/ > >> >> > >> >> Areas to review: > >> >> > >> >> * Does it work? > >> >> * Are the sigs and hashes valid? > >> >> * Have the issues with the last RC been fixed? > >> >> * Are the release notes now in good shape? > >> >> > >> >> The vote starts now and ends at 20:55 BST on Tuesday 13 September > 2016. > >> >> > >> >> Here is my +1. > >> >> > >> >> After this release is done, I'll try and find some time to profile > the > >> >> build & tests - 15 minutes is quite a wait on an SSD (it's possible > we > >> >> might want some multi-threaded options on the tests). > >> >> > >> >> Thanks, > >> >> > >> >> -- > >> >> David North | www.dnorth.net > >> >> > >> >> > >> > > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > >> For additional commands, e-mail: dev-h...@poi.apache.org > >> > >> >
RE: [VOTE] Apache POI 3.15 (RC2)
Regression results are here. I haven't had a chance to look. This compares Tika's trunk with poi 3.15-rc1 (? I think?) against 3.15-beta1 in Tika 1.13. Some differences might be changes at the Tika level. I ran this against the full corpus so there are file formats we don't care about. https://github.com/tballison/share/blob/master/tika_comparisons/reports_tika_20160904_dev.zip
RE: [VOTE] Apache POI 3.15 (RC2)
All, On TIKA-2058 [1], Luis Filipe Nassif attached a patch for POI that _may_ solve a memory leak. We haven't had a chance to test that it solves the problem. The patch looks reasonable to me (it is very short), but I don't know enough about FileBackedDataSource to apply it responsibly. If anyone has a chance to look, it would be great to apply this before we respin. Thank you! Best, Tim [1] https://issues.apache.org/jira/browse/TIKA-2058 -Original Message- From: David North [mailto:dtn-...@corefiling.co.uk] Sent: Tuesday, September 13, 2016 12:09 PM To: POI Developers List <dev@poi.apache.org> Subject: Re: [VOTE] Apache POI 3.15 (RC2) Thanks - sounds good. I guess I'd better change my +1 to a -1 and try to build a fresh RC tomorrow night. On 13/09/16 17:06, Javen O'Neal wrote: > I will commit a fix for this today with the goal for backwards > compatibility. > > Here's the plan: > getX() returns int > getXEnum() returns enum > setX(int) > setX(enum) > > I will also take a look at bug 59907 (client anchor enum) > > On Sep 13, 2016 6:58 AM, "David North" <dtn-...@corefiling.co.uk> wrote: > >> Javen, any thoughts on this one? >> >> On 13/09/16 12:14, Dominik Stadler wrote: >>> Hi, >>> >>> I really hate to delay this further, but unfortunately we have a >>> similar problem in class CellValue as we tried to fix in Cell in >>> RC2, the >>> getCellType() is now an enum whereas it was an int before, so >>> something like the following in user-code does break in POI 3.15: >>> >>> CellValue cellValue = checkAndGetCellValue(evaluator, sheet, line); >>> >>> switch (cellValue.getCellType()) { >>> case Cell.CELL_TYPE_STRING: >>> >>> >>> I am sorry that I did not see this earlier but this can lead to the >>> same incompatibility as we had in Cell before. >>> >>> Dominik. >>> >>> On Sun, Sep 11, 2016 at 9:46 PM, David North <dno...@apache.org> wrote: >>> >>>> Hi everyone, >>>> >>>> My apologies for going AWOL in the middle of the last release >>>> attempt. I didn't anticipate that we'd find problems in review >>>> twice in a row, and things have been very busy for me at work >>>> lately. However, I've now rolled a second RC for 3.15. >>>> >>>> https://dist.apache.org/repos/dist/dev/poi/3.15-RC2/ >>>> >>>> Areas to review: >>>> >>>> * Does it work? >>>> * Are the sigs and hashes valid? >>>> * Have the issues with the last RC been fixed? >>>> * Are the release notes now in good shape? >>>> >>>> The vote starts now and ends at 20:55 BST on Tuesday 13 September 2016. >>>> >>>> Here is my +1. >>>> >>>> After this release is done, I'll try and find some time to profile >>>> the build & tests - 15 minutes is quite a wait on an SSD (it's >>>> possible we might want some multi-threaded options on the tests). >>>> >>>> Thanks, >>>> >>>> -- >>>> David North | www.dnorth.net >>>> >>>> >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional >> commands, e-mail: dev-h...@poi.apache.org >> >> > - To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
Re: [VOTE] Apache POI 3.15 (RC2)
I read through all the commits mentioned in the bugs that block bug 59836. These changes, excluding ClientAnchor.getAnchorType(), were made after the release of POI 3.14, so I could safely revert back to the original getter behavior. I have left ClientAnchor.getAnchorType() returning AnchorType enum and am ***hoping for some discussion on this before we start RC3.*** The commits I made span for reverting the other getters span r1760607 to r1760641. Some of these commits are just javadoc, @deprecated, @since, @Deprecated, @Internal, and @Removal changes. ***Please add the following*** to the release notes per r1737751 bug 59264 comment 4: CellStyle#BORDER_HAIR and #BORDER_DOTTED were swapped to correctly reflect the official names and to be consistent with BorderStyle enum. HAIR has smaller dots than DOTTED On Sep 13, 2016 19:23, "Javen O'Neal"wrote: > CellValue#getCellType was changed to return an enum after the 3.14 > release. I reverted that signature change in r1760607 (see bug 59791 > comment 13). > > For bug 59907, I broke backwards compatibility for ClientAnchor (both HSSF > and XSSF) in r1716313 (first appeared in POI 3.14 beta 1 and included in > POI 3.14 final) without the usual 2 release deprecation warning. The > question is do I restore the behavior of 3.13 (breaking code a second time > for anyone who upgraded their code to 3.14, and a third time whenever we > retire the int code), or do we leave it as is and ask users to upgrade to > the enum getter now? > > Looking at the code example from bug 59907 comment 1, the fix for them is > simple: delete ".getValue()". > > On Sep 13, 2016 09:06, "Javen O'Neal" wrote: > >> I will commit a fix for this today with the goal for backwards >> compatibility. >> >> Here's the plan: >> getX() returns int >> getXEnum() returns enum >> setX(int) >> setX(enum) >> >> I will also take a look at bug 59907 (client anchor enum) >> >> On Sep 13, 2016 6:58 AM, "David North" wrote: >> >>> Javen, any thoughts on this one? >>> >>> On 13/09/16 12:14, Dominik Stadler wrote: >>> > Hi, >>> > >>> > I really hate to delay this further, but unfortunately we have a >>> similar >>> > problem in class CellValue as we tried to fix in Cell in RC2, the >>> > getCellType() is now an enum whereas it was an int before, so something >>> > like the following in user-code does break in POI 3.15: >>> > >>> > CellValue cellValue = checkAndGetCellValue(evaluator, sheet, line); >>> > >>> > switch (cellValue.getCellType()) { >>> > case Cell.CELL_TYPE_STRING: >>> > >>> > >>> > I am sorry that I did not see this earlier but this can lead to the >>> same >>> > incompatibility as we had in Cell before. >>> > >>> > Dominik. >>> > >>> > On Sun, Sep 11, 2016 at 9:46 PM, David North >>> wrote: >>> > >>> >> Hi everyone, >>> >> >>> >> My apologies for going AWOL in the middle of the last release >>> attempt. I >>> >> didn't anticipate that we'd find problems in review twice in a row, >>> and >>> >> things have been very busy for me at work lately. However, I've now >>> >> rolled a second RC for 3.15. >>> >> >>> >> https://dist.apache.org/repos/dist/dev/poi/3.15-RC2/ >>> >> >>> >> Areas to review: >>> >> >>> >> * Does it work? >>> >> * Are the sigs and hashes valid? >>> >> * Have the issues with the last RC been fixed? >>> >> * Are the release notes now in good shape? >>> >> >>> >> The vote starts now and ends at 20:55 BST on Tuesday 13 September >>> 2016. >>> >> >>> >> Here is my +1. >>> >> >>> >> After this release is done, I'll try and find some time to profile the >>> >> build & tests - 15 minutes is quite a wait on an SSD (it's possible we >>> >> might want some multi-threaded options on the tests). >>> >> >>> >> Thanks, >>> >> >>> >> -- >>> >> David North | www.dnorth.net >>> >> >>> >> >>> > >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org >>> For additional commands, e-mail: dev-h...@poi.apache.org >>> >>>
Re: [VOTE] Apache POI 3.15 (RC2)
CellValue#getCellType was changed to return an enum after the 3.14 release. I reverted that signature change in r1760607 (see bug 59791 comment 13). For bug 59907, I broke backwards compatibility for ClientAnchor (both HSSF and XSSF) in r1716313 (first appeared in POI 3.14 beta 1 and included in POI 3.14 final) without the usual 2 release deprecation warning. The question is do I restore the behavior of 3.13 (breaking code a second time for anyone who upgraded their code to 3.14, and a third time whenever we retire the int code), or do we leave it as is and ask users to upgrade to the enum getter now? Looking at the code example from bug 59907 comment 1, the fix for them is simple: delete ".getValue()". On Sep 13, 2016 09:06, "Javen O'Neal"wrote: > I will commit a fix for this today with the goal for backwards > compatibility. > > Here's the plan: > getX() returns int > getXEnum() returns enum > setX(int) > setX(enum) > > I will also take a look at bug 59907 (client anchor enum) > > On Sep 13, 2016 6:58 AM, "David North" wrote: > >> Javen, any thoughts on this one? >> >> On 13/09/16 12:14, Dominik Stadler wrote: >> > Hi, >> > >> > I really hate to delay this further, but unfortunately we have a similar >> > problem in class CellValue as we tried to fix in Cell in RC2, the >> > getCellType() is now an enum whereas it was an int before, so something >> > like the following in user-code does break in POI 3.15: >> > >> > CellValue cellValue = checkAndGetCellValue(evaluator, sheet, line); >> > >> > switch (cellValue.getCellType()) { >> > case Cell.CELL_TYPE_STRING: >> > >> > >> > I am sorry that I did not see this earlier but this can lead to the same >> > incompatibility as we had in Cell before. >> > >> > Dominik. >> > >> > On Sun, Sep 11, 2016 at 9:46 PM, David North wrote: >> > >> >> Hi everyone, >> >> >> >> My apologies for going AWOL in the middle of the last release attempt. >> I >> >> didn't anticipate that we'd find problems in review twice in a row, and >> >> things have been very busy for me at work lately. However, I've now >> >> rolled a second RC for 3.15. >> >> >> >> https://dist.apache.org/repos/dist/dev/poi/3.15-RC2/ >> >> >> >> Areas to review: >> >> >> >> * Does it work? >> >> * Are the sigs and hashes valid? >> >> * Have the issues with the last RC been fixed? >> >> * Are the release notes now in good shape? >> >> >> >> The vote starts now and ends at 20:55 BST on Tuesday 13 September 2016. >> >> >> >> Here is my +1. >> >> >> >> After this release is done, I'll try and find some time to profile the >> >> build & tests - 15 minutes is quite a wait on an SSD (it's possible we >> >> might want some multi-threaded options on the tests). >> >> >> >> Thanks, >> >> >> >> -- >> >> David North | www.dnorth.net >> >> >> >> >> > >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org >> For additional commands, e-mail: dev-h...@poi.apache.org >> >>
Re: [VOTE] Apache POI 3.15 (RC2)
Thanks - sounds good. I guess I'd better change my +1 to a -1 and try to build a fresh RC tomorrow night. On 13/09/16 17:06, Javen O'Neal wrote: > I will commit a fix for this today with the goal for backwards > compatibility. > > Here's the plan: > getX() returns int > getXEnum() returns enum > setX(int) > setX(enum) > > I will also take a look at bug 59907 (client anchor enum) > > On Sep 13, 2016 6:58 AM, "David North"wrote: > >> Javen, any thoughts on this one? >> >> On 13/09/16 12:14, Dominik Stadler wrote: >>> Hi, >>> >>> I really hate to delay this further, but unfortunately we have a similar >>> problem in class CellValue as we tried to fix in Cell in RC2, the >>> getCellType() is now an enum whereas it was an int before, so something >>> like the following in user-code does break in POI 3.15: >>> >>> CellValue cellValue = checkAndGetCellValue(evaluator, sheet, line); >>> >>> switch (cellValue.getCellType()) { >>> case Cell.CELL_TYPE_STRING: >>> >>> >>> I am sorry that I did not see this earlier but this can lead to the same >>> incompatibility as we had in Cell before. >>> >>> Dominik. >>> >>> On Sun, Sep 11, 2016 at 9:46 PM, David North wrote: >>> Hi everyone, My apologies for going AWOL in the middle of the last release attempt. I didn't anticipate that we'd find problems in review twice in a row, and things have been very busy for me at work lately. However, I've now rolled a second RC for 3.15. https://dist.apache.org/repos/dist/dev/poi/3.15-RC2/ Areas to review: * Does it work? * Are the sigs and hashes valid? * Have the issues with the last RC been fixed? * Are the release notes now in good shape? The vote starts now and ends at 20:55 BST on Tuesday 13 September 2016. Here is my +1. After this release is done, I'll try and find some time to profile the build & tests - 15 minutes is quite a wait on an SSD (it's possible we might want some multi-threaded options on the tests). Thanks, -- David North | www.dnorth.net >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org >> For additional commands, e-mail: dev-h...@poi.apache.org >> >> > - To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
Re: [VOTE] Apache POI 3.15 (RC2)
I will commit a fix for this today with the goal for backwards compatibility. Here's the plan: getX() returns int getXEnum() returns enum setX(int) setX(enum) I will also take a look at bug 59907 (client anchor enum) On Sep 13, 2016 6:58 AM, "David North"wrote: > Javen, any thoughts on this one? > > On 13/09/16 12:14, Dominik Stadler wrote: > > Hi, > > > > I really hate to delay this further, but unfortunately we have a similar > > problem in class CellValue as we tried to fix in Cell in RC2, the > > getCellType() is now an enum whereas it was an int before, so something > > like the following in user-code does break in POI 3.15: > > > > CellValue cellValue = checkAndGetCellValue(evaluator, sheet, line); > > > > switch (cellValue.getCellType()) { > > case Cell.CELL_TYPE_STRING: > > > > > > I am sorry that I did not see this earlier but this can lead to the same > > incompatibility as we had in Cell before. > > > > Dominik. > > > > On Sun, Sep 11, 2016 at 9:46 PM, David North wrote: > > > >> Hi everyone, > >> > >> My apologies for going AWOL in the middle of the last release attempt. I > >> didn't anticipate that we'd find problems in review twice in a row, and > >> things have been very busy for me at work lately. However, I've now > >> rolled a second RC for 3.15. > >> > >> https://dist.apache.org/repos/dist/dev/poi/3.15-RC2/ > >> > >> Areas to review: > >> > >> * Does it work? > >> * Are the sigs and hashes valid? > >> * Have the issues with the last RC been fixed? > >> * Are the release notes now in good shape? > >> > >> The vote starts now and ends at 20:55 BST on Tuesday 13 September 2016. > >> > >> Here is my +1. > >> > >> After this release is done, I'll try and find some time to profile the > >> build & tests - 15 minutes is quite a wait on an SSD (it's possible we > >> might want some multi-threaded options on the tests). > >> > >> Thanks, > >> > >> -- > >> David North | www.dnorth.net > >> > >> > > > > - > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > For additional commands, e-mail: dev-h...@poi.apache.org > >
Re: [VOTE] Apache POI 3.15 (RC2)
Javen, any thoughts on this one? On 13/09/16 12:14, Dominik Stadler wrote: > Hi, > > I really hate to delay this further, but unfortunately we have a similar > problem in class CellValue as we tried to fix in Cell in RC2, the > getCellType() is now an enum whereas it was an int before, so something > like the following in user-code does break in POI 3.15: > > CellValue cellValue = checkAndGetCellValue(evaluator, sheet, line); > > switch (cellValue.getCellType()) { > case Cell.CELL_TYPE_STRING: > > > I am sorry that I did not see this earlier but this can lead to the same > incompatibility as we had in Cell before. > > Dominik. > > On Sun, Sep 11, 2016 at 9:46 PM, David Northwrote: > >> Hi everyone, >> >> My apologies for going AWOL in the middle of the last release attempt. I >> didn't anticipate that we'd find problems in review twice in a row, and >> things have been very busy for me at work lately. However, I've now >> rolled a second RC for 3.15. >> >> https://dist.apache.org/repos/dist/dev/poi/3.15-RC2/ >> >> Areas to review: >> >> * Does it work? >> * Are the sigs and hashes valid? >> * Have the issues with the last RC been fixed? >> * Are the release notes now in good shape? >> >> The vote starts now and ends at 20:55 BST on Tuesday 13 September 2016. >> >> Here is my +1. >> >> After this release is done, I'll try and find some time to profile the >> build & tests - 15 minutes is quite a wait on an SSD (it's possible we >> might want some multi-threaded options on the tests). >> >> Thanks, >> >> -- >> David North | www.dnorth.net >> >> > - To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
RE: [VOTE] Apache POI 3.15 (RC2)
Kicked off regression tests. Should have results by tomorrow. -Original Message- From: David North [mailto:dno...@apache.org] Sent: Sunday, September 11, 2016 3:47 PM To: POI Developers List <dev@poi.apache.org> Subject: [VOTE] Apache POI 3.15 (RC2) Hi everyone, My apologies for going AWOL in the middle of the last release attempt. I didn't anticipate that we'd find problems in review twice in a row, and things have been very busy for me at work lately. However, I've now rolled a second RC for 3.15. https://dist.apache.org/repos/dist/dev/poi/3.15-RC2/ Areas to review: * Does it work? * Are the sigs and hashes valid? * Have the issues with the last RC been fixed? * Are the release notes now in good shape? The vote starts now and ends at 20:55 BST on Tuesday 13 September 2016. Here is my +1. After this release is done, I'll try and find some time to profile the build & tests - 15 minutes is quite a wait on an SSD (it's possible we might want some multi-threaded options on the tests). Thanks, -- David North | www.dnorth.net
[VOTE] Apache POI 3.15 (RC2)
Hi everyone, My apologies for going AWOL in the middle of the last release attempt. I didn't anticipate that we'd find problems in review twice in a row, and things have been very busy for me at work lately. However, I've now rolled a second RC for 3.15. https://dist.apache.org/repos/dist/dev/poi/3.15-RC2/ Areas to review: * Does it work? * Are the sigs and hashes valid? * Have the issues with the last RC been fixed? * Are the release notes now in good shape? The vote starts now and ends at 20:55 BST on Tuesday 13 September 2016. Here is my +1. After this release is done, I'll try and find some time to profile the build & tests - 15 minutes is quite a wait on an SSD (it's possible we might want some multi-threaded options on the tests). Thanks, -- David North | www.dnorth.net signature.asc Description: OpenPGP digital signature