[Bug 61967] New: Semantic Versioning semver

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=61967

Bug ID: 61967
   Summary: Semantic Versioning semver
   Product: POI
   Version: unspecified
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: POI Overall
  Assignee: dev@poi.apache.org
  Reporter: stefanwendelm...@gmail.com
  Target Milestone: ---

I just updated POI in my Project from 3.5 to 3.17 and got tons of Errors in my
Code.

Is it possible to go for a Semantic Versioning so one could see if the API
changes and is not compatible with the old one anymore?

IMHO the best approach is https://semver.org/

Best regards

Stefan Wendelmann

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[Bug 61967] Semantic Versioning semver

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=61967

PJ Fanning  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from PJ Fanning  ---
The next release is 4.0.0 and we will be using semver.
The policy in the past is that APIs deprecated for the 1st time in say, 3.5,
could be removed in 3.7 or afterwards - ie that they would be retained for 2
releases.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[GitHub] poi pull request #87: Xmlbeans 2.6.3

[pjfanning]

GitHub user pjfanning opened a pull request:

https://github.com/apache/poi/pull/87

Xmlbeans 2.6.3

I'm suggesting that we use xmlbeans fork in POI 4.0.0 while we consider the 
options around replacing xmlbeans or coming up with a better way of maintaining 
xmlbeans.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/pjfanning/poi xmlbeans-2.6.3

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/poi/pull/87.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #87


commit 93fa541ad1acc25d0212716fc649d76ec9caae7e
Author: pj.fanning 
Date:   2018-01-05T16:19:24Z

use xmlbeans fork v2.6.3

commit 8c57f6dcec5b366171caf589d5fe140d45fe97eb
Author: pj.fanning 
Date:   2018-01-05T16:21:04Z

reset groupId for poms that use xmlbeans 2.3.0




---

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

Can't compile EvaluationConditionalFormatRule

[Blake Watson]

When I try to compile EvaluationConditionalFormatRule.java I get an error:

**
Error:(348, 40) java: method isValid in enum
org.apache.poi.ss.formula.EvaluationConditionalFormatRule.OperatorEnum
cannot be applied to given types;
  required: C,C,C
  found: java.lang.Double,java.lang.Double,java.lang.Comparable
  reason: inference variable C has incompatible bounds
equality constraints: java.lang.Double
lower bounds: java.lang.Comparable,java.lang.Double
​**​
​Am I missing a compile switch somewhere? I'm just trying to compile that
particular file from inside IntelliJ.​


-- 

*Blake Watson*

*PNMAC*
Application Development Manager
5898 Condor Drive
Moorpark, CA 93021
(805) 330.4911 x7742
blake.wat...@pnmac.com
www.PennyMacUSA.com 

Re: Can't compile EvaluationConditionalFormatRule

[pj.fanning]

I use IntelliJ and it handles the poi repo well, in my experience.
I allow IntelliJ to use the gradle build and use a Zulu 8 JDK as the SDK.



--
Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

Re: Can't compile EvaluationConditionalFormatRule

[Blake Watson]

I am trying to =just= recompile two classes:
ConditionalFormattingEvaluator, EvaluationConditionalFormatRule. I'm trying
to expose ConditionalFormattingEvaluator.getRules and
EvaluationConditionalFormatRule.matches. I think the latter is the source
of the slowness I'm experiencing.

On Fri, Jan 5, 2018 at 3:03 PM, pj.fanning  wrote:

> I use IntelliJ and it handles the poi repo well, in my experience.
> I allow IntelliJ to use the gradle build and use a Zulu 8 JDK as the SDK.
>
>
>
> --
> Sent from: https://urldefense.proofpoint.com/v2/url?u=http-3A__apache-
> 2Dpoi.1045710.n5.nabble.com_POI-2DDev-2Df2312866.html&d=DwICAg&c=
> dmLomitc30UP5j2qU8E1rg&r=p42pHJHEwFZOHtVFHKJUdL2fYbroN3
> 3stXXb3Psthjw&m=OExuMa3xd_yH4_SVZiaToE0s8nt0Zmeyb-ix5r6oN1U&s=
> 0rB61Zj027i8stAVAhjMIWPzlVubaK49e2oEtLwoN_g&e=
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
> For additional commands, e-mail: dev-h...@poi.apache.org
>
>


-- 

*Blake Watson*

*PNMAC*
Application Development Manager
5898 Condor Drive
Moorpark, CA 93021
(805) 330.4911 x7742
blake.wat...@pnmac.com
www.PennyMacUSA.com 

Re: Can't compile EvaluationConditionalFormatRule

[Greg Woolsey]

Which Java version is your compiler compatibility set to?  POI 4.0 requires
Java 8.

On Fri, Jan 5, 2018 at 3:14 PM Blake Watson  wrote:

> I am trying to =just= recompile two classes:
> ConditionalFormattingEvaluator, EvaluationConditionalFormatRule. I'm trying
> to expose ConditionalFormattingEvaluator.getRules and
> EvaluationConditionalFormatRule.matches. I think the latter is the source
> of the slowness I'm experiencing.
>
> On Fri, Jan 5, 2018 at 3:03 PM, pj.fanning  wrote:
>
> > I use IntelliJ and it handles the poi repo well, in my experience.
> > I allow IntelliJ to use the gradle build and use a Zulu 8 JDK as the SDK.
> >
> >
> >
> > --
> > Sent from: https://urldefense.proofpoint.com/v2/url?u=http-3A__apache-
> > 2Dpoi.1045710.n5.nabble.com_POI-2DDev-2Df2312866.html&d=DwICAg&c=
> > dmLomitc30UP5j2qU8E1rg&r=p42pHJHEwFZOHtVFHKJUdL2fYbroN3
> > 3stXXb3Psthjw&m=OExuMa3xd_yH4_SVZiaToE0s8nt0Zmeyb-ix5r6oN1U&s=
> > 0rB61Zj027i8stAVAhjMIWPzlVubaK49e2oEtLwoN_g&e=
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
> > For additional commands, e-mail: dev-h...@poi.apache.org
> >
> >
>
>
> --
>
> *Blake Watson*
>
> *PNMAC*
> Application Development Manager
> 5898 Condor Drive
> Moorpark, CA 93021
> (805) 330.4911 x7742 <(805)%20330-4911>
> blake.wat...@pnmac.com
> www.PennyMacUSA.com 
>

Re: Can't compile EvaluationConditionalFormatRule

[Greg Woolsey]

for getRules() you can just create your own subclass and override it with a
public version that returns super.getRules()

for matches, I don't see a quick easy way to override.  What rule
definition seems to be slow, and what range does it cover?  There are
definitely some formulas that take longer to evaluate than others -
especially things that do lookups or evaluate over an entire column range.
Could be something else as well.

Right now there is no easy way to shortcut the logic for a range when the
formula is static (has no references relative to the specific range cell
being evaluated, meaning the formula has the same result independent of
"current" range cell).  That kind of optimization hasn't even been
discussed yet, and reliably guaranteeing the code wouldn't miss a case is
probably non-trivial.  Might even make it more expensive than it's worth
unless the range is large and has a large number of non-empty cells.
Patches welcome, of course ;D



On Fri, Jan 5, 2018 at 4:10 PM Greg Woolsey  wrote:

> Which Java version is your compiler compatibility set to?  POI 4.0
> requires Java 8.
>
> On Fri, Jan 5, 2018 at 3:14 PM Blake Watson 
> wrote:
>
>> I am trying to =just= recompile two classes:
>> ConditionalFormattingEvaluator, EvaluationConditionalFormatRule. I'm
>> trying
>> to expose ConditionalFormattingEvaluator.getRules and
>> EvaluationConditionalFormatRule.matches. I think the latter is the source
>> of the slowness I'm experiencing.
>>
>> On Fri, Jan 5, 2018 at 3:03 PM, pj.fanning  wrote:
>>
>> > I use IntelliJ and it handles the poi repo well, in my experience.
>> > I allow IntelliJ to use the gradle build and use a Zulu 8 JDK as the
>> SDK.
>> >
>> >
>> >
>> > --
>> > Sent from: https://urldefense.proofpoint.com/v2/url?u=http-3A__apache-
>> > 2Dpoi.1045710.n5.nabble.com_POI-2DDev-2Df2312866.html&d=DwICAg&c=
>> > dmLomitc30UP5j2qU8E1rg&r=p42pHJHEwFZOHtVFHKJUdL2fYbroN3
>> > 3stXXb3Psthjw&m=OExuMa3xd_yH4_SVZiaToE0s8nt0Zmeyb-ix5r6oN1U&s=
>> > 0rB61Zj027i8stAVAhjMIWPzlVubaK49e2oEtLwoN_g&e=
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
>> > For additional commands, e-mail: dev-h...@poi.apache.org
>> >
>> >
>>
>>
>> --
>>
>> *Blake Watson*
>>
>> *PNMAC*
>> Application Development Manager
>> 5898 Condor Drive
>> Moorpark, CA 93021
>> (805) 330.4911 x7742 <(805)%20330-4911>
>> blake.wat...@pnmac.com
>> www.PennyMacUSA.com 
>>
>

[GitHub] poi pull request #72: Define XDDF user model for shape properties to be shar...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/poi/pull/72


---

-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[Bug 61960] The log said "this error should NEVER happen Please raise a bug", So...

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=61960

Alain Fagot Bearez  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #3 from Alain Fagot Bearez  ---
It seems that your code is closing your workbook inside the while loop. Being
so, on second attempt to get a row from your sheet, the exception is raised
since no reading is allowed from a closed document.

I recommend three actions:
  1. update your dependencies to POI 3.17;
  2. move the two last lines of the while loop outside of the loop;
  3. report about your progress on this ticket.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

[Bug 61959] Provide support to create single slide SlideShow given multi slides SlideShow

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=61959

--- Comment #4 from Alain Fagot Bearez  ---
The alternative would be to copy each slide to a new presentation, by creating
a new slide in the new presentation and importing the content of the original
slide into the newly created slide.
https://poi.apache.org/apidocs/org/apache/poi/xslf/usermodel/XSLFSlide.html#importContent-org.apache.poi.xslf.usermodel.XSLFSheet-

But then you would have to copy the master style sheet and some other details,
from the original presentation to the newly created presentation.

If your slides have charts or notes and you want to copy them along, you would
face bug #57835 for which I implemented only part of the fix: charts in the
same presentation.
https://bz.apache.org/bugzilla/show_bug.cgi?id=57835

Not wanting to scare you, but Nick might have given the path to the solution
with less code to write...

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org

Re: Can't compile EvaluationConditionalFormatRule

[Blake Watson]

On Fri, Jan 5, 2018 at 4:19 PM, Greg Woolsey  wrote:

> for getRules() you can just create your own subclass and override it with a
> public version that returns super.getRules()
>

​That is precisely what I did, yes. And then I hit the matches thing.​

 for matches, I don't see a quick easy way to override.  What rule

> definition seems to be slow, and what range does it cover?  There are
> definitely some formulas that take longer to evaluate than others -
> especially things that do lookups or evaluate over an entire column range.
> Could be something else as well.
>

​Well, I don't know. I'm not working in Java so I was trying to bring as
much as possible into Clojure (in which I am working, to state the
implicitly obvious).


> Right now there is no easy way to shortcut the logic for a range when the
> formula is static (has no references relative to the specific range cell
> being evaluated, meaning the formula has the same result independent of
> "current" range cell).  That kind of optimization hasn't even been
> discussed yet, and reliably guaranteeing the code wouldn't miss a case is
> probably non-trivial.  Might even make it more expensive than it's worth
> unless the range is large and has a large number of non-empty cells.
> Patches welcome, of course ;D


​If I had a set up with profiler working in Java and moved the Clojure code
​into Java I could maybe work out the precise problem but I'm kind of under
the gun on this one. I =am= working on getting a good Java set up and
burnishing my Java skills because I do want to contribute back to POI. That
said, this probably isn't the issue.

I came up with an alternate plan which I had temporarily forgotten in
trying to get all this other stuff to work: Instead of asking each cell
what conditionals apply, asking the sheet about all the conditionals that
apply and getting back a list of those conditionals with the cells
affected . I'm guessing that would be (could be?) a lot faster.

​===Blake===​

Re: Can't compile EvaluationConditionalFormatRule

[Blake Watson]

For completeness purposes, I should say that the language level in IntelliJ
is 8. The JDK in use is 1.8.0_131 which I believe is the official Oracle
release.

And this is line being objected to:

return op != null && op.isValid(val, comp, (Comparable)null);


On Fri, Jan 5, 2018 at 8:05 PM, Blake Watson  wrote:

> On Fri, Jan 5, 2018 at 4:19 PM, Greg Woolsey 
> wrote:
>
>> for getRules() you can just create your own subclass and override it with
>> a
>> public version that returns super.getRules()
>>
>
> ​That is precisely what I did, yes. And then I hit the matches thing.​
>
>  for matches, I don't see a quick easy way to override.  What rule
>
>> definition seems to be slow, and what range does it cover?  There are
>> definitely some formulas that take longer to evaluate than others -
>> especially things that do lookups or evaluate over an entire column range.
>> Could be something else as well.
>>
>
> ​Well, I don't know. I'm not working in Java so I was trying to bring as
> much as possible into Clojure (in which I am working, to state the
> implicitly obvious).
>
>
>> Right now there is no easy way to shortcut the logic for a range when the
>> formula is static (has no references relative to the specific range cell
>> being evaluated, meaning the formula has the same result independent of
>> "current" range cell).  That kind of optimization hasn't even been
>> discussed yet, and reliably guaranteeing the code wouldn't miss a case is
>> probably non-trivial.  Might even make it more expensive than it's worth
>> unless the range is large and has a large number of non-empty cells.
>> Patches welcome, of course ;D
>
>
> ​If I had a set up with profiler working in Java and moved the Clojure
> code ​into Java I could maybe work out the precise problem but I'm kind of
> under the gun on this one. I =am= working on getting a good Java set up and
> burnishing my Java skills because I do want to contribute back to POI. That
> said, this probably isn't the issue.
>
> I came up with an alternate plan which I had temporarily forgotten in
> trying to get all this other stuff to work: Instead of asking each cell
> what conditionals apply, asking the sheet about all the conditionals that
> apply and getting back a list of those conditionals with the cells
> affected . I'm guessing that would be (could be?) a lot faster.
>
> ​===Blake===​
>
>


-- 

*Blake Watson*

*PNMAC*
Application Development Manager
5898 Condor Drive
Moorpark, CA 93021
(805) 330.4911 x7742
blake.wat...@pnmac.com
www.PennyMacUSA.com 

Re: Can't compile EvaluationConditionalFormatRule

[Greg Woolsey]

Looks like I should update my local JDK anyway, it's out of date, I'll see
what that says Monday.

As for asking the conditional rules what cells they cover, and then only
checking those cells, that may be faster.  I tried to have it fail fast if
the cell in question is not in a range covered by a rule, but perhaps there
is more to it than that.  I've seen some interesting performance things pop
up when digging into POI execution timing in the past, wouldn't surprise me
to find out there is room for optimization somewhere in this part too.

On Fri, Jan 5, 2018 at 8:29 PM Blake Watson  wrote:

> For completeness purposes, I should say that the language level in IntelliJ
> is 8. The JDK in use is 1.8.0_131 which I believe is the official Oracle
> release.
>
> And this is line being objected to:
>
> return op != null && op.isValid(val, comp, (Comparable)null);
>
>
> On Fri, Jan 5, 2018 at 8:05 PM, Blake Watson 
> wrote:
>
> > On Fri, Jan 5, 2018 at 4:19 PM, Greg Woolsey 
> > wrote:
> >
> >> for getRules() you can just create your own subclass and override it
> with
> >> a
> >> public version that returns super.getRules()
> >>
> >
> > ​That is precisely what I did, yes. And then I hit the matches thing.​
> >
> >  for matches, I don't see a quick easy way to override.  What rule
> >
> >> definition seems to be slow, and what range does it cover?  There are
> >> definitely some formulas that take longer to evaluate than others -
> >> especially things that do lookups or evaluate over an entire column
> range.
> >> Could be something else as well.
> >>
> >
> > ​Well, I don't know. I'm not working in Java so I was trying to bring as
> > much as possible into Clojure (in which I am working, to state the
> > implicitly obvious).
> >
> >
> >> Right now there is no easy way to shortcut the logic for a range when
> the
> >> formula is static (has no references relative to the specific range cell
> >> being evaluated, meaning the formula has the same result independent of
> >> "current" range cell).  That kind of optimization hasn't even been
> >> discussed yet, and reliably guaranteeing the code wouldn't miss a case
> is
> >> probably non-trivial.  Might even make it more expensive than it's worth
> >> unless the range is large and has a large number of non-empty cells.
> >> Patches welcome, of course ;D
> >
> >
> > ​If I had a set up with profiler working in Java and moved the Clojure
> > code ​into Java I could maybe work out the precise problem but I'm kind
> of
> > under the gun on this one. I =am= working on getting a good Java set up
> and
> > burnishing my Java skills because I do want to contribute back to POI.
> That
> > said, this probably isn't the issue.
> >
> > I came up with an alternate plan which I had temporarily forgotten in
> > trying to get all this other stuff to work: Instead of asking each cell
> > what conditionals apply, asking the sheet about all the conditionals that
> > apply and getting back a list of those conditionals with the cells
> > affected . I'm guessing that would be (could be?) a lot faster.
> >
> > ​===Blake===​
> >
> >
>
>
> --
>
> *Blake Watson*
>
> *PNMAC*
> Application Development Manager
> 5898 Condor Drive
> Moorpark, CA 93021
> (805) 330.4911 x7742 <(805)%20330-4911>
> blake.wat...@pnmac.com
> www.PennyMacUSA.com 
>