Re: xmlbeans 3.0.2 release?

[Javen O'Neal]

+1

On Wed, Sep 26, 2018, 14:53 pj.fanning  wrote:

> Should we do an XMLBeans 3.0.2 release?
>
>
> https://issues.apache.org/jira/browse/XMLBEANS-520?jql=project%20%3D%20XMLBEANS%20AND%20fixVersion%20%3D%20%22Version%203.0.2%22
>
>
>
> --
> 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: [RESULT] [VOTE] Apache POI 4.0.0 release (RC1)

[Javen O'Neal]

Congrats on the release!

Re: POI 4.0.0 in bugzilla

[Javen O'Neal]

Just to verify (I'm in agreement), by disabling 3.17-FINAL from new bugs,
that means we are discontinuing support for the 3.17 code branch. If we
need to create a bug against 3.17 for a security update, we'll need to ask
Nick to temporarily allow new bugs for 3.17-FINAL. In a pinch (Nick is
busy), the unspecified tag is still available.

Any users choosing to stay on 3.x will be implicitly discouraged from
contributing patches and code snippets on bz.apache.org for each other,
since they'll have to use the unspecified tag. Here I'm acknowledging that
our bugzilla isn't always used by contributors to get a dev to upstream
their change, but sometimes to provide a quick fix for another user or to
post an idea that requires elaboration to become committable.

Sounds fair to me.

On Thu, Sep 6, 2018, 13:20 Andreas Beeker  wrote:

> On 9/6/18 8:27 PM, Nick Burch wrote:
> >
> > I've gone for
> >  * 4.0.0-FINAL
> >  * 4.0.x-dev
> >
> > Hopefully that makes sense, sorts well, and ought to be fairly easy to
> maintain?
>
> +1 ... thank you
>
> Andi
>
>
>

Re: Remove OPOIFSFileSystem for 4.0.0?

[Javen O'Neal]

+1.
How many lines of code can we delete by removing this class?

Re: Remove Spanish translation?

[Javen O'Neal]

+1

Wrong documentation < No documentation

Re: Use forrest 0.9?

[Javen O'Neal]

+1

Re: Adding a function or two...

[Javen O'Neal]

HSSF and SS Common tests live here:
https://svn.apache.org/viewvc/poi/trunk/src/testcases/org/apache/poi/

XSSF and SS Common tests live here:
https://svn.apache.org/viewvc/poi/trunk/src/ooxml/testcases/org/apache/poi/

We separated the tests because HSSF code is compiled and tested without
providing ooxml-schema.jar or poi-ooxml-schema.jar on the class path. This
way we can guarantee that poi.jar doesn't require ooxml as a dependency, to
keep projects small where they're only using the binary formats.

On Tue, Mar 27, 2018, 20:09 Blake Watson  wrote:

> I was just scouring the whole project for XSSFWorkbook and not finding
> nearly as much as I thought.
>
> How does one properly add to functionMetaData.txt?
>
> On Tue, Mar 27, 2018 at 6:38 PM, Greg Woolsey 
> wrote:
>
> > Tests in that package are run in a context without the xssf code. Xssf
> > specific tests need to go in a different location. I don't have it on my
> > phone, but some searching should reveal them, the naming conventions are
> > strong.
> >
> > On Tue, Mar 27, 2018, 17:45 Blake Watson  wrote:
> >
> > > The tests seem to be mostly HSSF based. Is that right? (I guess it
> > > shouldn't matter?)
> > >
> > > On Mon, Mar 26, 2018 at 9:45 AM, Blake Watson 
> > > wrote:
> > >
> > > > Yeah, I was gonna use the Git.
> > > >
> > > > On Sun, Mar 25, 2018 at 11:04 PM, Dominik Stadler <
> > > dominik.stad...@gmx.at>
> > > > wrote:
> > > >
> > > >> Hi,
> > > >>
> > > >> Tests are part of the published sources in separate directories
> under
> > > >> "src", for functions mostly under "src/testsources", e.g.
> > > >> src/testcases/org/apache/poi/ss/formula/functions seems a good place
> > for
> > > >> unit-tests that cover specific functions.
> > > >>
> > > >> Maybe also good if you use either the SVN or Git repository
> directly,
> > > then
> > > >> it is easier to contribute changes as patch or pull-request.
> > > >>
> > > >> See https://urldefense.proofpoint.com/v2/url?u=http-3A__poi.apac
> > > >> he.org_subversion.html=DwIBaQ=dmLomitc30UP5j2qU8E1rg=p
> > > >> 42pHJHEwFZOHtVFHKJUdL2fYbroN33stXXb3Psthjw=1DnAqaPgydsOffy
> > > >> pXYLDcv8KsRHlBIdBDu0cTZj2ve0=X2uDFTHTp5eWfrHJql4lFvqbKN_g
> > > >> LO7ywUomDopdFrs= and
> > > >> https://urldefense.proofpoint.com/v2/url?u=http-3A__poi.apac
> > > >> he.org_howtobuild.html=DwIBaQ=dmLomitc30UP5j2qU8E1rg=p
> > > >> 42pHJHEwFZOHtVFHKJUdL2fYbroN33stXXb3Psthjw=1DnAqaPgydsOffy
> > > >> pXYLDcv8KsRHlBIdBDu0cTZj2ve0=5Y3qC-4XYROiktL9qO-JjkVJMUqN
> > > >> 87GDNNpu7RkO50Q= for working with the code,
> > > >>
> > > >> Thanks... Dominik.
> > > >>
> > > >>
> > > >>
> > > >> On Sat, Mar 24, 2018 at 1:56 AM, Blake Watson <
> blake.wat...@pnmac.com
> > >
> > > >> wrote:
> > > >>
> > > >> > I was going to try adding functions to POI (IFNA seems like a
> likely
> > > >> first
> > > >> > shot). I've imported the sources from the ZIP (NetBeans) and I can
> > > build
> > > >> > and run tests. But I don't see where the source code for the tests
> > is.
> > > >> (I
> > > >> > assume I start with the tests...)
> > > >> >
> > > >> > Also open to any suggestions for...whatever.
> > > >> > --
> > > >> >
> > > >> > *Blake Watson*
> > > >> >
> > > >> > *PNMAC*
> > > >> > Application Development Manager
> > > >> > 5898 Condor Drive
> > > >> > Moorpark, CA 93021
> > > >> > (805) 330.4911 x7742
> > > >> > blake.wat...@pnmac.com
> > > >> > www.PennyMacUSA.com 
> > > >> >
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > >
> > > > *Blake Watson*
> > > >
> > > > *PNMAC*
> > > > Application Development Manager
> > > > 5898 Condor Drive
> > > > Moorpark, CA 93021
> > > > (805) 330.4911 x7742
> > > > blake.wat...@pnmac.com
> > > > www.PennyMacUSA.com 
> > > >
> > >
> > >
> > >
> > > --
> > >
> > > *Blake Watson*
> > >
> > > *PNMAC*
> > > Application Development Manager
> > > 5898 Condor Drive
> > > Moorpark, CA 93021
> > > (805) 330.4911 x7742
> > > blake.wat...@pnmac.com
> > > www.PennyMacUSA.com 
> > >
> >
>
>
>
> --
>
> *Blake Watson*
>
> *PNMAC*
> Application Development Manager
> 5898 Condor Drive
> Moorpark, CA 93021
> (805) 330.4911 x7742
> blake.wat...@pnmac.com
> www.PennyMacUSA.com 
>

Re: publishing poi xmlbeans jars

[Javen O'Neal]

+1 sending it back to Incubator or subproject of Commons.

+0.9 as a subproject of POI.

Would prefer Xmlbeans to have its own PMC to make it easier for other
Apache devs to make changes, but given how stable/mature it is, the support
volume should be low.

If/when POI does replace XMLBeans for a more memory efficient/faster XML
library, it'd be awkward for our PMC to manage a product we don't use. We
can move it out to incubator, attic, or put it up for adoption when that
time comes.

As long as the board doesn't have reservations about us subprojecting
XMLBeans and then making another change in a couple years, I'm fine with
taking XMLBeans as a subproject of POI.

On Thu, Mar 8, 2018, 10:50 Dominik Stadler  wrote:

> +1
>
> On Wed, Mar 7, 2018 at 11:20 PM, pj.fanning  wrote:
>
> > +1
> >
> >
> >
> > --
> > 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: Tests that create documents without closing them

[Javen O'Neal]

Yes.. many tests were written without closing the document.

Some tests close documents outside of a finally statement and thus won't
close the document if the unit test fails.

When the JVM exits, it should close any open resources that the unit tests
failed to close. This would be really bad for production code where the JVM
may run continuously, but hasn't been a big deal for test code. Every line
of test code that doesn't directly relate to what's being tested could be
viewed as noise, but I'm in favor of unit tests properly closing resources
since the unit tests also serve as a reference implementation/quick guide
for users of our library, and proper resource management should be used
whenever possible.

Feel free to fix the resource leaks in the unit tests as you discover them.
Even if done without proper try/finally or try-with-resources/finally.

On Feb 11, 2018 14:11, "Mark Murphy"  wrote:

> Has anyone noticed that we have a lot of test cases that create documents
> without closing them when they are complete? Does this happen automatically
> somehow, and I just missed it, or are we using up a lot of memory by
> keeping documents open?
>

RE: XMLBeans in 4.0.0 release

[Javen O'Neal]

Bringing xmlbeans out of the attic is my vote.

I can be one of the Xmlbeans PMCs if all we are missing is a head count and
a couple emails to infra.

I don't see taking Xmlbeans out of the attic as a huge support burden. It's
a stable, complete product and any future development is probably just
small bug fixes. As long as infra is okay with that philosophy, removing
Xmlbeans from the attic causes the least confusion for everyone, and may
reduce our support load for POI and Tika when users can't get xmlbeans
working (even if all it is is linking to the FAQ and PJ's GitHub).

Every email we receive probably was the result of 8 hours of struggling to
diagnose the problem in their build setup, and several others who gave up
without contacting us.

On Jan 11, 2018 05:02, "Murphy, Mark"  wrote:

> If we are going to take on maintenance of XMLBeans, I would suggest that
> getting it out of the attic would be the most appropriate course of action.
> This would reduce confusion for people trying to find XML Beans as there
> would only be a single project to reference rather than one in the attic
> and another in the POI project.
>
> -Original Message-
> From: Nick Burch [mailto:apa...@gagravarr.org]
> Sent: Thursday, January 11, 2018 12:59 AM
> To: POI Developers List 
> Subject: Re: XMLBeans in 4.0.0 release
>
> On Wed, 10 Jan 2018, pj.fanning wrote:
> > I don't fancy trying to merge the xmlbeans and poi ant builds. I've
> > been trying for an hour or more and still getting issues.
>
> There's no need to do this!
>
> We'd keep the two codebases separate, and probably release at different
> times. (XMLBeans hardly ever, except when we find bugs) All that would
> happen is that we'd swap the group ID, add POI to the release names, and
> update the readme etc to refer to POI as the PMC providing the oversight
>
> So, assuming we're releasing it as POI rather than getting it out of the
> attic:
>   * Copy xmlbeans trunk in svn to
> https://svn.apache.org/repos/asf/poi/xmlbeans/trunk
>   * Merge in the fixes
>   * Update the bin/src packages to have poi in them, eg
> xmlbeans-poi-2.6.5-bin.zip
>   * Update the poms to be under org.apache.poi rather than xmlbeans
>   * Test, vote, release!
>
> Or, if we want to take xmlbeans out of the attic, we'd do:
>   * Vote to take it on
>   * Wait for attic PMC to confirm
>   * Get infra to unlock svn for xmlbeans
>   * Merge in fixes
>   * Test, vote, release!
>
> Nick
>
> -
> 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: classloading xsbs for pptx

[Javen O'Neal]

> Should we do this at the Tika level or at the Solr level...or, longer
term, should we do this within POI?

Definitely POI. CTTable is an implementation detail of POI that we should
avoid leaking to outside libraries--even Tika.

On Nov 28, 2017 09:03, "Allison, Timothy B."  wrote:

All,

  We have a report that Tika's integration with Solr is now failing proper
classloading on a pptx with a CTTable that can't be loaded [1].
The error message suggests doing something like this: POIXMLTypeLoader.
setClassLoader(CTTable.class.getClassLoader()).  Is this the right fix?
Should we do this at the Tika level or at the Solr level...or, longer term,
should we do this within POI?

Thank you!

   Best,

Tim

[1] https://issues.apache.org/jira/browse/TIKA-2497

Re: [GitHub] poi pull request #68: Share chart data implementation between XSSFChart and ...

[Javen O'Neal]

Once you've closed out a bug, you can add the change to the 4.0.0 changelog
here:
https://svn.apache.org/viewvc/poi/site/src/documentation/content/xdocs/status.xml?view=log

If you install Apache Ant 1.8+ and Apache Forrest 0.6.*, you can rebuild
the HTML site with these changes.

Re: svn commit: r1815988 - /poi/trunk/src/java/org/apache/poi/ss/format/CellDateFormatter.java

[Javen O'Neal]

The result of

> LocaleUtil.getUserLocale()

should be stored in a local variable at the beginning of the method to
reduce the number of get calls, as well as producing inconsistent results
if the user locale is modified while formatting a cell value.

The UserLocale currently uses per-thread storage so I don't think it's
possible to modify while formatting a cell value, but this would be a
strange problem to debug if the implementation changed.

On Nov 21, 2017 13:11,  wrote:

Author: fanningpj
Date: Tue Nov 21 21:11:07 2017
New Revision: 1815988

URL: http://svn.apache.org/viewvc?rev=1815988=rev
Log:
remove more uses of Character.toUpperCase

Modified:
poi/trunk/src/java/org/apache/poi/ss/format/CellDateFormatter.java

Modified: poi/trunk/src/java/org/apache/poi/ss/format/CellDateFormatter.java
URL: http://svn.apache.org/viewvc/poi/trunk/src/java/org/apache/
poi/ss/format/CellDateFormatter.java?rev=1815988=1815987=1815988&
view=diff

==
--- poi/trunk/src/java/org/apache/poi/ss/format/CellDateFormatter.java
(original)
+++ poi/trunk/src/java/org/apache/poi/ss/format/CellDateFormatter.java Tue
Nov 21 21:11:07 2017
@@ -181,7 +181,6 @@ public class CellDateFormatter extends C
 boolean doneAm = false;
 boolean doneMillis = false;

-it.first();
 for (char ch = it.first();
  ch != CharacterIterator.DONE;
  ch = it.next()) {
@@ -189,12 +188,9 @@ public class CellDateFormatter extends C
 if (!doneMillis) {
 Date dateObj = (Date) value;
 int pos = toAppendTo.length();
-Formatter formatter = new Formatter(toAppendTo,
Locale.ROOT);
-try {
+try (Formatter formatter = new Formatter(toAppendTo,
Locale.ROOT)) {
 long msecs = dateObj.getTime() % 1000;
 formatter.format(locale, sFmt, msecs / 1000.0);
-} finally {
-formatter.close();
 }
 toAppendTo.delete(pos, pos + 2);
 doneMillis = true;
@@ -203,11 +199,11 @@ public class CellDateFormatter extends C
 if (!doneAm) {
 if (showAmPm) {
 if (amPmUpper) {
-toAppendTo.append(Character.toUpperCase(ch));
+toAppendTo.append(Character.
toString(ch).toUpperCase(LocaleUtil.getUserLocale()));
 if (showM)
 toAppendTo.append('M');
 } else {
-toAppendTo.append(Character.toLowerCase(ch));
+toAppendTo.append(Character.
toString(ch).toLowerCase(LocaleUtil.getUserLocale()));
 if (showM)
 toAppendTo.append('m');
 }



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

Re: svn commit: r1815994 - in /poi/trunk/src: java/org/apache/poi/sl/usermodel/ java/org/apache/poi/ss/format/ java/org/apache/poi/util/ ooxml/java/org/apache/poi/xssf/usermodel/helpers/ resources/dev

[Javen O'Neal]

Should we be lower-casing and switching on codepoints rather than the first
character if a string can contain multiple-byte symbols?


Modified: poi/trunk/src/java/org/apache/poi/ss/format/CellFormatPart.java
URL: http://svn.apache.org/viewvc/poi/trunk/src/java/org/apache/
poi/ss/format/CellFormatPart.java?rev=1815994=1815993&
r2=1815994=diff

==
--- poi/trunk/src/java/org/apache/poi/ss/format/CellFormatPart.java
(original)
+++ poi/trunk/src/java/org/apache/poi/ss/format/CellFormatPart.java Tue Nov
21 22:10:48 2017
@@ -18,6 +18,7 @@ package org.apache.poi.ss.format;

 import org.apache.poi.hssf.util.HSSFColor;
 import org.apache.poi.util.LocaleUtil;
+import org.apache.poi.util.StringUtil;

 import javax.swing.*;

@@ -341,7 +342,7 @@ public class CellFormatPart {
 char c1 = repl.charAt(0);
 char c2 = 0;
 if (repl.length() > 1)
-c2 = Character.toLowerCase(repl.charAt(1));
+c2 = StringUtil.toLowerCase(repl.charAt(1)).charAt(0);

 switch (c1) {
 case '@':

Re: svn commit: r1815953 - /poi/site/src/documentation/content/xdocs/overview.xml

[Javen O'Neal]

Does this library version bump need to be reflected in the changelog?

On Nov 21, 2017 08:29,  wrote:

> Author: centic
> Date: Tue Nov 21 16:29:24 2017
> New Revision: 1815953
>
> URL: http://svn.apache.org/viewvc?rev=1815953=rev
> Log:
> Adjust version of commons-codec in docu pages as well
>
> Modified:
> poi/site/src/documentation/content/xdocs/overview.xml
>
> Modified: poi/site/src/documentation/content/xdocs/overview.xml
> URL: http://svn.apache.org/viewvc/poi/site/src/documentation/
> content/xdocs/overview.xml?rev=1815953=1815952=1815953=diff
> 
> ==
> --- poi/site/src/documentation/content/xdocs/overview.xml (original)
> +++ poi/site/src/documentation/content/xdocs/overview.xml Tue Nov 21
> 16:29:24 2017
> @@ -292,7 +292,7 @@
>  
>poi
>https://search.maven.
> org/#artifactdetails|commons-logging|commons-logging|1.2|jar
> ">commons-logging,
> -  https://search.maven.
> org/#artifactdetails|commons-codec|commons-codec|1.10|jar">
> commons-codec,
> +  https://search.maven.
> org/#artifactdetails|commons-codec|commons-codec|1.11|jar">
> commons-codec,
>https://search.maven.org/#artifactdetails|org.
> apache.commons|commons-collections4|4.1|jar">commons-collections
> (since POI 3.15 beta 3),
>https://search.maven.org/#artifactdetails|org.
> apache.commons|commons-math3|3.6.1|jar">commons-math (since POI
> 4.0.0),
>https://search.maven.
> org/#artifactdetails|log4j|log4j|1.2.17|bundle">log4j
>
>
>
> -
> To unsubscribe, e-mail: commits-unsubscr...@poi.apache.org
> For additional commands, e-mail: commits-h...@poi.apache.org
>
>

Re: Financial support to implement bar chart functionality

[Javen O'Neal]

Which POi modules do you need chart support for? Just XSSF?

There are some improvements in the pipeline. Not sure if it meets your
needs though.
https://github.com/apache/poi/pull/68

On Nov 20, 2017 02:27, "gmu...@gmail.com"  wrote:

Dear POI devs,

I love Apache POI and have been using it for quite a while now.

I am currently in need of a bar chart functionality in POI, just like Line
Charts and Scatter Charts, which are already available.
I would like to hire someone to develop this, but I am not sure this is the
best place.

I would not mind helping the team financially to further improve the chart
functionalities within Apache POI.

Could you please contact me to negotiate this, or indicate me the best
place to get this started?
I would not like to hire any dev who has never worked on POI or with OOXML
before, as this would probably be too expensive.

Thanks for the excellent work and regards,
Guilherme

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

Re: Charts

[Javen O'Neal]

Alain Béarez has contributed several pull requests for a common
charting API between XSSF and XSLF via github-68 [1] and github-72 [2]
that need a signed contributor license agreement before merging. The
CLA is in progress.

Sandeep Tiwari recently opened bug 61745 with a patch for XWPF. This
is a smaller patch that probably doesn't require a CLA (code submitted
to POI devs for inclusion in POI is implicitly ASL 2.0 licensed unless
stated otherwise). I don't think this change conflicts with Alain's
work. If someone is interested in using XDDF in XWPF, that work can be
done after this patch is committed.

[1] https://github.com/apache/poi/pull/68
[2] https://github.com/apache/poi/pull/72
[3] https://bz.apache.org/bugzilla/show_bug.cgi?id=61745

On Sat, Nov 11, 2017 at 2:11 PM, Mark Murphy  wrote:
> I think I have heard of a charting effort in progress for POI, I am hoping
> that is in a common module, at least for the XML formats so that we don't
> have to copy it to each of the document types. Can someone let me know how
> that is going? I have a patch for XWPF, and I want to make sure it doesn't
> conflict with the way that effort is handling things.

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

Re: [DISCUSS] Getting a fixed version of XMLBeans

[Javen O'Neal]

Dave Fisher's (e) seems like the best fix to me. Not everyone needs the
XMLBeans fixes, so we shouldn't force it on them in order to update to the
latest version of POI.

Changing the java package name from org.apache.xmlbeans would break
compatibility with XMLBeans 2.3.0 and 2.6.0, as well as any private forks
people maintain that use the org.apache.xmlbeans package namespace.

If the board is open to it, the least effort solution is to commit the
changes to XMLBeans's repo l, make a release, and update the website
without pulling it out of the Attic. If we can't get around the Apache's
policies requiring non-Attic status to commit or release, then we could
pull XMLBeans out of the Attic just long enough to form a PMC, commit,
release, vote, and update website, then put it back into the attic.

I don't see the changes we need to make to XMLBeans as specific to POI--the
same bugs would affect other projects running on Android. We aren't aware
of what those other projects might be. I don't think that's enough reason
to make a POI-specific XMLBeans release or to copy the source tree inside
of POI.

I haven't had any issues using POI with XMLBeans for my applications, so my
opinions probably don't hold as much weight as those who have been affected
by the bugs.

On Nov 9, 2017 15:43, "Andreas Beeker"  wrote:

Hi,

I would prefer c) but keeping the package names and only change the
artifact groupid,
to keep it's proprietary usage for POI. So we don't need to care to build
up a xmlbeans
community again.

I think d) is a longterm goal - to simulate xmlbeans xml infoset
preservation plus
support various ECMA versions plus handling alternate content blocks
correctly
will be a challenge in a brown field context.
Therefore we should first fix xmlbeans.

Andi


On 11/9/17 10:01 PM, Dominik Stadler wrote:

Hi,

the initial discussion showed a few possible routes. I would like to
discuss the options a bit more, probably followed by a vote to see which
option has the majority.

I currently see the following possibilities:

a) Fork XMLBeans with a different name outside of Apache and upload a fixed
version, just like PJ already did, only some more renaming would probably
be necessary

b) Include the source of XMLBeans with POI and release fixes from there

c) As b), but change the code so different package names and jar-names are
used to avoid colliding with the "official" version

d) Do nothing with XMLBeans and invest all the time for replacing XMLBeans
soon

Any thoughts? Other options?

Thanks... Dominik.

Re: Non-maintainer upload of bugfixes for the XMLBeans library in the Attic

[Javen O'Neal]

Any other project using XMLBeans on Android would likely be affected by the
same issue. Making the XMLBeans update within the POI source code or POI
maven coordinates would make it more difficult for others to find this
update.

If we had to change the Java package name to
org.apache.poi.internal.xmlbeans, it would take a bit of trickery to allow
users to continue using the official releases, XMLBeans 2.3.0 or 2.6.0 if
the bug doesn't affect them.

On Nov 7, 2017 03:41, "sebb"  wrote:

On 7 November 2017 at 07:20, jan iversen  wrote:
>
>
> Sent from my iPad
>
>> On 6 Nov 2017, at 21:47, Dominik Stadler  wrote:
>>
>> Hi,
>>
>> The Apache XMLBeans library was moved to the Attic a few years ago
>> (05/2014), however Apache POI still uses the library as it's core XML
>> binding framework.
>>
>> While the Apache POI PMC and the development community is already
>> discussing possible replacements for some time, use of XMLBeans is still
>> deeply rooted and thus hard to replace quickly.
>>
>> Over time, we discovered a few grave bugs in XMLBeans which lead to
>> bug-reports that we cannot fix ourselves.
>>
>> Therefore we would like to start discussion about an NMU of XMLBeans to
get
>> a fix for the most pressing issues.
>>
>> See https://bz.apache.org/bugzilla/show_bug.cgi?id=59268 for the full
>> discussion,and https://github.com/pjfanning/xmlbeans for a fork with
>> initial bugfixes.
>>
>> Among others, we would like to fix the following, changes for these are
>> already applied and verified in the github fork:
>> * the official XMLBeans-JAR contains duplicate classes, making it
>> impossible to use it on Android as the Android build fails due to this
>> * cannot use Unicode surogates, thus affecting use of Apache POI in
>> non-latin-script areas
>> * Remove W3C and JAVAX classes which are not needed any more since Java 6
>> (current Apache POI development is on Java 8)
>>
>>
>> So is there a precedent for something like this? What steps do we need to
>> make to get an updated version of XMLBeans published?
>
> Others might have examples of how it was done in the past. Making a fork
on e.g. github with a new non-apache name is the simplest way.
>
> However if I understand it correct your intention is only to maintain
XMLbeans for the benefit of POI. That gives you (as I see it) another
option, you can include the source code in your project and do the patches
as part of your project.

I think it would need to be in a different package to avoid possible
confusion with the original.
And it should be obvious that it is not intended for external use.

e.g. org.apache.poi.internal.xmlbeans

> rgds
> jan i
>>
>>
>> Thanks... Dominik
>>
>> On behalf of the Apache POI PMC
>>
>>
>> About Apache POI
>> ---
>>
>> Apache POI is well-known in the Java field as a library for reading and
>> writing Microsoft Office file formats, such as Excel, PowerPoint, Word,
>> Visio, Publisher and Outlook. It supports both the older (OLE2) and
>> new (OOXML - Office Open XML) formats.
>>
>> See https://poi.apache.org/ for more details

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

Re: jaxb problems

[Javen O'Neal]

If the schemas aren't backwards compatible and we have CT* classes in the
XSSF classes, then wouldn't that mean that we'd need to dynamically import
the CT classes and reload the XSSF classes with the correct schema at
runtime?

This sounds tricky.

On Oct 22, 2017 02:30, "Andreas Beeker"  wrote:

> Hi *,
>
> I'm struggling with jaxb and the ecma v5 schemas for quite a while - maybe
> you could have a look at [1].
>
> My idea is to have several ecma version available in parallel and decide
> which to use after some
> introspection of a given ooxml file - AFAIK the versions are not downward
> compatible.
> Additionally my goal is to have the internal model saved as
> (serializable?) dom fragments
> or even strings, so you could use some kind of mmap list to handle big
> files.
> For reading the data you wouldn't need a schema, but for writing (and
> respecting the element order) I think there's
> no feasible method apart of xml binding, which would be applied on the fly
> on changed elements.
>
> So feel free to also suggest a different approach not only for the jaxb
> problem.
>
> Andi
>
>
> [1] https://stackoverflow.com/q/46869482
>
>
>

Re: [GitHub] poi pull request #79: Remove the method invocation of toString on a string.

[Javen O'Neal]

Looks like all of the String.toString() calls have been removed. I added
this to the forbidden APIs list in r1812239 to eliminate this problem from
recurring.

On Oct 15, 2017 17:42, "Javen O'Neal" <one...@apache.org> wrote:

We can probably add String.toString() to forbidden APIs to make sure there
aren't other usages of String.toString and that this stays fixed in the
future. Even if String.toString gets compiled out and therefore doesn't
affect library performance,  it could be confusing for someone reading the
code.

Are there any reasons to keep String.toString() usages? Perhaps
String.toString(Locale).

On Oct 15, 2017 13:34, "asfgit" <g...@git.apache.org> wrote:

> Github user asfgit closed the pull request at:
>
> https://github.com/apache/poi/pull/79
>
>
> ---
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
> For additional commands, e-mail: dev-h...@poi.apache.org
>
>

Re: [GitHub] poi pull request #79: Remove the method invocation of toString on a string.

[Javen O'Neal]

We can probably add String.toString() to forbidden APIs to make sure there
aren't other usages of String.toString and that this stays fixed in the
future. Even if String.toString gets compiled out and therefore doesn't
affect library performance,  it could be confusing for someone reading the
code.

Are there any reasons to keep String.toString() usages? Perhaps
String.toString(Locale).

On Oct 15, 2017 13:34, "asfgit"  wrote:

> Github user asfgit closed the pull request at:
>
> https://github.com/apache/poi/pull/79
>
>
> ---
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
> For additional commands, e-mail: dev-h...@poi.apache.org
>
>

Re: Apache POI 4.0/Java 8

[Javen O'Neal]

Are we following the guidelines of http://semver.org? If so, should we
declare that (possibly in the 4.0.0 release notes)?

Semver.org specifies that adding any deprecation warning would need to be
done in a minor release and any removal of a deprecated feature be done in
a major release.

This is a departure from our deprecate+2 releases rule for removing
features.

There are enough bits of the API worth changing that I think we'll be
spinning through major versions.

If we strictly follow semver.org, we'll need to bump the major version for
any backwards incompatible change, even if it's in scratchpad or some other
volatile module. At the same time, anyone using a module that isn't
actively developed, like hdgf, won't benefit from semantic versioning to
know that there weren't any backwards incompatible changes to hdgf from
4.0.0 to 5.0.0. How do we want to manage this? Maintaining different
package versions for each module sounds like a nightmare for devs and users
alike. Do we rely on bugzilla and the changelog to convey this information,
as well as our API Check build?


On Sep 16, 2017 18:47, "pj.fanning"  wrote:

I agree with Andi about using 4.0.0-SNAPSHOT as the release number.
I'd like to make regular 4.0.x releases and to have 4.y release on a similar
cadence to the existing 3.z releases (2 or so a year).



--
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: Apache POI 4.0/Java 8

[Javen O'Neal]

Yes, and our @deprecated messages should be using the new semantic
versioning 4.0.0.

On Sep 15, 2017 4:06 AM, "Allison, Timothy B."  wrote:

Thank you, Dominik!!!

So, speaking of 4.0...should we move to semantic versioning: 4.0.0?

-Original Message-
From: Dominik Stadler [mailto:dominik.stad...@gmx.at]
Sent: Thursday, September 14, 2017 1:39 PM
To: POI Developers List 
Subject: Apache POI 4.0/Java 8

Hi,

FYI, as 3.17 is out and we agreed to work on 4.0/Java 8 now, I have done a
bunch of changes locally which switch to Java 8 and 4.0 and also use some
newer third party libs. I would like to do some more local testing on it
and then commit it tomorrow.

Just FYI so we don't duplicate efforts here.

Dominik.

Re: [VOTE] Apache POI 3.17 release (RC2)

[Javen O'Neal]

Github-69 would be worth reviewing and committing if we're going to do an
RC3.

On Aug 30, 2017 10:44, "Greg Woolsey"  wrote:

> I would like an RC3 (sorry, I know this is a fair bit of work) to pick
> up r1806623
> fixing bug 61468, as I consider that a rather serious calculation bug, and
> will likely cause a couple months' delay in my attempts to get
> Vaadin-Spreadsheet updated to use the new conditional formatting and table
> style APIs I've added to POI.
>
> I won't vote -1 yet, though. If others need this released now, I'm open to
> a conversation about the timing of a 3.18 release.
>
> On Mon, Aug 28, 2017 at 2:38 PM Andreas Beeker 
> wrote:
>
> > Hi *,
> >
> > I've prepared artifacts for the release of Apache POI 3.17 (RC2).
> >
> > The most notable changes in this release are:
> >
> > - Various modules: add sanity checks and fix infinite loops / OOMs
> caused by fuzzed data
> > - OPC: fix linebreak handling on XML signature calculation (#61182)
> > - SS Common: fix number formatting (github-43/52, #60422)
> > - SXSSF: fix XML processing - unicode surrogates and line breaks
> (#61048, #61246)
> > https://dist.apache.org/repos/dist/dev/poi/3.17-RC2/ <
> https://dist.apache.org/repos/dist/dev/poi/3.17-RC1/>
> >
> > I'll add the summary to the change log on releasing the artifacts.
> >
> > Please vote to release the artifacts.
> > The vote keeps open for 72hrs, 2017-09-01, 23:59 UTC,
> > planned release announcement date is Monday, 2017-09-04.
> >
> > Here is my +1
> >
> > Andi
> >
> >
>

RE: POI 4.0 and Java 8

[Javen O'Neal]

Other stakeholders we should ping?

> Vaadin, if they're on Java 6 or 7.

On Aug 28, 2017 8:50 AM, "Allison, Timothy B."  wrote:

Thank you, David!

Anyone with contacts at/works for Alfresco?

Other stakeholders we should ping?

From: David Pilato [mailto:da...@pilato.fr]
Sent: Monday, August 28, 2017 10:27 AM
To: d...@tika.apache.org; Allison, Timothy B. 
Cc: POI Developers List 
Subject: RE: POI 4.0 and Java 8

Nope. Elasticsearch does not support 1.7 anymore in 5.x, 6.x and master
branch.

+1 to switch to 1.8.

--
David Pilato, elastic.co
Developer | Evangelist, [X]

Le 28 août 2017 à 15:14 +0200, Allison, Timothy B. >, a écrit :

+1 from me.

David, any problems with ES if Tika migrates to jdk8?

-Original Message-
From: Konstantin Gribov [mailto:gros...@gmail.com]
Sent: Wednesday, August 23, 2017 1:11 PM
To: d...@tika.apache.org
Cc: POI Developers List  wrote:


Hi Tika devs,

at POI, we are about to have a major change in the upcoming version
after POI 3.17 is out, which will be probably in the next week or so.

Up till now we had a discussion [1], about the next Java SE, i.e. Java
7 or 8, and it looks like Java 8 is the preferred version - with the
restriction on how you'll get along with that decision.

In an ideal world you would say, ok we switch to Java 8 too, but I
guess this won't happen ...
at least not so fast.

To continue the discussion, I could try to gather a few arguments why
it would make sense to switch, but in the end you also have upstream
dependencies to check for, e.g. elasticsearch [2].

So I would choose a different approach...:
- do you have any plans to switch to Java 8? when would that be?
- if we decide to go on, how much of an impact would that be for Tika (...
to rely on an older POI version)?
- any recommendations? maybe something like a mixed versions jar

Thank you,
Andi

[1]
http://apache-poi.1045710.n5.nabble.com/Discussions-on-POI-4-0-Java7-8
-voting-td5728560.html
[2]
https://www.elastic.co/guide/en/elasticsearch/reference/current/setup.
html


--

Best regards,
Konstantin Gribov

Re: Discussions on POI 4.0 / Java7/8 voting

[Javen O'Neal]

a) 4.0
b) JDK8
c) yes, of course.
d) +1 for sematic versioning.

On Aug 21, 2017 09:40, "pj.fanning"  wrote:

> My votes are:
>
> a) 4.0
> b) JDK8 (if Tika team agrees to upgrade)
> c) yes
> d) semver
>
>
>
> --
> View this message in context: http://apache-poi.1045710.n5.
> nabble.com/Discussions-on-POI-4-0-Java7-8-voting-tp5728560p5728566.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.17 release (RC1)

[Javen O'Neal]

Let's leave this vote open until Dominik and/or Tim can run tests against
our corpus and Tika.

If this is the last Java 6-compatible release, let's make it a good one.

On Aug 21, 2017 3:43 PM, "Andreas Beeker"  wrote:

> Hi,
>
> I've prepared artifacts for the release of Apache POI 3.17 (RC1).
>
> The most notable changes in this release are:
>
> - Various modules: add sanity checks and fix infinite loops / OOMs caused
> by fuzzed data
> - OPC: fix linebreak handling on XML signature calculation (#61182)
> - SS Common: fix number formatting (github-43/52, #60422)
> - SXSSF: fix XML processing - unicode surrogates and line breaks (#61048,
> #61246)
>
> https://dist.apache.org/repos/dist/dev/poi/3.17-RC1/
>
> All tests pass. ASC files verify and MD5/SHA1 are correct. Docs look fine.
> I'll add the summary to the change log on releasing the artifacts.
>
> Please vote to release the artifacts.
> The vote keeps open for 72hrs, 2017-08-25, 23:59 UTC,
> planned release announcement date is Saturday, 2017-08-27.
>
> Here is my +1
>
> Andi
>
>
>

Re: Discussions on POI 4.0 / Java7/8 voting

[Javen O'Neal]

a) 4.0
b) JDK8
c) yes, of course.

How many releases into the 4.x series will we allow for API breaks? If we
need to make all of our API changes by the time 4.0 final releases, then we
might have a few more 4.0 betas than other releases (and probably wouldn't
be ready for 4.0 final until Q2 2018).

On Sun, Aug 20, 2017 at 4:06 PM, Andreas Beeker 
wrote:

> Hi,
>
> I'd like to add a note to the final announcement about the JDK change and
> link a vote thread to it.
>
> We've discussed about Java 7 [4], but as a few projects around us already
> have
> switched to Java 8 [1], I want an official vote about Java 7/8.
> As I anticipate a bit of controversy on this, I want to discuss first and
> then
> have a separate vote thread to be linked to from the announcement.
>
> Up till now I have 3 questions to vote -
> is there anything else, we should vote on for version 4.0?
> For the sake of simplicity, they aren't in the -1/0/1 response format.
>
>
> a) Is the next version 4.0 or do we have a 3.18?
> b) Which will be the next Java SE 7 or 8?
>
> The guidelines [2] are actually clear about this, but I'll ask that anyway:
> c) Will you join an opposing majority?
>
>
> Here are my votes:
> a) 4.0
> b) JDK8
> c) yes
>
>
> Regarding b)
> As we have a major break here and Java 7 is already at EOL [3], I'd like to
> use the opportunity to fast forward. When I look through a few
> rendering/AWT
> related bugs which occur in Java 6, I often see those are only fixed in
> Java 8.
> I have the impression, that dependent libraries/products either are
> dependent on
> older features and therefore can stick with 3.17 ... or they have already a
> current Java 8 compatible version out.
>
> To make up you mind, check [5] for a different stance on EOL/upgrading.
> For a quantitative list of POI dependencies check [6]
>
> Andi
>
>
> [1]
> http://ant.apache.org/antnews.html#Apache Ant 1.9.8 and 1.10.0
> http://apache-xml-project.6118.n7.nabble.com/Java-2-1-0-
> release-td43800.html
> [2] https://www.apache.org/foundation/voting.html
> [3] http://www.oracle.com/technetwork/java/eol-135779.html
> [4] http://apache-poi.1045710.n5.nabble.com/Java-6-support-td5721373.html
> [5] https://spring.io/blog/2015/04/01/ongoing-support-for-
> java-7-and-even-java-6
> [6] https://github.com/centic9/github-version-statistics
>
>
>

Re: XDDF implementation shared between XSSFChart and XSLFChart

[Javen O'Neal]

That sounds like a good compromise.

On Aug 11, 2017 04:18, "pj.fanning"  wrote:

> Would it be feasible to keep the existing classes and APIs and have them
> delegate to the XDDF impl?
> We could immediately deprecate any of these legacy APIs.
>
>
>
> --
> View this message in context: http://apache-poi.1045710.n5.
> nabble.com/XDDF-implementation-shared-between-XSSFChart-and-XSLFChart-
> tp5728473p5728476.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: Table Formula Manipulation and Matrix Function Implementation in HSSF/XSSF

[Javen O'Neal]

At 2.2MB and with more projects using better dependency resolvers (Gradle),
I'm less worried about this hurting adoption.

On Jul 26, 2017 11:58, "Greg Woolsey" <greg.wool...@gmail.com> wrote:

> The runtime JARs for Commons Math are 2.2MB, the rest of the release
> package is source and docs.  If users really need the minimum required
> packaging, they can use something like Maven Shade [1].
>
> I like the idea of running tests without this dependency and just skipping
> tests that need it.
>
> Perhaps we could use an annotation to identify tests to skip in a
> particular run, so we don't need to maintain a master list?
>
> 1. https://maven.apache.org/plugins/maven-shade-plugin/
>
> On Wed, Jul 26, 2017 at 11:20 AM Javen O'Neal <javenon...@gmail.com>
> wrote:
>
> > +1 to Apache Commons Math.
> >
> > Can we write tests to verify that this dependency is only needed for
> > certain packages? I hope I'm wrong, but 20 MB is large enough that some
> > people may not want to update to newer versions of POI.
> >
> > On Jul 26, 2017 10:28 AM, "Greg Woolsey" <greg.wool...@gmail.com> wrote:
> >
> > > We aren't averse to dependency changes, we did one in the past year.
> My
> > > personal preference is the Commons Math library, as it is also an
> Apache
> > > project and more importantly still under active development.  JAMA
> > appears
> > > dead, and calls itself a straw-man implementation.
> > >
> > > We could note that if a user doesn't need Excel matrix function
> > evaluation
> > > they would not need to include that library at run time.  Until we
> start
> > > using the Commons Math functionality for more stuff :)
> > >
> > > Actually, there are likely statistical functions we could implement
> using
> > > it as well, among others.
> > >
> > > On Wed, Jul 26, 2017 at 9:18 AM Robert Hulbert <bob951...@gmail.com>
> > > wrote:
> > >
> > > > Following up, there are two external Matrix Libraries that I am
> > familiar
> > > > with (JAMA and Commons.Math3.Linear). Both of these libraries provide
> > all
> > > > the functionality necessary to emulate the Excel Matrix
> functionality.
> > > The
> > > > Linear library is 2MB and JAMA is ~20KB. I understand this would be
> > > adding
> > > > a dependency to the project. Is there a preference on which library
> > would
> > > > be used or is the preferred solution to implement the functionality
> > > > directly in POI?
> > > >
> > > > On 2017-06-27 15:51 (-0700), "Javen O'Neal" <one...@apache.org>
> wrote:
> > > > > Greg Woolsey has provided quite a few improvements on Table support
> > for
> > > > > XSSF recently (last 6-12 months).
> > > > >
> > > > > Question to the devs: Are tables part of the XLS binary file
> format,
> > > and
> > > > if
> > > > > so are users interested in a common SS Table interface?
> > > > >
> > > > > Question to Robert: Is LLNL particularly interested in using POI to
> > > read
> > > > > and write workbooks containing tables and matrix (table or array?)
> > > > > functions? Or were they more interested in having an intern help
> out
> > on
> > > > an
> > > > > open source project and table support was one idea they had?
> > > > >
> > > > >
> > > > > On Jun 27, 2017 1:01 PM, "Hulbert, Robert Douglas" <
> > hulbe...@llnl.gov>
> > > > > wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > I'm a summer student at Lawrence Livermore National Laboratory and
> > was
> > > > > hired to find or implement POI's table formulas and matrix
> functions.
> > > > >
> > > > > Over the last week or so, I have checked the POI page/Contributor
> > > > > guidelines and have looked through the source code for handling
> this
> > > > > functionality.
> > > > >
> > > > > Is anyone still interested in this functionality? If not, is there
> > any
> > > > > documentation on where this aspect left off?
> > > > >
> > > > > Thank you so much for any help you can give!
> > > > >
> > > > > Best Regards,
> > > > > Robert Hulbert
> > > > >
> > > >
> > > > 
> -
> > > > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
> > > > For additional commands, e-mail: dev-h...@poi.apache.org
> > > >
> > > >
> > >
> >
>

Re: Table Formula Manipulation and Matrix Function Implementation in HSSF/XSSF

[Javen O'Neal]

+1 to Apache Commons Math.

Can we write tests to verify that this dependency is only needed for
certain packages? I hope I'm wrong, but 20 MB is large enough that some
people may not want to update to newer versions of POI.

On Jul 26, 2017 10:28 AM, "Greg Woolsey" <greg.wool...@gmail.com> wrote:

> We aren't averse to dependency changes, we did one in the past year.  My
> personal preference is the Commons Math library, as it is also an Apache
> project and more importantly still under active development.  JAMA appears
> dead, and calls itself a straw-man implementation.
>
> We could note that if a user doesn't need Excel matrix function evaluation
> they would not need to include that library at run time.  Until we start
> using the Commons Math functionality for more stuff :)
>
> Actually, there are likely statistical functions we could implement using
> it as well, among others.
>
> On Wed, Jul 26, 2017 at 9:18 AM Robert Hulbert <bob951...@gmail.com>
> wrote:
>
> > Following up, there are two external Matrix Libraries that I am familiar
> > with (JAMA and Commons.Math3.Linear). Both of these libraries provide all
> > the functionality necessary to emulate the Excel Matrix functionality.
> The
> > Linear library is 2MB and JAMA is ~20KB. I understand this would be
> adding
> > a dependency to the project. Is there a preference on which library would
> > be used or is the preferred solution to implement the functionality
> > directly in POI?
> >
> > On 2017-06-27 15:51 (-0700), "Javen O'Neal" <one...@apache.org> wrote:
> > > Greg Woolsey has provided quite a few improvements on Table support for
> > > XSSF recently (last 6-12 months).
> > >
> > > Question to the devs: Are tables part of the XLS binary file format,
> and
> > if
> > > so are users interested in a common SS Table interface?
> > >
> > > Question to Robert: Is LLNL particularly interested in using POI to
> read
> > > and write workbooks containing tables and matrix (table or array?)
> > > functions? Or were they more interested in having an intern help out on
> > an
> > > open source project and table support was one idea they had?
> > >
> > >
> > > On Jun 27, 2017 1:01 PM, "Hulbert, Robert Douglas" <hulbe...@llnl.gov>
> > > wrote:
> > >
> > > Hi,
> > >
> > > I'm a summer student at Lawrence Livermore National Laboratory and was
> > > hired to find or implement POI's table formulas and matrix functions.
> > >
> > > Over the last week or so, I have checked the POI page/Contributor
> > > guidelines and have looked through the source code for handling this
> > > functionality.
> > >
> > > Is anyone still interested in this functionality? If not, is there any
> > > documentation on where this aspect left off?
> > >
> > > Thank you so much for any help you can give!
> > >
> > > Best Regards,
> > > Robert Hulbert
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
> > For additional commands, e-mail: dev-h...@poi.apache.org
> >
> >
>

Re: svn commit: r1801806 - in /poi/trunk/src/ooxml: java/org/apache/poi/xssf/streaming/SXSSFWorkbook.java java/org/apache/poi/xssf/streaming/SheetDataWriter.java testcases/org/apache/poi/xssf/streamin

[Javen O'Neal]

I like the idea of using XML-specific startElement, endElement, and
writeAttribute functions so that the code doesn't get littered with angle
brackets, quotes, and escaping attributes that contain quotes, ampersands,
and other characters.

I think Java will convert "a"+"b"+"c" into
StringBuilder("a").append("b").append("c").toString() during the
compilation process, so we probably don't need to make those replacements
unless they improve readability.

On Jul 13, 2017 12:14 AM,  wrote:

> Author: fanningpj
> Date: Thu Jul 13 07:14:01 2017
> New Revision: 1801806
>
> URL: http://svn.apache.org/viewvc?rev=1801806=rev
> Log:
> avoid unnecessary string concats in SXSSF SheetDataWriter
>
> Modified:
> poi/trunk/src/ooxml/java/org/apache/poi/xssf/streaming/
> SXSSFWorkbook.java
> poi/trunk/src/ooxml/java/org/apache/poi/xssf/streaming/
> SheetDataWriter.java
> poi/trunk/src/ooxml/testcases/org/apache/poi/xssf/streaming/
> TestSXSSFWorkbook.java
>
> Modified: poi/trunk/src/ooxml/java/org/apache/poi/xssf/streaming/
> SXSSFWorkbook.java
> URL: http://svn.apache.org/viewvc/poi/trunk/src/ooxml/java/org/
> apache/poi/xssf/streaming/SXSSFWorkbook.java?rev=
> 1801806=1801805=1801806=diff
> 
> ==
> --- poi/trunk/src/ooxml/java/org/apache/poi/xssf/streaming/SXSSFWorkbook.java
> (original)
> +++ poi/trunk/src/ooxml/java/org/apache/poi/xssf/streaming/SXSSFWorkbook.java
> Thu Jul 13 07:14:01 2017
> @@ -406,7 +406,7 @@ public class SXSSFWorkbook implements Wo
>  }
>
>  private static void copyStreamAndInjectWorksheet(InputStream in,
> OutputStream out, InputStream worksheetData) throws IOException {
> -InputStreamReader inReader=new InputStreamReader(in,"UTF-8");
> //TODO: Is it always UTF-8 or do we need to read the xml encoding
> declaration in the file? If not, we should perhaps use a SAX reader instead.
> +InputStreamReader inReader=new InputStreamReader(in,"UTF-8");
>  OutputStreamWriter outWriter=new OutputStreamWriter(out,"UTF-8");
>  boolean needsStartTag = true;
>  int c;
>
> Modified: poi/trunk/src/ooxml/java/org/apache/poi/xssf/streaming/
> SheetDataWriter.java
> URL: http://svn.apache.org/viewvc/poi/trunk/src/ooxml/java/org/
> apache/poi/xssf/streaming/SheetDataWriter.java?rev=
> 1801806=1801805=1801806=diff
> 
> ==
> --- 
> poi/trunk/src/ooxml/java/org/apache/poi/xssf/streaming/SheetDataWriter.java
> (original)
> +++ 
> poi/trunk/src/ooxml/java/org/apache/poi/xssf/streaming/SheetDataWriter.java
> Thu Jul 13 07:14:01 2017
> @@ -207,23 +207,27 @@ public class SheetDataWriter implements
>  }
>
>  void beginRow(int rownum, SXSSFRow row) throws IOException {
> -_out.write(" -if (row.hasCustomHeight())
> -_out.write(" customHeight=\"true\"  ht=\"" +
> row.getHeightInPoints() + "\"");
> -if (row.getZeroHeight())
> -_out.write(" hidden=\"true\"");
> +_out.write(" +writeAttribute("r", Integer.toString(rownum + 1));
> +if (row.hasCustomHeight()) {
> +writeAttribute("customHeight", "true");
> +writeAttribute("ht", Float.toString(row.
> getHeightInPoints()));
> +}
> +if (row.getZeroHeight()) {
> +writeAttribute("hidden", "true");
> +}
>  if (row.isFormatted()) {
> -_out.write(" s=\"" + row.getRowStyleIndex() + "\"");
> -_out.write(" customFormat=\"1\"");
> +writeAttribute("s", Integer.toString(row.
> getRowStyleIndex()));
> +writeAttribute("customFormat", "1");
>  }
>  if (row.getOutlineLevel() != 0) {
> -_out.write(" outlineLevel=\"" + row.getOutlineLevel() + "\"");
> +writeAttribute("outlineLevel", Integer.toString(row.
> getOutlineLevel()));
>  }
>  if(row.getHidden() != null) {
> -_out.write(" hidden=\"" + (row.getHidden() ? "1" : "0") +
> "\"");
> +writeAttribute("hidden", row.getHidden() ? "1" : "0");
>  }
>  if(row.getCollapsed() != null) {
> -_out.write(" collapsed=\"" + (row.getCollapsed() ? "1" : "0")
> + "\"");
> +writeAttribute("collapsed", row.getCollapsed() ? "1" : "0");
>  }
>
>  _out.write(">\n");
> @@ -239,30 +243,32 @@ public class SheetDataWriter implements
>  return;
>  }
>  String ref = new CellReference(_rownum,
> columnIndex).formatAsString();
> -_out.write(" +_out.write(" +writeAttribute("r", ref);
>  CellStyle cellStyle = cell.getCellStyle();
>  if (cellStyle.getIndex() != 0) {
>  // need to convert the short to unsigned short as the indexes
> can be up to 64k
>  // ideally we would use int for this index, but that would
> need changes to 

Re: Java 6 support

[Javen O'Neal]

> My 2 cents is that we could continue to support a 3.x branch and backport
security fixes and fixes that would be generally useful to a wide community.

I could get behind back porting security fixes since they're fairly
infrequent and small.

Fully maintaining a branch would get tricky as the code bases diverge and
merge. We already have a bandwidth problem with 1 code base. I'd rather
spend my energy on improving what we have than keeping two trees in sync.
Furthermore I think the audience for a 3.x branch is fairly small. Users
stuck on Java 6 (read: large companies) are less likely to upgrade to new
versions of POI, especially as we keep evolving the API.

> As part of a possible 4.0 release, we should review the deprecated code to
try and prune as much as possible.

Agreed. With all the enum enhancements, CellType is one that's so engrained
on our quick guide, on mailing lists, stack overflow questions and answers,
and elsewhere that Nick suggested we wait til 4.0 to change
Cell.getCellType() to return a CellType enum. Most of the rest of the enums
added in the last few releases are less heavily found in 3rd party code
that it was safe to do:
1. Add getXEnum() and deprecate getX()
2. Wait 2 releases
3. Change getX() to return an enum, deprecate getXEnum()
4. Wait 2 releases
5. Delete getXEnum().
See Bug 59836 https://bz.apache.org/bugzilla/show_bug.cgi?id=59836

On Jul 9, 2017 19:13, "pj.fanning"  wrote:

I favour more regular non-beta releases generally and like the idea of a 4.0
release.
I'm pretty neutral on the JRE version support. My employers mandate JRE 1.8
usage and I think, for security reasons, this is the right approach.
My 2 cents is that we could continue to support a 3.x branch and backport
security fixes and fixes that would be generally useful to a wide community.
As part of a possible 4.0 release, we should review the deprecated code to
try and prune as much as possible.



--
View this message in context: http://apache-poi.1045710.n5.
nabble.com/Java-6-support-tp5721373p5728121.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: Java 6 support

[Javen O'Neal]

Then let's kick XMLBeans to POI 5.0 and drop Java 6 ASAP if it's preventing
Java 9 support.

Java 9 is just around the corner (July 27).

We should aim to support Java 9 the day it's released so we're not a reason
for other software projects to delay Java 9 adoption.

Have we addressed the open issues with POI 3.17 beta 1 that we'd be
comfortable with a 3.17 final release?

We could make 3.17 final and 4.0 nearly identical, released the same day or
a few days apart, with the only difference being dropping Java 6
compatibility and adding Java 9 compatibility.

On Jul 9, 2017 5:47 PM, "Andreas Beeker"  wrote:

> +1 for switching now or after POI 3.17 ... if we will do a 3.17 final
> soonish.
>
> I'm actually bringing this up, as I was facing again problems with
> generics bugs in Java 6 and independently had a devops discussion with
> fluxo yesterday, questioning me/us why we are still on Java 6 level.
>
> > If we're talking about POI 4.0, we should also think about replacing
> > XMLBeans, since that can't be done gradually like refactoring the code to
> > use Java 7 language features.
>
> Switching to Java 7 is probably just a declarative issue in the beginning
> and we gradually upgrade the source in the releases afterwards - I don't
> see a XmlBeans replacement coming so soon and we shouldn't pack to many
> changes in version 4.0. Furthermore I don't think replacing XMLBeans can be
> done gradually - at least this should happen module-wise in my point of
> view.
>
> I also wouldn't spend any time to think about Java 6 mitigations - as the
> long term support is running out for most customers - at least that's what
> happened to my last project in a quite update-reluctant company with a IBM
> java environment.
>
> Andi
>
>
>

Re: svn commit: r1801373 - in /poi/trunk/src: java/org/apache/poi/sl/usermodel/ ooxml/testcases/org/apache/poi/sl/

[Javen O'Neal]

Is this a bug in the JVM implementation or are self-referential generics
not allowed per the Java 6 language spec?

Are our jenkins slaves using the latest version of Java 6?

Looks like Java 6 and 9 support are mutually exclusive here. Time to drop
Java 6 support.

On Jul 9, 2017 5:27 PM,  wrote:

> Author: kiwiwings
> Date: Sun Jul  9 15:27:29 2017
> New Revision: 1801373
>
> URL: http://svn.apache.org/viewvc?rev=1801373=rev
> Log:
> Rollback of r1801368 because of a generics bug with self-referenced types
> in Java6
>
> Modified:
> poi/trunk/src/java/org/apache/poi/sl/usermodel/AutoShape.java
> poi/trunk/src/java/org/apache/poi/sl/usermodel/Background.java
> poi/trunk/src/java/org/apache/poi/sl/usermodel/ConnectorShape.java
> poi/trunk/src/java/org/apache/poi/sl/usermodel/FreeformShape.java
> poi/trunk/src/java/org/apache/poi/sl/usermodel/GraphicalFrame.java
> poi/trunk/src/java/org/apache/poi/sl/usermodel/GroupShape.java
> poi/trunk/src/java/org/apache/poi/sl/usermodel/Hyperlink.java
> poi/trunk/src/java/org/apache/poi/sl/usermodel/Line.java
> poi/trunk/src/java/org/apache/poi/sl/usermodel/MasterSheet.java
> poi/trunk/src/java/org/apache/poi/sl/usermodel/Notes.java
> poi/trunk/src/java/org/apache/poi/sl/usermodel/PictureShape.java
> poi/trunk/src/java/org/apache/poi/sl/usermodel/PlaceableShape.java
> poi/trunk/src/java/org/apache/poi/sl/usermodel/Shadow.java
> poi/trunk/src/java/org/apache/poi/sl/usermodel/Shape.java
> poi/trunk/src/java/org/apache/poi/sl/usermodel/ShapeContainer.java
> poi/trunk/src/java/org/apache/poi/sl/usermodel/Sheet.java
> poi/trunk/src/java/org/apache/poi/sl/usermodel/SimpleShape.java
> poi/trunk/src/java/org/apache/poi/sl/usermodel/Slide.java
> poi/trunk/src/java/org/apache/poi/sl/usermodel/SlideShow.java
> poi/trunk/src/java/org/apache/poi/sl/usermodel/TableCell.java
> poi/trunk/src/java/org/apache/poi/sl/usermodel/TableShape.java
> poi/trunk/src/java/org/apache/poi/sl/usermodel/TextBox.java
> poi/trunk/src/java/org/apache/poi/sl/usermodel/TextShape.java
> poi/trunk/src/ooxml/testcases/org/apache/poi/sl/TestFonts.java
>
> Modified: poi/trunk/src/java/org/apache/poi/sl/usermodel/AutoShape.java
> URL: http://svn.apache.org/viewvc/poi/trunk/src/java/org/apache/
> poi/sl/usermodel/AutoShape.java?rev=1801373=1801372&
> r2=1801373=diff
> 
> ==
> --- poi/trunk/src/java/org/apache/poi/sl/usermodel/AutoShape.java
> (original)
> +++ poi/trunk/src/java/org/apache/poi/sl/usermodel/AutoShape.java Sun
> Jul  9 15:27:29 2017
> @@ -19,6 +19,6 @@ package org.apache.poi.sl.usermodel;
>
>  public interface AutoShape<
>  S extends Shape,
> -P extends TextParagraph
> +P extends TextParagraph
>  > extends TextShape {
>  }
>
> Modified: poi/trunk/src/java/org/apache/poi/sl/usermodel/Background.java
> URL: http://svn.apache.org/viewvc/poi/trunk/src/java/org/apache/
> poi/sl/usermodel/Background.java?rev=1801373=1801372&
> r2=1801373=diff
> 
> ==
> --- poi/trunk/src/java/org/apache/poi/sl/usermodel/Background.java
> (original)
> +++ poi/trunk/src/java/org/apache/poi/sl/usermodel/Background.java Sun
> Jul  9 15:27:29 2017
> @@ -19,7 +19,7 @@ package org.apache.poi.sl.usermodel;
>
>  public interface Background<
>  S extends Shape,
> -P extends TextParagraph
> +P extends TextParagraph
>  > extends Shape {
>  FillStyle getFillStyle();
>  }
>
> Modified: poi/trunk/src/java/org/apache/poi/sl/usermodel/
> ConnectorShape.java
> URL: http://svn.apache.org/viewvc/poi/trunk/src/java/org/apache/
> poi/sl/usermodel/ConnectorShape.java?rev=1801373=1801372=1801373&
> view=diff
> 
> ==
> --- poi/trunk/src/java/org/apache/poi/sl/usermodel/ConnectorShape.java
> (original)
> +++ poi/trunk/src/java/org/apache/poi/sl/usermodel/ConnectorShape.java
> Sun Jul  9 15:27:29 2017
> @@ -19,7 +19,7 @@ package org.apache.poi.sl.usermodel;
>
>  public interface ConnectorShape<
>  S extends Shape,
> -P extends TextParagraph
> +P extends TextParagraph
>  > extends SimpleShape {
>
>  }
>
> Modified: poi/trunk/src/java/org/apache/poi/sl/usermodel/
> FreeformShape.java
> URL: http://svn.apache.org/viewvc/poi/trunk/src/java/org/apache/
> poi/sl/usermodel/FreeformShape.java?rev=1801373=1801372=1801373&
> view=diff
> 
> ==
> --- poi/trunk/src/java/org/apache/poi/sl/usermodel/FreeformShape.java
> (original)
> +++ poi/trunk/src/java/org/apache/poi/sl/usermodel/FreeformShape.java Sun
> Jul  9 15:27:29 2017
> @@ -21,7 +21,7 @@ import java.awt.geom.Path2D;
>
>  public 

Re: Java 6 support

[Javen O'Neal]

The Android dev team have been making progress on Java 8 support, including
3rd party libraries, though currently still is a subset of the full Java 8
language specification.

There will be more problems with Android API level <=23 (Marshmallow and
older).

https://developer.android.com/studio/write/java8-support.html

On Jul 9, 2017 16:29, "Dominik Stadler" <dominik.stad...@gmx.at> wrote:

> Hi,
>
> +1 for Java 7 in POI 4 after 3.17 is out. And I for not investing too much
> in backwards compatibility, people on Java 6 likely still run POI 3.9
> anyway.
>
> I'm -1 on Java 8, as 7 is still needed for Android AFAIK and we get a
> number of requests in that area lately.
>
> Dominik
>
> On Jul 9, 2017 16:10, "Javen O'Neal" <one...@apache.org> wrote:
>
> > (writing an iterator in Java is particularly painful).
> We could also leapfrog Java 7 and go straight to Java 8 with support for
> streams and lambdas.
>
> And yes, it's a can of worms to try to compile Java 7/8 source to Java 6
> bytecode. It shouldn't be, as that's one of the glorious things about
> intermediate code, and somehow Kotlin and other languages managed to
> compile to Java 6 bytecode...
> https://stackoverflow.com/questions/22610400/a-program-
> made-with-java-8-can-be-run-on-java-7
>
> On Jul 9, 2017 15:48, "Javen O'Neal" <one...@apache.org> wrote:
>
> +1
>
> I'm in favor of dropping Java 6 support. If users still need to run new
> versions of POI on old JVMs, they should be able to cross-compile, though
> it may require some extra tools on their end to modify the bytecode to be
> compatible with and old JVM.
>
> If we can figure out a way to maintain binary compatibility with Java 6
> while rewriting our code with features from Java 7 (diamond operator for
> inferred generic type, try-with-resources, Unicode literals), then it's a
> no-brainer.
>
> If cross compilation doesn't work, I was toying with the idea of rewriting
> parts of the code in Kotlin, Scala, or other static JVM language that
> maintains Java 6 compatibility while providing a less verbose language to
> write code in (writing an iterator in Java is particularly painful).
>
> If we're talking about POI 4.0, we should also think about replacing
> XMLBeans, since that can't be done gradually like refactoring the code to
> use Java 7 language features.
>
> Either before or after we replace XMLBeans, it'd be worthwhile to fully
> read files into POJOs so we don't have to keep an XMLDOM open. This is why
> we struggle with RAM and CPU performance.
>
> I'm not sure if it's easier to replace XMLBeans before de-XMLDOM'ing POI
> (assuming we want that), but it's worth discussing as we look at the
> roadmap of dependent tasks to move forward.
>
> Of course, if we're not ready to embark on replacing XMLBeans and
> de-XMLDOM, we can drop Java 6 support in POI 4 and work on removing
> XMLBeans and the XMLDOM in POI 5 (or 6).
>
> On Jul 9, 2017 14:29, "kiwiwings" <kiwiwi...@apache.org> wrote:
>
> It has been a while that we've discussed this topic ... or at least I
> couldn't find another more recent/decent thread ... [1]
>
> How about switching to Java 7 now?
> If we'd do, will we change to version 4 then?
>
> Andi
>
>
>
> [1] http://apache-poi.1045710.n5.nabble.com/Java-6-support-td5721373.html
>
>
>
> --
> View this message in context: http://apache-poi.1045710.n5.n
> abble.com/Java-6-support-tp5721373p5728102.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: Java 6 support

[Javen O'Neal]

> (writing an iterator in Java is particularly painful).
We could also leapfrog Java 7 and go straight to Java 8 with support for
streams and lambdas.

And yes, it's a can of worms to try to compile Java 7/8 source to Java 6
bytecode. It shouldn't be, as that's one of the glorious things about
intermediate code, and somehow Kotlin and other languages managed to
compile to Java 6 bytecode...
https://stackoverflow.com/questions/22610400/a-program-made-with-java-8-can-be-run-on-java-7

On Jul 9, 2017 15:48, "Javen O'Neal" <one...@apache.org> wrote:

+1

I'm in favor of dropping Java 6 support. If users still need to run new
versions of POI on old JVMs, they should be able to cross-compile, though
it may require some extra tools on their end to modify the bytecode to be
compatible with and old JVM.

If we can figure out a way to maintain binary compatibility with Java 6
while rewriting our code with features from Java 7 (diamond operator for
inferred generic type, try-with-resources, Unicode literals), then it's a
no-brainer.

If cross compilation doesn't work, I was toying with the idea of rewriting
parts of the code in Kotlin, Scala, or other static JVM language that
maintains Java 6 compatibility while providing a less verbose language to
write code in (writing an iterator in Java is particularly painful).

If we're talking about POI 4.0, we should also think about replacing
XMLBeans, since that can't be done gradually like refactoring the code to
use Java 7 language features.

Either before or after we replace XMLBeans, it'd be worthwhile to fully
read files into POJOs so we don't have to keep an XMLDOM open. This is why
we struggle with RAM and CPU performance.

I'm not sure if it's easier to replace XMLBeans before de-XMLDOM'ing POI
(assuming we want that), but it's worth discussing as we look at the
roadmap of dependent tasks to move forward.

Of course, if we're not ready to embark on replacing XMLBeans and
de-XMLDOM, we can drop Java 6 support in POI 4 and work on removing
XMLBeans and the XMLDOM in POI 5 (or 6).

On Jul 9, 2017 14:29, "kiwiwings" <kiwiwi...@apache.org> wrote:

It has been a while that we've discussed this topic ... or at least I
couldn't find another more recent/decent thread ... [1]

How about switching to Java 7 now?
If we'd do, will we change to version 4 then?

Andi



[1] http://apache-poi.1045710.n5.nabble.com/Java-6-support-td5721373.html



--
View this message in context: http://apache-poi.1045710.n5.n
abble.com/Java-6-support-tp5721373p5728102.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: Java 6 support

[Javen O'Neal]

+1

I'm in favor of dropping Java 6 support. If users still need to run new
versions of POI on old JVMs, they should be able to cross-compile, though
it may require some extra tools on their end to modify the bytecode to be
compatible with and old JVM.

If we can figure out a way to maintain binary compatibility with Java 6
while rewriting our code with features from Java 7 (diamond operator for
inferred generic type, try-with-resources, Unicode literals), then it's a
no-brainer.

If cross compilation doesn't work, I was toying with the idea of rewriting
parts of the code in Kotlin, Scala, or other static JVM language that
maintains Java 6 compatibility while providing a less verbose language to
write code in (writing an iterator in Java is particularly painful).

If we're talking about POI 4.0, we should also think about replacing
XMLBeans, since that can't be done gradually like refactoring the code to
use Java 7 language features.

Either before or after we replace XMLBeans, it'd be worthwhile to fully
read files into POJOs so we don't have to keep an XMLDOM open. This is why
we struggle with RAM and CPU performance.

I'm not sure if it's easier to replace XMLBeans before de-XMLDOM'ing POI
(assuming we want that), but it's worth discussing as we look at the
roadmap of dependent tasks to move forward.

Of course, if we're not ready to embark on replacing XMLBeans and
de-XMLDOM, we can drop Java 6 support in POI 4 and work on removing
XMLBeans and the XMLDOM in POI 5 (or 6).

On Jul 9, 2017 14:29, "kiwiwings"  wrote:

It has been a while that we've discussed this topic ... or at least I
couldn't find another more recent/decent thread ... [1]

How about switching to Java 7 now?
If we'd do, will we change to version 4 then?

Andi



[1] http://apache-poi.1045710.n5.nabble.com/Java-6-support-td5721373.html



--
View this message in context: http://apache-poi.1045710.n5.
nabble.com/Java-6-support-tp5721373p5728102.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

Fwd: Re: [apache/poi] Trailing commas custom formats (#56)

[Javen O'Neal]

Luca has a question about PR #56 on GitHub. Seems relevant to some of the
recent internationalization work. Anyone more familiar with the subject
care to chime in on the GitHub PR?

-- Forwarded message --
From: "Luca Martini" 
Date: Jul 3, 2017 03:52
Subject: Re: [apache/poi] Trailing commas custom formats (#56)
To: "apache/poi" 
Cc: "onealj" , "Mention" 

*@lucailmartini* commented on this pull request.
--

In src/java/org/apache/poi/ss/usermodel/DataFormatter.java
:

> +
+private static final Pattern endsWithCommas = Pattern.compile("(,+)$");
+private BigDecimal divider;
+private static final BigDecimal ONE_THOUSAND = new BigDecimal(1000);
+private final DecimalFormat df;
+private static final String trimTrailingCommas(String s) {
+return s.replaceAll(",+$", "");
+}
+
+public InternalDecimalFormatWithScale(String pattern,
DecimalFormatSymbols symbols) {
+df = new DecimalFormat(trimTrailingCommas(pattern), symbols);
+setExcelStyleRoundingMode(df);
+Matcher endsWithCommasMatcher = endsWithCommas.matcher(pattern);
+if (endsWithCommasMatcher.find()) {
+String commas = (endsWithCommasMatcher.group(1));
+BigDecimal temp = BigDecimal.ONE;

hi @onealj , did you have the chance to review
my comment?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
, or mute the
thread

.

Re: svn commit: r1800341 - in /poi/trunk/src/ooxml/java/org/apache/poi/xssf/usermodel/charts: XSSFCategoryAxis.java XSSFChartAxis.java XSSFDateAxis.java XSSFValueAxis.java

[Javen O'Neal]

It's probably worth annotating a method that takes or returns a CT* class
with @Internal, since CT* classes are an implementation detail to POI ooxml
and may not work if we get rid of xmlbeans or fully read the XML into POJOs
then recreate the XML on write.

On Jun 29, 2017 4:06 PM,  wrote:

Author: gwoolsey
Date: Thu Jun 29 23:06:27 2017
New Revision: 1800341

URL: http://svn.apache.org/viewvc?rev=1800341=rev
Log:
Expose one more bit of style information generically (for XSSF).  If
someone needs all these properties for HSSF charts as well, we can build a
new Interface for the various bits and populate it with things like axis
line width and color, etc. but for now I think most users are in the XSSF
realm like me.

Modified:
poi/trunk/src/ooxml/java/org/apache/poi/xssf/usermodel/
charts/XSSFCategoryAxis.java
poi/trunk/src/ooxml/java/org/apache/poi/xssf/usermodel/
charts/XSSFChartAxis.java
poi/trunk/src/ooxml/java/org/apache/poi/xssf/usermodel/
charts/XSSFDateAxis.java
poi/trunk/src/ooxml/java/org/apache/poi/xssf/usermodel/
charts/XSSFValueAxis.java

Modified: poi/trunk/src/ooxml/java/org/apache/poi/xssf/usermodel/
charts/XSSFCategoryAxis.java
URL: http://svn.apache.org/viewvc/poi/trunk/src/ooxml/java/org/
apache/poi/xssf/usermodel/charts/XSSFCategoryAxis.java?
rev=1800341=1800340=1800341=diff

==
--- 
poi/trunk/src/ooxml/java/org/apache/poi/xssf/usermodel/charts/XSSFCategoryAxis.java
(original)
+++ 
poi/trunk/src/ooxml/java/org/apache/poi/xssf/usermodel/charts/XSSFCategoryAxis.java
Thu Jun 29 23:06:27 2017
@@ -33,6 +33,7 @@ import org.openxmlformats.schemas.drawin
 import org.openxmlformats.schemas.drawingml.x2006.chart.CTScaling;
 import org.openxmlformats.schemas.drawingml.x2006.chart.CTTickMark;
 import org.openxmlformats.schemas.drawingml.x2006.chart.STTickLblPos;
+import org.openxmlformats.schemas.drawingml.x2006.main.CTShapeProperties;

 /**
  * Category axis type.
@@ -58,6 +59,10 @@ public class XSSFCategoryAxis extends XS
return ctCatAx.getAxId().getVal();
}

+   public CTShapeProperties getLine() {
+   return ctCatAx.getSpPr();
+   }
+
protected CTAxPos getCTAxPos() {
return ctCatAx.getAxPos();
}

Modified: poi/trunk/src/ooxml/java/org/apache/poi/xssf/usermodel/
charts/XSSFChartAxis.java
URL: http://svn.apache.org/viewvc/poi/trunk/src/ooxml/java/org/
apache/poi/xssf/usermodel/charts/XSSFChartAxis.java?rev=
1800341=1800340=1800341=diff

==
--- 
poi/trunk/src/ooxml/java/org/apache/poi/xssf/usermodel/charts/XSSFChartAxis.java
(original)
+++ 
poi/trunk/src/ooxml/java/org/apache/poi/xssf/usermodel/charts/XSSFChartAxis.java
Thu Jun 29 23:06:27 2017
@@ -37,6 +37,7 @@ import org.openxmlformats.schemas.drawin
 import org.openxmlformats.schemas.drawingml.x2006.chart.STCrosses;
 import org.openxmlformats.schemas.drawingml.x2006.chart.STOrientation;
 import org.openxmlformats.schemas.drawingml.x2006.chart.STTickMark;
+import org.openxmlformats.schemas.drawingml.x2006.main.CTShapeProperties;

 /**
  * Base class for all axis types.
@@ -195,6 +196,7 @@ public abstract class XSSFChartAxis impl
protected abstract CTTickMark getMajorCTTickMark();
protected abstract CTTickMark getMinorCTTickMark();
public abstract CTChartLines getMajorGridLines();
+   public abstract CTShapeProperties getLine();

private static STOrientation.Enum fromAxisOrientation(AxisOrientation
orientation) {
switch (orientation) {

Modified: poi/trunk/src/ooxml/java/org/apache/poi/xssf/usermodel/
charts/XSSFDateAxis.java
URL: http://svn.apache.org/viewvc/poi/trunk/src/ooxml/java/org/
apache/poi/xssf/usermodel/charts/XSSFDateAxis.java?rev=
1800341=1800340=1800341=diff

==
--- 
poi/trunk/src/ooxml/java/org/apache/poi/xssf/usermodel/charts/XSSFDateAxis.java
(original)
+++ 
poi/trunk/src/ooxml/java/org/apache/poi/xssf/usermodel/charts/XSSFDateAxis.java
Thu Jun 29 23:06:27 2017
@@ -34,6 +34,7 @@ import org.openxmlformats.schemas.drawin
 import org.openxmlformats.schemas.drawingml.x2006.chart.CTScaling;
 import org.openxmlformats.schemas.drawingml.x2006.chart.CTTickMark;
 import org.openxmlformats.schemas.drawingml.x2006.chart.STTickLblPos;
+import org.openxmlformats.schemas.drawingml.x2006.main.CTShapeProperties;

 /**
  * Date axis type.  Currently only implements the same values as {@link
XSSFCategoryAxis}, since the two are nearly identical.
@@ -66,6 +67,10 @@ public class XSSFDateAxis extends XSSFCh
return ctDateAx.getAxId().getVal();
}

+public CTShapeProperties getLine() {
+return ctDateAx.getSpPr();
+}
+
protected CTAxPos getCTAxPos() {
return ctDateAx.getAxPos();
}

Modified: 

Moving to Git

[Javen O'Neal]

A fair increase in Github PR's. Having a git repo might increase the
number of (good) PR's we get, as that seems to be where a lot of
developers are at.

Then we'd be able to have github show merged PR's with credit to the
author rather than closed PR's.

Looks like some of Apache Commons is going through the transition right now.
https://wiki.apache.org/commons/MovingToGit

There's a lot of other Apache projects that have made the change that
could help us along too.

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

Re: [RESULT][VOTE] Apache POI 3.17-beta1 release (RC1)

[Javen O'Neal]

Thanks, Andi.

Looks like Maven Central has the artifacts now. Other mirrors may not be up
to date, though.
http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.apache.poi%22

On Jun 27, 2017 16:31, "Andreas Beeker" <kiwiwi...@apache.org> wrote:

> This vote has passed with 4x PMC +1 and 1x PMC 0 votes.
>
> I release the artifacts now and announce the release on the website,
> when I see the files on maven central.
>
> Andi
>
> On 6/27/17 10:41 PM, Javen O'Neal wrote:
> > +0 from me. I didn't have time to review this release.
> >
> > On Jun 27, 2017 7:48 AM, "Greg Woolsey" <greg.wool...@gmail.com> wrote:
> >
> >> +1
> >>
> >> So far so good in my tests, no sudden slow downs in my performance
> cases.
> >>
> >> On Tue, Jun 27, 2017, 05:15 Allison, Timothy B. <talli...@mitre.org>
> >> wrote:
> >>
> >>> +1
> >>>
> >>> Checksums and sig are good.  Built/tested on Windows.
> >>>
> >>> Thank you, Andi!
> >>>
> >>> -Original Message-
> >>> From: Dominik Stadler [mailto:dominik.stad...@gmx.at]
> >>> Sent: Monday, June 26, 2017 9:11 AM
> >>> To: POI Developers List <dev@poi.apache.org>
> >>> Subject: Re: [VOTE] Apache POI 3.17-beta1 release (RC1)
> >>>
> >>> Hi,
> >>>
> >>> I compared the contents of the archives to 3.16, things look good
> there.
> >>>
> >>> Otherwise +1 from me.
> >>>
> >>> Thanks for rolling! Dominik.
> >>>
> >>> On Sat, Jun 24, 2017 at 1:13 PM, Andreas Beeker <kiwiwi...@apache.org>
> >>> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> I've prepared artifacts for the release of Apache POI 3.17-beta1
> (RC1).
> >>>>
> >>>> The most notable changes in this release are:
> >>>>
> >>>> - XSSF: improved support for XSSFTables
> >>>> - HSLF: various fixes in table support
> >>>> - HPSF: reworked to cover edge cases and better support non-latin
> >>>> charsets
> >>>> - SL Common: fixed rendering of preset-shapes
> >>>> - HWPF: support for Binary RC4 / CryptoAPI de-/encryption
> >>>>
> >>>> https://dist.apache.org/repos/dist/dev/poi/3.17-beta1-RC1/
> >>>>
> >>>> All tests pass. ASC files verify and MD5/SHA1 are correct. Docs look
> >>> fine.
> >>>> I'll add the summary to the change log on releasing the artifacts.
> >>>> I think the XML signature support is currently flawed, but I don't
> >>>> think this is a blocker.
> >>>>
> >>>> Please vote to release the artifacts.
> >>>> The vote keeps open for 72hrs, 2017-06-27, 23:59 UTC, planned release
> >>>> announcement date is Saturday, 2017-07-01.
> >>>>
> >>>> Here is my +1
> >>>>
> >>>> Andi
> >>>>
> >>>>
> >>>>
>
>
>

Re: Table Formula Manipulation and Matrix Function Implementation in HSSF/XSSF

[Javen O'Neal]

Greg Woolsey has provided quite a few improvements on Table support for
XSSF recently (last 6-12 months).

Question to the devs: Are tables part of the XLS binary file format, and if
so are users interested in a common SS Table interface?

Question to Robert: Is LLNL particularly interested in using POI to read
and write workbooks containing tables and matrix (table or array?)
functions? Or were they more interested in having an intern help out on an
open source project and table support was one idea they had?


On Jun 27, 2017 1:01 PM, "Hulbert, Robert Douglas" 
wrote:

Hi,

I'm a summer student at Lawrence Livermore National Laboratory and was
hired to find or implement POI's table formulas and matrix functions.

Over the last week or so, I have checked the POI page/Contributor
guidelines and have looked through the source code for handling this
functionality.

Is anyone still interested in this functionality? If not, is there any
documentation on where this aspect left off?

Thank you so much for any help you can give!

Best Regards,
Robert Hulbert

Re: [VOTE] Apache POI 3.17-beta1 release (RC1)

[Javen O'Neal]

+0 from me. I didn't have time to review this release.

On Jun 27, 2017 7:48 AM, "Greg Woolsey"  wrote:

> +1
>
> So far so good in my tests, no sudden slow downs in my performance cases.
>
> On Tue, Jun 27, 2017, 05:15 Allison, Timothy B. 
> wrote:
>
> > +1
> >
> > Checksums and sig are good.  Built/tested on Windows.
> >
> > Thank you, Andi!
> >
> > -Original Message-
> > From: Dominik Stadler [mailto:dominik.stad...@gmx.at]
> > Sent: Monday, June 26, 2017 9:11 AM
> > To: POI Developers List 
> > Subject: Re: [VOTE] Apache POI 3.17-beta1 release (RC1)
> >
> > Hi,
> >
> > I compared the contents of the archives to 3.16, things look good there.
> >
> > Otherwise +1 from me.
> >
> > Thanks for rolling! Dominik.
> >
> > On Sat, Jun 24, 2017 at 1:13 PM, Andreas Beeker 
> > wrote:
> >
> > > Hi,
> > >
> > > I've prepared artifacts for the release of Apache POI 3.17-beta1 (RC1).
> > >
> > > The most notable changes in this release are:
> > >
> > > - XSSF: improved support for XSSFTables
> > > - HSLF: various fixes in table support
> > > - HPSF: reworked to cover edge cases and better support non-latin
> > > charsets
> > > - SL Common: fixed rendering of preset-shapes
> > > - HWPF: support for Binary RC4 / CryptoAPI de-/encryption
> > >
> > > https://dist.apache.org/repos/dist/dev/poi/3.17-beta1-RC1/
> > >
> > > All tests pass. ASC files verify and MD5/SHA1 are correct. Docs look
> > fine.
> > > I'll add the summary to the change log on releasing the artifacts.
> > > I think the XML signature support is currently flawed, but I don't
> > > think this is a blocker.
> > >
> > > Please vote to release the artifacts.
> > > The vote keeps open for 72hrs, 2017-06-27, 23:59 UTC, planned release
> > > announcement date is Saturday, 2017-07-01.
> > >
> > > Here is my +1
> > >
> > > Andi
> > >
> > >
> > >
> >
>

Re: svn commit: r1799645 - /poi/trunk/src/ooxml/java/org/apache/poi/xssf/util/EMUUtils.java

[Javen O'Neal]

if you don't want to wait for "ant jenkins" to run til completion (the
ooxml-lite and test-integration targets take a long time and rarely
catches issues not caught by the "test" target if you're not adding a
test-data/*/* file), then run:
"ant test rat-check findbugs forbidden-apis-check". That'll get you
most of the way there for a fraction of the run time.

That is assuming you haven't leaped to gradle yet.

On Thu, Jun 22, 2017 at 11:17 PM,   wrote:
> Author: gwoolsey
> Date: Fri Jun 23 06:17:09 2017
> New Revision: 1799645
>
> URL: http://svn.apache.org/viewvc?rev=1799645=rev
> Log:
> Bug 61203
>
> one of these days I'll add the copyright to my project templates.
>
> Modified:
> poi/trunk/src/ooxml/java/org/apache/poi/xssf/util/EMUUtils.java
>
> Modified: poi/trunk/src/ooxml/java/org/apache/poi/xssf/util/EMUUtils.java
> URL: 
> http://svn.apache.org/viewvc/poi/trunk/src/ooxml/java/org/apache/poi/xssf/util/EMUUtils.java?rev=1799645=1799644=1799645=diff
> ==
> --- poi/trunk/src/ooxml/java/org/apache/poi/xssf/util/EMUUtils.java (original)
> +++ poi/trunk/src/ooxml/java/org/apache/poi/xssf/util/EMUUtils.java Fri Jun 
> 23 06:17:09 2017
> @@ -1,3 +1,19 @@
> +/* 
> +   Licensed to the Apache Software Foundation (ASF) under one or more
> +   contributor license agreements.  See the NOTICE file distributed with
> +   this work for additional information regarding copyright ownership.
> +   The ASF licenses this file to You under the Apache License, Version 2.0
> +   (the "License"); you may not use this file except in compliance with
> +   the License.  You may obtain a copy of the License at
> +
> +   http://www.apache.org/licenses/LICENSE-2.0
> +
> +   Unless required by applicable law or agreed to in writing, software
> +   distributed under the License is distributed on an "AS IS" BASIS,
> +   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> +   See the License for the specific language governing permissions and
> +   limitations under the License.
> + */
>  package org.apache.poi.xssf.util;
>
>  import org.apache.poi.xssf.usermodel.XSSFShape;
>
>
>
> -
> To unsubscribe, e-mail: commits-unsubscr...@poi.apache.org
> For additional commands, e-mail: commits-h...@poi.apache.org
>

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

Developing POI with an IDE

[Javen O'Neal]

What IDE's are people using to develop POI? Command line Ant and Gradle on
Linux are pretty straight forward. We currently ship POI with an Eclipse
.project file, but I'd be interested in adding project files for other IDEs
if it makes it easier for people to build POI for the first time.

I am trying out IntelliJ IDEA. If someone already has a working setup in
IDEA that is reusable on a fresh checkout, let us know.

RE: Is it time for POI 3.17-beta1?

[Javen O'Neal]

+1 from me.

On Jun 19, 2017 04:26, "Allison, Timothy B."  wrote:

> +1
>
> I'd like to get in some small modifications I've been meaning to work on.
> I'll have time today.
>
> -Original Message-
> From: Andreas Beeker [mailto:kiwiwi...@apache.org]
> Sent: Monday, June 19, 2017 4:09 AM
> To: POI Developers List 
> Subject: Is it time for POI 3.17-beta1?
>
> Hi *,
>
> there are quite some changes since the last final in the changelog - how
> about pushing out the next beta?
>
> I would be available as release manager ...
>
> As I made substantial changes to HPSF - I'm curious about the common-crawl
> & Co. tests, i.e. the integration test have been modified to test HPSF now,
> so I'm sure there will be new errors reported in this area ...
>
> Andi
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
> For additional commands, e-mail: dev-h...@poi.apache.org
>
>

Re: DataTables and formula evaluation

[Javen O'Neal]

I think most people using isFormulaCell assume they're working with a cell
containing a regular formula, not a cell that belongs to an array formula
or table.
I'd say it's fair to document this distinction in the JavaDoc and provide a
isArrayFormulaCell and isTableFormulaCell if those concepts are useful.

On Jun 9, 2017 4:42 PM, "Greg Woolsey"  wrote:

POI doesn't currently support "data table" formulas (a variation on array
formulas).  However, the implementation of XSSFCell.isFormulaCell() still
thinks the "master" cell for a data table is a formula type cell.  But the
formula is not a stored one, but implied by the definition of a data table
and it's parameters.  Thus getCellFormula() returns an empty string, which
doesn't parse as a valid formula.

I think isFormulaCell() should just not consider these as formula cells
until POI supports data table formulas.  Currently saying they are formulas
but not actually figuring out what that formula is doesn't make sense.

Anyone think of a case this would be bad?  It should only affect data table
master cells, changing the current expression from:

if (_cell.getF() != null
  || getSheet().isCellInArrayFormulaContext(this))

to

if ( (_cell.isSetF() && _cell.getF().getT() != STCellFormulaType.DATA_TABLE
)
   || getSheet().isCellInArrayFormulaContext(this))

doesn't break anything for me.

Re: [PATCHES] poi as calculation engine

[Javen O'Neal]

> How about we adopt a full lazy-evaluation approach for Formula objects?
I opened bug 61136 [1] and took a stab at full lazy evaluation [2].

Travis, would you be willing to test the memory consumption and
execution speed with these changes in HSSF and XSSF relative to trunk
and your patch (8ab388eb78)?

[1] https://bz.apache.org/bugzilla/show_bug.cgi?id=61136
[2] https://bz.apache.org/bugzilla/attachment.cgi?id=35014=diff

On Tue, May 30, 2017 at 8:49 PM, Javen O'Neal <one...@apache.org> wrote:
> How about we adopt a full lazy-evaluation approach for Formula objects?
> Either _byteEncoding and _encodedTokenLen should be provided or
> _ptgTokens should be provided. Only when the other is needed should
> Ptg.readTokens or Ptg.serializeTokens be called.
>
> As I understand it, reading and serializing tokens is pretty
> expensive, and eager evaluation is expensive if the results are never
> used.
>
> There should be:
>> private Formula(final byte[] byteEncoding, final int encodedTokenLen);
>> private Formula(final Ptg[] cachedTokens);
> I don't think a third constructor is necessary with the current code
> and enough lazy evaluation, but here's a 3rd constructor
>> private Formula(final byte[] byteEncoding, final int encodedTokenLen, final 
>> Ptg[] cachedTokens);
>
> I think we're less likely to rewrite org.apache.poi.hssf.model with
> SpreadsheetVersion code since it would encourage incorrect usage (the
> mailing list would explode). However, if you can get to the bottom of
> why HSSF formula evaluation is faster with some profiling (perhaps
> it's the expensive xmlbean reading and writing that's slowing XSSF
> down), then we could go that avenue.
> 1. Find and fix the largest contributors to the overall formula
> evaluation time for your XSSF and HSSF test cases.
> 2. Create a GenericSSEvaluationWorkbook that stores sheets, cells, and
> rows in plain old java objects without the underlying HSSF bytestream
> or XSSF/SXSSF xml data structures that are needed for serialization.
> This wouldn't need to be a writeable workbook. This could plug into
> the current formula evaluation code.
> 3. Rewrite some of the XSSF classes that wrap an xmlbean to fully read
> their data from an xmlbean, and only recreate the bean when writing
> out. We want to go this direction with XSSF as it would make POI
> faster, use less memory, and make it easier to transition to a
> different XML library. Maybe I'm overstating, but long term, this
> would make it easier to merge HSSF, XSSF, SXSSF, and other SS
> interfaces, enabling format-agnostic classes that could convert
> between xls and xlsx.
> 4. Other ideas?

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

Re: [PATCHES] poi as calculation engine

[Javen O'Neal]

How about we adopt a full lazy-evaluation approach for Formula objects?
Either _byteEncoding and _encodedTokenLen should be provided or
_ptgTokens should be provided. Only when the other is needed should
Ptg.readTokens or Ptg.serializeTokens be called.

As I understand it, reading and serializing tokens is pretty
expensive, and eager evaluation is expensive if the results are never
used.

There should be:
> private Formula(final byte[] byteEncoding, final int encodedTokenLen);
> private Formula(final Ptg[] cachedTokens);
I don't think a third constructor is necessary with the current code
and enough lazy evaluation, but here's a 3rd constructor
> private Formula(final byte[] byteEncoding, final int encodedTokenLen, final 
> Ptg[] cachedTokens);

I think we're less likely to rewrite org.apache.poi.hssf.model with
SpreadsheetVersion code since it would encourage incorrect usage (the
mailing list would explode). However, if you can get to the bottom of
why HSSF formula evaluation is faster with some profiling (perhaps
it's the expensive xmlbean reading and writing that's slowing XSSF
down), then we could go that avenue.
1. Find and fix the largest contributors to the overall formula
evaluation time for your XSSF and HSSF test cases.
2. Create a GenericSSEvaluationWorkbook that stores sheets, cells, and
rows in plain old java objects without the underlying HSSF bytestream
or XSSF/SXSSF xml data structures that are needed for serialization.
This wouldn't need to be a writeable workbook. This could plug into
the current formula evaluation code.
3. Rewrite some of the XSSF classes that wrap an xmlbean to fully read
their data from an xmlbean, and only recreate the bean when writing
out. We want to go this direction with XSSF as it would make POI
faster, use less memory, and make it easier to transition to a
different XML library. Maybe I'm overstating, but long term, this
would make it easier to merge HSSF, XSSF, SXSSF, and other SS
interfaces, enabling format-agnostic classes that could convert
between xls and xlsx.
4. Other ideas?

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

Re: svn commit: r1796035 - in /poi/trunk: build.gradle build.xml sonar/ooxml/pom.xml

[Javen O'Neal]

Is jmh a test dependency or a regular OOXML runtime dependency?

I was hoping that we wouldn't have to require jmh for projects using the
poi jars.
Is it a required dependency because it's used for poi-ooxml-schemas.jar? If
so, can we exclude it from that jar so it isn't a dependency?

On May 24, 2017 3:07 AM,  wrote:

> Author: centic
> Date: Wed May 24 10:07:32 2017
> New Revision: 1796035
>
> URL: http://svn.apache.org/viewvc?rev=1796035=rev
> Log:
> Add jmh to Sonar-Maven build as well, add comment why we need to stick to
> 1.15 for now
>
> Modified:
> poi/trunk/build.gradle
> poi/trunk/build.xml
> poi/trunk/sonar/ooxml/pom.xml
>
> Modified: poi/trunk/build.gradle
> URL: http://svn.apache.org/viewvc/poi/trunk/build.gradle?rev=
> 1796035=1796034=1796035=diff
> 
> ==
> --- poi/trunk/build.gradle (original)
> +++ poi/trunk/build.gradle Wed May 24 10:07:32 2017
> @@ -210,6 +210,7 @@ project('ooxml') {
>
> testCompile 'junit:junit:4.12'
> testCompile project(path: ':main', configuration: 'tests')
> +   // Keep using 1.15 until we switch to Java 7
> testCompile 'org.openjdk.jmh:jmh-core:1.15'
> testCompile 'org.openjdk.jmh:jmh-
> generator-annprocess:1.15'
> }
>
> Modified: poi/trunk/build.xml
> URL: http://svn.apache.org/viewvc/poi/trunk/build.xml?rev=
> 1796035=1796034=1796035=diff
> 
> ==
> --- poi/trunk/build.xml (original)
> +++ poi/trunk/build.xml Wed May 24 10:07:32 2017
> @@ -163,6 +163,7 @@ under the License.
>  
>  
>  
> +
>  
>  
>  
>
> Modified: poi/trunk/sonar/ooxml/pom.xml
> URL: http://svn.apache.org/viewvc/poi/trunk/sonar/ooxml/pom.xml?
> rev=1796035=1796034=1796035=diff
> 
> ==
> --- poi/trunk/sonar/ooxml/pom.xml (original)
> +++ poi/trunk/sonar/ooxml/pom.xml Wed May 24 10:07:32 2017
> @@ -161,5 +161,19 @@
>  junit
>  ${junit.version}
>  
> +
> +
> +
> +org.openjdk.jmh
> +jmh-core
> +1.15
> +   test
> +
> +
> +org.openjdk.jmh
> +jmh-generator-annprocess
> +1.15
> +   test
> +
>  
>  
>
>
>
> -
> To unsubscribe, e-mail: commits-unsubscr...@poi.apache.org
> For additional commands, e-mail: commits-h...@poi.apache.org
>
>

Re: Build failed in Jenkins: POI-DSL-Maven #194

[Javen O'Neal]

I broke the Maven and Sonar builds be adding OpenJDK JMH test dependency.
It shouldn't be needed for the jars or maven, right?


On May 15, 2017 17:06, "Apache Jenkins Server" 
wrote:

> See  redirect?page=changes>
>
> Changes:
>
> [onealj] update changelog for github-54 from Tim Helmstedt
>
> [onealj] github-54: when adding a picture to an XSSFWorkbook, reduce
> memory consumption by 100x and increase speed by 10x based on OpenJDK JMH
> benchmarking. Thanks to Tim Helmstedt! This closes #54.
> https://github.com/apache/poi/pull/54
>
> --
> [...truncated 1.15 MB...]
> [INFO] No sources to compile
> [INFO]
> [INFO] --- maven-surefire-plugin:2.19.1:test (default-test) @
> poi-ooxml-schema-encryption ---
> [INFO] No tests to run.
> [INFO]
> [INFO] --- maven-antrun-plugin:1.8:run (remove-xmltypeloader-from-schema-jar)
> @ poi-ooxml-schema-encryption ---
> [INFO] Executing tasks
>
> main:
>[delete] Deleting directory  job/POI-DSL-Maven/ws/sonar/ooxml-schema-encryption/
> target/classes/org/apache>
> [INFO] Executed tasks
> [INFO]
> [INFO] --- maven-jar-plugin:2.4:jar (default-jar) @
> poi-ooxml-schema-encryption ---
> [INFO] Building jar:  job/POI-DSL-Maven/ws/sonar/ooxml-schema-encryption/
> target/poi-ooxml-schema-encryption-3.17-beta1-SNAPSHOT.jar>
> [INFO]
> [INFO] 
> 
> [INFO] Building Apache POI - Openxmlformats Security-Schema package
> 3.17-beta1-SNAPSHOT
> [INFO] 
> 
> [INFO]
> [INFO] --- maven-download-plugin:1.1.0:wget (install-xsds-part-1) @
> poi-ooxml-schema-security ---
> [INFO] Got from cache:  repository/.cache/maven-download-plugin/Office%20Open%
> 20XML%201st%20edition%20Part%202%20(PDF).zip>
> [INFO]
> [INFO] --- maven-download-plugin:1.1.0:wget (install-xsds-part-2) @
> poi-ooxml-schema-security ---
> [INFO] Got from cache:  repository/.cache/maven-download-plugin/dc.xsd>
> [INFO]
> [INFO] --- maven-download-plugin:1.1.0:wget (install-xsds-part-3) @
> poi-ooxml-schema-security ---
> [INFO] Got from cache:  repository/.cache/maven-download-plugin/dcterms.xsd>
> [INFO]
> [INFO] --- maven-download-plugin:1.1.0:wget (install-xsds-part-4) @
> poi-ooxml-schema-security ---
> [INFO] Got from cache:  repository/.cache/maven-download-plugin/dcmitype.xsd>
> [INFO]
> [INFO] --- maven-download-plugin:1.1.0:wget (install-xsds-part-5) @
> poi-ooxml-schema-security ---
> [INFO] Got from cache:  repository/.cache/maven-download-plugin/xmldsig-core-schema.xsd>
> [INFO]
> [INFO] --- maven-download-plugin:1.1.0:wget (install-xsds-part-6) @
> poi-ooxml-schema-security ---
> [INFO] Got from cache:  repository/.cache/maven-download-plugin/XAdES.xsd>
> [INFO]
> [INFO] --- maven-download-plugin:1.1.0:wget (install-xsds-part-7) @
> poi-ooxml-schema-security ---
> [INFO] Got from cache:  repository/.cache/maven-download-plugin/XAdESv141.xsd>
> [INFO]
> [INFO] --- maven-antrun-plugin:1.8:run (copy-xmltype-and-xsdconfig) @
> poi-ooxml-schema-security ---
> [INFO] Executing tasks
>
> main:
>  [copy] Copying 7 files to  job/POI-DSL-Maven/ws/sonar/ooxml-schema-security/target/
> generated-sources/xmlbeans>
>  [copy] Copying 1 file to  job/POI-DSL-Maven/ws/sonar/ooxml-schema-security/target/schemas>
> [INFO] Executed tasks
> [INFO]
> [INFO] --- maven-antrun-plugin:1.8:run (unzip-schema) @
> poi-ooxml-schema-security ---
> [INFO] Executing tasks
>
> main:
>  [echo] unzip schemas
> [unzip] Expanding:  job/POI-DSL-Maven/ws/sonar/ooxml-schema-security/target/
> OpenPackagingConventions-XMLSchema.zip> into  job/POI-DSL-Maven/ws/sonar/ooxml-schema-security/target/schemas>
>  [copy] Copying 1 file to  job/POI-DSL-Maven/ws/sonar/ooxml-schema-security/target/schemas>
> [INFO] Executed tasks
> [INFO]
> [INFO] --- xmlbeans-maven-plugin:2.3.3:xmlbeans (default) @
> poi-ooxml-schema-security ---
> [INFO]
> [INFO] --- maven-antrun-plugin:1.8:run (replace-xmltypeloader) @
> poi-ooxml-schema-security ---
> [INFO] Executing tasks
>
> main:
> [INFO] Executed tasks
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
> poi-ooxml-schema-security ---
> [INFO] Using 'ASCII' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory 

Re: svn commit: r1795122 - /poi/trunk/test-data/spreadsheet/~$tableStyle.xlsx

[Javen O'Neal]

Not a bad idea
svn propedit test-data/spreadsheet

On May 14, 2017 16:18, "Greg Woolsey"  wrote:

Thanks for noticing that I totally missed that I checked in the temp file.
Perhaps the ignore list needs this as a pattern to avoid it happening again.

On Sun, May 14, 2017, 15:24  wrote:

> Author: kiwiwings
> Date: Sun May 14 22:24:07 2017
> New Revision: 1795122
>
> URL: http://svn.apache.org/viewvc?rev=1795122=rev
> Log:
> removed invalid test file
>
> Removed:
> poi/trunk/test-data/spreadsheet/~$tableStyle.xlsx
>
>
> -
> To unsubscribe, e-mail: commits-unsubscr...@poi.apache.org
> For additional commands, e-mail: commits-h...@poi.apache.org
>
>

Re: Not able to add excelsheets to existing excel file

[Javen O'Neal]

You create 2 workbook objects if the file exists. One of those workbooks
doesn't get closed.

If the workbook exists, you read from and write to the same file while the
workbook is open. This corrupts the file. Either use the in-place write
method (this is a new addition, still in development), or write to a
different file location, close the workbook, and shuffle the files around
as necessary.

On May 8, 2017 07:51, "Aakash Rathod"  wrote:

Hi All,
I want to add new sheets to existing excel file, but when file doesn't
exist it it successfully created and even opens successfully with the data
and when i try to add new sheet to this existing file it doesn't throw any
error but when i try to open this file it throws error saying "We found a
problem with some content in 'filename' ? Do you want us to try to
recover..". Code is pasted below. Please look into it and help me
out.

import java.io.File;
import java.io.FileOutputStream;
import java.io.IOException;

import org.apache.poi.openxml4j.exceptions.InvalidFormatException;
import org.apache.poi.ss.usermodel.WorkbookFactory;
import org.apache.poi.xssf.usermodel.XSSFSheet;
import org.apache.poi.xssf.usermodel.XSSFWorkbook;

public class FileCheck {
public static void main(String[] args) {
XSSFWorkbook workbook = new XSSFWorkbook();
String fileName="Trial.xlsx";
File file = new File(fileName);
FileOutputStream out;
if(!file.exists()){ // This will create new workbook with new
sheet if it doesnt exists{
System.out.println("New");
XSSFSheet mySheet = workbook.createSheet("A");
} else{ // This add new sheet to above created workbook
try {
System.out.println("Old");
XSSFWorkbook myWorkBook = (XSSFWorkbook)
WorkbookFactory.create(file);
workbook=myWorkBook;
XSSFSheet mySheet = (XSSFSheet)
workbook.createSheet("B");
} catch (InvalidFormatException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
try{
out = new FileOutputStream(fileName,true);
workbook.write(out);
out.close();
}catch(Exception e){
e.printStackTrace();
}
}
}

Thanks,
Aakash Rathod

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

Re: Java (Apache POI) : How to retrieve comment/annotation and associated highlight text from Microsoft Word?

[Javen O'Neal]

A few additions, since John is the critical thing:





John



  

  Comment Anchor Range Start

  
  

  Comment Anchor Range End

  

So if performance isn't a concern here (you don't need to save
pointers to where the comment ranges are), the pseudo-code for a
XWPFComment method that gets the text that a comment refers to would
be:

public String getRefersToText() {
StringBuilder refersTo = new StringBuilder();
for each CTParagraph in document:
for each child element of the CTParagraph:
if child element is a commentRangeStart and id==this.id
append subsequent text runs to the refersTo buffer
continue
if we have found the comment range start and child
element is a text run
append this text run to the refersTo buffer
if child element is a commentRangeEnd and id==this.id
return refersTo.toString() (assuming that one
comment may not refer to multiple text ranges)

}

This would require searching the entire document for every comment.
https://svn.apache.org/viewvc/poi/trunk/src/ooxml/java/org/apache/poi/xwpf/usermodel/XWPFDocument.java?view=markup
https://svn.apache.org/viewvc/poi/trunk/src/ooxml/java/org/apache/poi/xwpf/usermodel/XWPFParagraph.java?view=markup

On Tue, May 9, 2017 at 11:14 PM, Javen O'Neal <one...@apache.org> wrote:
> First, if you're using Java 1.5+(?), you can use for-each loops for
> more readable code.
> for (final XWPFComment comment : adoc.getComments()) {
> final String id = comment.getId();
> final String author = comment.getAuthor();
> final String text = comment.getText();
> }
>
> I don't see anything in POI right now that make extracting the
> annotated text that a track changes comment refers to.
>
> Here's the current implementation of XWPFComment:
> https://svn.apache.org/viewvc/poi/trunk/src/ooxml/java/org/apache/poi/xwpf/usermodel/XWPFComment.java?view=markup
>
> Taking a look at the OOXML 2006 schemas wml.xsd (download from
> http://www.ecma-international.org/publications/files/ECMA-ST/Office%20Open%20XML%201st%20edition%20Part%204%20(PDF).zip,
> extract OfficeOpenXML-Part4a.zip, extract OfficeOpenXML-XMLSchema.zip,
> open wml.xsd), I see that the comment (*.docx/word/comments.xml)
> doesn't refer to the document text.
>
>   
> 
>   
> 
>maxOccurs="unbounded">
> 
> 
>   
> Initials of Comment Author
>   
> 
>   
> 
>   
>
>   
> 
>   
> 
>   
> Annotation Author
>   
> 
> 
>   
> Annotation Date
>   
> 
>   
> 
>   
>
>   
> 
>   
> Annotation Identifier
>   
> 
>   
>
> Examining the zipped xml contents of a simple comment example docx
> file that I created, I see that the relationship is the other way
> around: the document refers to the comments (this ordering makes more
> sense anyways).
>
> For a simple file that I created with the text "My name is John." and
> annotated the word John with a comment with the message "Noun", here's
> what I got in CommentExample.docx/word/document.xml:
>
> 
> 
> 
> 
>  w:rsidRDefault="" w:rsidRPr="">
> 
> 
> 
> 
> 
>
> 
> 
> 
> My name is 
> 
>
> 
> 
> 
> 
> John
> 
> 
>
> 
> 
> 
>
> 
> 
> 
> .
> 
>
> 
> 
> 
>  w:right="1440" w:header="0"/>
> 
> 
> 
> 
>
> So to solve your problem, you could either:
> 1. search the document.xml for all comments, looking up the comment's
> author and text using the ID that is referenced in the document
> commentRangeStart-commentRangeEnd and joining all the text contained
> between those markers
> 2. for each comment in the comment table, find the corresponding
> commentRangeStart and commentRangeEnd tags in document.xml and get the
> corresponding text that was annotated (in this example, John).
>
> If you don't already have a development environment set up, I
> encourage you to do so. Patches are greatly appreciated.
>
> On Tue, May 9, 2017 a

Re: Java (Apache POI) : How to retrieve comment/annotation and associated highlight text from Microsoft Word?

[Javen O'Neal]

First, if you're using Java 1.5+(?), you can use for-each loops for
more readable code.
for (final XWPFComment comment : adoc.getComments()) {
final String id = comment.getId();
final String author = comment.getAuthor();
final String text = comment.getText();
}

I don't see anything in POI right now that make extracting the
annotated text that a track changes comment refers to.

Here's the current implementation of XWPFComment:
https://svn.apache.org/viewvc/poi/trunk/src/ooxml/java/org/apache/poi/xwpf/usermodel/XWPFComment.java?view=markup

Taking a look at the OOXML 2006 schemas wml.xsd (download from
http://www.ecma-international.org/publications/files/ECMA-ST/Office%20Open%20XML%201st%20edition%20Part%204%20(PDF).zip,
extract OfficeOpenXML-Part4a.zip, extract OfficeOpenXML-XMLSchema.zip,
open wml.xsd), I see that the comment (*.docx/word/comments.xml)
doesn't refer to the document text.

  

  

  


  
Initials of Comment Author
  

  

  

  

  

  
Annotation Author
  


  
Annotation Date
  

  

  

  

  
Annotation Identifier
  

  

Examining the zipped xml contents of a simple comment example docx
file that I created, I see that the relationship is the other way
around: the document refers to the comments (this ordering makes more
sense anyways).

For a simple file that I created with the text "My name is John." and
annotated the word John with a comment with the message "Noun", here's
what I got in CommentExample.docx/word/document.xml:















My name is 






John










.











So to solve your problem, you could either:
1. search the document.xml for all comments, looking up the comment's
author and text using the ID that is referenced in the document
commentRangeStart-commentRangeEnd and joining all the text contained
between those markers
2. for each comment in the comment table, find the corresponding
commentRangeStart and commentRangeEnd tags in document.xml and get the
corresponding text that was annotated (in this example, John).

If you don't already have a development environment set up, I
encourage you to do so. Patches are greatly appreciated.

On Tue, May 9, 2017 at 9:42 AM, Ramani Routray  wrote:
> I have a Microsoft word (.docx) file and trying to retrieve the comments and 
> it's associated highlighted text. Can you pls help.
>
> Attaching picture of the sample word document and the java code for 
> extracting the comments. [ A file with a line "My name is John". The word 
> "John" is highlighted with a comment "Noun" ]
>
> I am able to extract the comments (Noun, Adjective). I would like to extract 
> the text associated with the comment "Noun" (Noun = John, Adjective = great)
>
> FileInputStream fis = new FileInputStream(new File(msWordFilePath));
> XWPFDocument adoc = new XWPFDocument(fis);
> XWPFWordExtractor xwe = new XWPFWordExtractor(adoc);
> XWPFComment[] comments = adoc.getComments();
>
>
> for(int idx=0; idx < comments.length; idx++)
> {
> MSWordAnnotation annot = new MSWordAnnotation();
> annot.setAnnotationName(comments[idx].getId());
> annot.setAnnotationValue(comments[idx].getText());
> aList.add(annot);
>
>
> }
>
> -
> 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: xls record length exception

[Javen O'Neal]

Is bug 61049 related?

On Apr 27, 2017 5:16 AM, "Allison, Timothy B." <talli...@mitre.org> wrote:

> Thank you, Javen.
>
> As happens too often, I had senders-regret on this email.  I found a
> triggering file in our regression corpus and opened 61045.
>
> No multibytes found; more details in issue.
>
> Thank you!
>
> -Original Message-
> From: Javen O'Neal [mailto:javenon...@gmail.com]
> Sent: Wednesday, April 26, 2017 11:59 PM
> To: POI Developers List <dev@poi.apache.org>
> Subject: Re: xls record length exception
>
> Are there any multibyte Unicode characters in the record?
>
> Any chance you could open the file in a hex editor or modify the biff
> record reader to dump the bytes of just that record?
>
> If the record contents are sensitive, you could redact all single-byte
> codepoints with 0x41 ("A"). Of course at that point you've probably found
> the problem...
>
> On Apr 26, 2017 11:45, "Allison, Timothy B." <talli...@mitre.org> wrote:
>
> All,
>   I can't share the file, but...  (sorry, it hurts me too).  File opens
> without problem in Excel.  If anyone has any recommendations, I'd
> appreciate it.
>
> Caused by: org.apache.poi.hssf.record.RecordFormatException: Expected to
> find a ContinueRecord in order to read remaining 1 of 51 chars
>at org.apache.poi.hssf.record.RecordInputStream.
> readStringCommon(RecordInputStream.java:420)
>at org.apache.poi.hssf.record.RecordInputStream.
> readCompressedUnicode(RecordInputStream.java:379)
>at org.apache.poi.hssf.record.FormatRecord.(
> FormatRecord.java:57)
>
> It looks like the record length is correct, but that the XLUnicode string
> requires one more character than is stored in the record.
>
> In a format record, I'm seeing:
>
> 1E 04 37 00  -- format record which should contain 0x37 bytes 2a 00 -
> index code and Unicode or not
> 33 00 00 ...  --- the XLUnicode String that should be 51 characters long
>
> However, only 50 characters follow...and they match where the overall
> record length should end
>
> Another format record follows immediately:
> 1E 04 2E 00...
>

Re: xls record length exception

[Javen O'Neal]

Are there any multibyte Unicode characters in the record?

Any chance you could open the file in a hex editor or modify the biff
record reader to dump the bytes of just that record?

If the record contents are sensitive, you could redact all single-byte
codepoints with 0x41 ("A"). Of course at that point you've probably found
the problem...

On Apr 26, 2017 11:45, "Allison, Timothy B."  wrote:

All,
  I can't share the file, but...  (sorry, it hurts me too).  File opens
without problem in Excel.  If anyone has any recommendations, I'd
appreciate it.

Caused by: org.apache.poi.hssf.record.RecordFormatException: Expected to
find a ContinueRecord in order to read remaining 1 of 51 chars
   at org.apache.poi.hssf.record.RecordInputStream.
readStringCommon(RecordInputStream.java:420)
   at org.apache.poi.hssf.record.RecordInputStream.
readCompressedUnicode(RecordInputStream.java:379)
   at org.apache.poi.hssf.record.FormatRecord.(
FormatRecord.java:57)

It looks like the record length is correct, but that the XLUnicode string
requires one more character than is stored in the record.

In a format record, I'm seeing:

1E 04 37 00  -- format record which should contain 0x37 bytes
2a 00 - index code and Unicode or not
33 00 00 ...  --- the XLUnicode String that should be 51 characters long

However, only 50 characters follow...and they match where the overall
record length should end

Another format record follows immediately:
1E 04 2E 00...

Re: [Bug 61004] org.apache.poi.hssf.usermodel.HSSFWorkbook.createCellStyle() throws NoClassDefFoundError on Google App Engine

[Javen O'Neal]

Are we set up to test POI in several typical environments as part of our CI
or release testing? Tomcat, Jetty, Google App Engine, JBoss and a couple
other web containers?

On Apr 19, 2017 1:23 AM, <bugzi...@apache.org> wrote:

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

--- Comment #2 from Javen O'Neal <one...@apache.org> ---
Do we need to make an effort to exclude java.awt.Color or java.awt.* from
our
codebase if we want to support restricted environments?

If this is a commitment that we can and want to make, we should add the
appropriate rules to forbidden apis. This would keep this behavior from
lapsing
back once fixed (we already fixed this before in bug 59194).

If I remember correctly, HSLF relies on java.awt for positioning of shapes
and
rendering of slides, so running HSLF in a restricted environments is less
likely. HSSF might not have the same quantity of java.awt usages.

Perhaps this discussion should take place on the dev list.

--
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: bean-free ooxml streaming readers?

[Javen O'Neal]

Absolutely!

Since XMLBeans is collecting cobwebs in the attic, we've been looking for a
replacement, so long as it doesn't grow the POI codebase too much.

On Apr 4, 2017 5:29 AM, "Allison, Timothy B."  wrote:

Thank you, Javen.

On Tika, we now have mostly bean-free SAX-based parsers for docx and pptx.

Is there any interest in moving those into POI and potentially working
towards creating a new read-only module that does not depend on
ooxml-schemas.

Not for 3.16, obviously...

Cheers,

   Tim

Re: POI 3.16 Final?

[Javen O'Neal]

+1

ThreadLocal-related bugs:
https://bz.apache.org/bugzilla/buglist.cgi?bug_status=__all__=Threadlocal_id=158556=Importance=POI_format=specific

On Apr 3, 2017 8:15 AM, "Dominik Stadler"  wrote:

> Hi,
>
> soonish sounds fine to me, I can start a first regression run tomorrow or
> Wednesday to get results before we start the release process.
>
> On ThreadLocals: XMLBeans is dormant, so unfortuantely not much help to be
> expected from there, I started some early work on https://bz.apache.org/
> bugzilla/show_bug.cgi?id=59268 some time ago, but unfortunately it was
> very
> unwieldly, i.e. for some reason it was hard to even identify the exact
> version used for previous releases or build the latest version cleanly.
>
> Dominik.
>
> On Mon, Apr 3, 2017 at 3:14 PM, Allison, Timothy B. 
> wrote:
>
> > Is there anything we can do about ThreadLocal leaks in POI bug
> > 55149/XMLBEANS-502/TIKA-1784?
> >
> > -Original Message-
> > From: Allison, Timothy B. [mailto:talli...@mitre.org]
> > Sent: Monday, April 3, 2017 9:06 AM
> > To: POI Developers List 
> > Subject: RE: POI 3.16 Final?
> >
> > +1 for next couple days-ish.
> >
> > I'd like to finish or abandon hope on 50955.  I'll be working on that
> this
> > morning.
> >
> > -Original Message-
> > From: Andreas Beeker [mailto:kiwiwi...@apache.org]
> > Sent: Saturday, April 1, 2017 6:46 PM
> > To: POI Developers List 
> > Subject: POI 3.16 Final?
> >
> > Hi,
> >
> > how about pushing the 3.16 final out soon?
> >
> > I have quite a few changes for HPSF, which I don't want to commit to the
> > final.
> >
> > Who will be the release manager? ... I'll be the fallback, if everyone is
> > busy ...
> >
> > Andi
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional
> > commands, e-mail: dev-h...@poi.apache.org
> >
> >
> >
>

Re: java.lang.IllegalArgumentException: target is null for type http://schemas.openxmlformats.org/officeDocument/2006/relationships/h

[Javen O'Neal]

> wb.write(fileOut); . Fileout is just the directory

SXSSFWorkbook.write(File) must be a filename, not a directory.

On Mar 16, 2017 2:06 PM, "Dominik Stadler"  wrote:

> Can you share some standalone sample code which reproduces this? Or at
> least some snippets that show what you do?
>
> Dominik
>
> On Mar 16, 2017 20:12, "duanep026"  wrote:
>
> > Hi Dominik,
> >
> > Thank you for your response. I do create  hyperlinks. And I do call the
> > setAddress method to set the location. I've  also checked and every
> > hyperlink that I set has an actual address being set. There are no null
> or
> > blank addresses.
> >
> > Please advise.
> >
> > Thanks,
> > Duane
> >
> >
> >
> > --
> > View this message in context: http://apache-poi.1045710.n5.
> > nabble.com/java-lang-IllegalArgumentException-
> > target-is-null-for-type-http-schemas-openxmlformats-org-
> > officeDoch-tp5726901p5726906.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
> >
> >
>

Getting and setting cell value

[Javen O'Neal]

Would it be a good idea to add the following two methods to the cell
interface so that the switch(cell.getCellType()) code can be taken care of
in POI?

interface org.apache.poi.ss.usermodel.Cell {
Object getCellValue();
void setCellValue(Object value);
}

We would have to decide how to handle formulas, but otherwise the code is
straightforward. I think this would go a long way to making the POI API
easier to use.

Any objections?

RE: xlsb Streaming Reader?

[Javen O'Neal]

Regarding newer editions of OOXML schema:

If that's something you're interested in and willing to work on, yes. Read
through the bug first to see the backwards compatibility concerns.

On Mar 6, 2017 11:02, "Murphy, Mark" <murphym...@metalexmfg.com> wrote:

> Are we trying to support OOXML schemas other than the 1st edition?
>
> -Original Message-
> From: Javen O'Neal [mailto:javenon...@gmail.com]
> Sent: Monday, March 06, 2017 12:24 PM
> To: POI Developers List <dev@poi.apache.org>
> Subject: Re: xlsb Streaming Reader?
>
> +1!
>
> We currently have no support for xlsb, either streaming or dom. This would
> be a welcome addition.
>
> We also have bugs open for OOXML strict (bug 57699) and 3rd Edition OOXML
> schemas (bug 56205), depending on how much you want time you have to
> contribute in the name of file format support.
>
> On Mar 6, 2017 6:00 AM, "Allison, Timothy B." <talli...@mitre.org> wrote:
>
> > All,
> >   I'm considering starting work on a streaming reader for xlsb.  Has
> > anyone else worked on this?  Would this conflict with anyone's plans?
> >
> >  Best,
> >
> >  Tim
> >
> > [1] https://issues.apache.org/jira/browse/TIKA-1195
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional
> > commands, e-mail: dev-h...@poi.apache.org
> >
> >
>

Re: xlsb Streaming Reader?

[Javen O'Neal]

+1!

We currently have no support for xlsb, either streaming or dom. This would
be a welcome addition.

We also have bugs open for OOXML strict (bug 57699) and 3rd Edition OOXML
schemas (bug 56205), depending on how much you want time you have to
contribute in the name of file format support.

On Mar 6, 2017 6:00 AM, "Allison, Timothy B."  wrote:

> All,
>   I'm considering starting work on a streaming reader for xlsb.  Has
> anyone else worked on this?  Would this conflict with anyone's plans?
>
>  Best,
>
>  Tim
>
> [1] https://issues.apache.org/jira/browse/TIKA-1195
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
> For additional commands, e-mail: dev-h...@poi.apache.org
>
>

Re: GSOC mentee

[Javen O'Neal]

Excel Chart support is certainly an area where help is needed, and it's
pretty well sized for one summer worth of effort.

I'd be happy to mentor you with Chart support.

I've haven't looked into GSOC mentor or mentee requirements yet, but I
imagine it includes creating a plan for what you want to accomplish in
terms of skills (subversion/git, creating patches, building, unit tests,
collaboration) and the scope of the changes you will make (chart types,
formula support, pivot charts, rendering to PNG, embedded Excel charts in
Word and PowerPoint, etc).

What are *you* most interested in working on?
Your homework is to outline a few of the Java classes you will be working
with. This will show us that you know how to check out the code, can read
Java, gain a preliminary understanding of the POI package structure, and
have a vision for the direction that POI should be headed.

On Mar 2, 2017 02:26, "Piyush Sharma"  wrote:

> Hey,
>
> I was looking forward to getting into GSOC with apache.org ! Apache poi is
> something that I've worked  with for one of my projects previously. I am
> pretty much interested in working with apache POI. I would really be glad
> if anyone would point me in the right direction as to what would be the
> right set of deliverables to get accepted in GSOC with apache poi, or even
> better mentor me to work with poi.
>
> One of the issues that caught my eye was enhancement for chart support in
> Excel. I am currently a 3rd year CSE student at BITS Pilani, University
> (INDIA). I think I have the time and the dedication to be very well devoted
> to contributing to open source.
>
> Looking forward for a reply. Thanking in anticipation.
>
> Cheers
> Piyush Sharma
>

Re: [apache/poi] make line breaks consistent - always use line feeds (LF) (#20)

[Javen O'Neal]

Anyone object to a massive EOL conversion? Should we put this off to POI
4.0?

doc2unix `find -name "*.java"`; svn propset svn:eol-style `find -name
"*.java"`?

Do we want to do an indentation whitespace conversion while we're touching
all the files and potentially breaking patch files and forks?

On Feb 27, 2017 03:42, "René Scheibe"  wrote:

> Closed #20 .
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> , or mute the
> thread
> 
> .
>

Re: Evaluating expressions outside a cell value context

[Javen O'Neal]

Just reading through some of the open POI bugs.
Looks like this work is related to
https://bz.apache.org/bugzilla/show_bug.cgi?id=58131
This bug should be updated, possibly resolved, with the work you've done here.

On Mon, Feb 13, 2017 at 7:51 AM, Greg Woolsey <greg.wool...@gmail.com> wrote:
> What I meant was external implementations of the Sheet interface.
> Everything inside POI that I've done in my branch is fully implemented with
> tests and JavaDocs.
>
> On Sun, Feb 12, 2017 at 7:32 PM Javen O'Neal <javenon...@gmail.com> wrote:
>
> Anything that is still stubbed can be annotated with @NotImplemented, which
> will add the corresponding note to the JavaDocs.
>
> On Feb 12, 2017 17:08, "Greg Woolsey" <greg.wool...@gmail.com> wrote:
>
>> Thanks for taking the time to inspect it, and point me to the utilities, I
>> hadn't found them yet.  I'll incorporate them and run all the tests
>> including my new ones.
>>
>> Are folks OK with this as part of 3.16?  I'd like that.  There are some
> new
>> methods on some interfaces, so if there are custom implementations of
>> things like Sheet, they would need changes.  Returning null or false
> should
>> be fine though, as the only callers are the new evaluator classes, and
>> anyone using those would need the new API methods anyway.
>>
>> On Sun, Feb 12, 2017, 5:22 PM Javen O'Neal <javenon...@gmail.com> wrote:
>>
>> > I haven't read through all your changes on GitHub yet, but all the
>> > changes so far look good. I have a few other suggestions to
>> > deduplicate some code using SheetUtil and FormulaShifter, but those
>> > changes can be made at a later date if needed.
>> >
>> > You should be able to use git-svn to push your changes. Read through
>> > and improve our git documentation [1] if necessary.
>> >
>> > [1] https://poi.apache.org/guidelines.html#Approach+3+-+the+git+way
>> >
>> > On Fri, Feb 10, 2017 at 12:10 AM, Greg Woolsey <greg.wool...@gmail.com>
>> > wrote:
>> > > Well, I couldn't stand the incomplete support, so now this supports
>> > > evaluating rules for all the different types, including range
>> aggregates
>> > > like "greater than 2 standard deviations" and "top 10".  Still doesn't
>> > > provide help assigning partitioning buckets for icon sets and colors,
>> but
>> > > everything else is working.
>> > >
>> > > I filed a big bug with Vaadin, listing 5 core design problems I've
>> found
>> > > with their Conditional Formatting implementation, and offering my
>> > > replacement for their code that uses the new POI evaluator instead.
>> They
>> > > bit, and are interested, but I won't make my first commit some
> behemoth
>> > > that hasn't received any feedback.  I know there are conventions and
>> > ideas
>> > > I've missed :)
>> > >
>> > >  I need both sets of changes for my day job, so I'm all-in on doing it
>> > > right in both directions and facilitating the conversations.
>> > >
>> > > On Tue, Feb 7, 2017 at 11:50 PM Greg Woolsey <greg.wool...@gmail.com>
>> > wrote:
>> > >
>> > >> Now this fork also contains ConditionalSpreadsheetEvaluator, and
>> related
>> > >> code.  The unit test is essentially a stub, but tests one basic style
>> > for
>> > >> proof of concept.
>> > >>
>> > >> I've actually implemented a version of Vaadin Spreadsheet that uses
>> this
>> > >> new code to see how it performs, and I'm quite happy with both the
>> > improved
>> > >> performance (~50% faster than theirs) and feature coverage/accuracy.
>> > I've
>> > >> found 5 major bugs so far in what they did, most likely the result of
>> > the
>> > >> complexity of the document structure and the fact that several key
>> > pieces
>> > >> of information where still buried in the implementation classes, and
>> > hadn't
>> > >> been surfaced yet to the SS interfaces.  I've done that in this
> branch
>> > also.
>> > >>
>> > >> My code here is my own, I didn't like anything I saw elsewhere enough
>> to
>> > >> copy it :)
>> > >>
>> > >> Evaluation currently doesn't support range-based conditions, such as
>> > >> TOP_10, DUPLICATE, etc.  Those don't seem like they'd be that bad to
>> > do,

Re: Missing "Ant (latest)"

[Javen O'Neal]

Done.

r1873170
https://svn.apache.org/viewvc?view=revision=1783170

On Feb 15, 2017 6:41 AM, "Dominik Stadler" <dominik.stad...@gmx.at> wrote:

> Yes, would be good if you can add a note there that Ant 1.8 - 1.9.x is
> supported for Java 1.6.
>
> Dominik.
>
> On Wed, Feb 15, 2017 at 5:15 AM, Javen O'Neal <javenon...@gmail.com>
> wrote:
>
> > Should we mention that if someone builds with Java 6, the highest version
> > of Ant they can use is 1.9.9?
> >
> > https://poi.apache.org/howtobuild.html#Install+Apache+Ant
> >
> > https://svn.apache.org/viewvc/poi/site/src/documentation/
> > release-guide.txt?revision=1781457=markup#l44
> >
> >
> > On Feb 14, 2017 00:39, "Andreas Beeker" <kiwiwi...@apache.org> wrote:
> >
> >> We need to downgrade to Ant 1.9.9.
> >>
> >>
> >>
> >> [image: ipv6guru]Gavin
> >> <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=ipv6guru>
> added
> >> a comment - 3 hours ago
> >> So yesterday all nodes/slaves had two new Ant versions installed - 1.9.9
> >> and 1.10.1.
> >> 1.10.1 was symlinked to latest. 1.10.1 also has Java 8 as a requirement.
> >>
> >> Any builds that dont use Java 8 should pick 1.9.9 or earlier from the
> >> drop down choices.
> >>
> >> See the builds@ list for the announcement
> >>
> >>
>

Re: Missing "Ant (latest)"

[Javen O'Neal]

Should we mention that if someone builds with Java 6, the highest version
of Ant they can use is 1.9.9?

https://poi.apache.org/howtobuild.html#Install+Apache+Ant

https://svn.apache.org/viewvc/poi/site/src/documentation/release-guide.txt?revision=1781457=markup#l44


On Feb 14, 2017 00:39, "Andreas Beeker"  wrote:

> We need to downgrade to Ant 1.9.9.
>
>
>
> [image: ipv6guru]Gavin
>  added
> a comment - 3 hours ago
> So yesterday all nodes/slaves had two new Ant versions installed - 1.9.9
> and 1.10.1.
> 1.10.1 was symlinked to latest. 1.10.1 also has Java 8 as a requirement.
>
> Any builds that dont use Java 8 should pick 1.9.9 or earlier from the drop
> down choices.
>
> See the builds@ list for the announcement
>
>

Re: Evaluating expressions outside a cell value context

[Javen O'Neal]

Anything that is still stubbed can be annotated with @NotImplemented, which
will add the corresponding note to the JavaDocs.

On Feb 12, 2017 17:08, "Greg Woolsey" <greg.wool...@gmail.com> wrote:

> Thanks for taking the time to inspect it, and point me to the utilities, I
> hadn't found them yet.  I'll incorporate them and run all the tests
> including my new ones.
>
> Are folks OK with this as part of 3.16?  I'd like that.  There are some new
> methods on some interfaces, so if there are custom implementations of
> things like Sheet, they would need changes.  Returning null or false should
> be fine though, as the only callers are the new evaluator classes, and
> anyone using those would need the new API methods anyway.
>
> On Sun, Feb 12, 2017, 5:22 PM Javen O'Neal <javenon...@gmail.com> wrote:
>
> > I haven't read through all your changes on GitHub yet, but all the
> > changes so far look good. I have a few other suggestions to
> > deduplicate some code using SheetUtil and FormulaShifter, but those
> > changes can be made at a later date if needed.
> >
> > You should be able to use git-svn to push your changes. Read through
> > and improve our git documentation [1] if necessary.
> >
> > [1] https://poi.apache.org/guidelines.html#Approach+3+-+the+git+way
> >
> > On Fri, Feb 10, 2017 at 12:10 AM, Greg Woolsey <greg.wool...@gmail.com>
> > wrote:
> > > Well, I couldn't stand the incomplete support, so now this supports
> > > evaluating rules for all the different types, including range
> aggregates
> > > like "greater than 2 standard deviations" and "top 10".  Still doesn't
> > > provide help assigning partitioning buckets for icon sets and colors,
> but
> > > everything else is working.
> > >
> > > I filed a big bug with Vaadin, listing 5 core design problems I've
> found
> > > with their Conditional Formatting implementation, and offering my
> > > replacement for their code that uses the new POI evaluator instead.
> They
> > > bit, and are interested, but I won't make my first commit some behemoth
> > > that hasn't received any feedback.  I know there are conventions and
> > ideas
> > > I've missed :)
> > >
> > >  I need both sets of changes for my day job, so I'm all-in on doing it
> > > right in both directions and facilitating the conversations.
> > >
> > > On Tue, Feb 7, 2017 at 11:50 PM Greg Woolsey <greg.wool...@gmail.com>
> > wrote:
> > >
> > >> Now this fork also contains ConditionalSpreadsheetEvaluator, and
> related
> > >> code.  The unit test is essentially a stub, but tests one basic style
> > for
> > >> proof of concept.
> > >>
> > >> I've actually implemented a version of Vaadin Spreadsheet that uses
> this
> > >> new code to see how it performs, and I'm quite happy with both the
> > improved
> > >> performance (~50% faster than theirs) and feature coverage/accuracy.
> > I've
> > >> found 5 major bugs so far in what they did, most likely the result of
> > the
> > >> complexity of the document structure and the fact that several key
> > pieces
> > >> of information where still buried in the implementation classes, and
> > hadn't
> > >> been surfaced yet to the SS interfaces.  I've done that in this branch
> > also.
> > >>
> > >> My code here is my own, I didn't like anything I saw elsewhere enough
> to
> > >> copy it :)
> > >>
> > >> Evaluation currently doesn't support range-based conditions, such as
> > >> TOP_10, DUPLICATE, etc.  Those don't seem like they'd be that bad to
> > do, if
> > >> someone wants to take a stab at them.  I don't need them (yet), so
> they
> > >> just evaluate to "false" with a TODO comment for now.
> > >>
> > >> Likewise, there is no code to report which partition bucket a cell
> falls
> > >> into when the condition type is one of the partitioned styles, 2,3 or
> 4
> > >> value buckets, gradient fill, etc.  The fact that the rule matches
> > (based
> > >> on range) is available, the caller would need to evaluate the rule
> type
> > and
> > >> see what lies beneath.
> > >>
> > >> I assume interested parties will take a look as they have time and
> > >> inclination.  I'm sure there are areas to discuss, beyond where to put
> > the
> > >> curly braces :)  I left some comments as to alter

Re: Evaluating expressions outside a cell value context

[Javen O'Neal]

I haven't read through all your changes on GitHub yet, but all the
changes so far look good. I have a few other suggestions to
deduplicate some code using SheetUtil and FormulaShifter, but those
changes can be made at a later date if needed.

You should be able to use git-svn to push your changes. Read through
and improve our git documentation [1] if necessary.

[1] https://poi.apache.org/guidelines.html#Approach+3+-+the+git+way

On Fri, Feb 10, 2017 at 12:10 AM, Greg Woolsey  wrote:
> Well, I couldn't stand the incomplete support, so now this supports
> evaluating rules for all the different types, including range aggregates
> like "greater than 2 standard deviations" and "top 10".  Still doesn't
> provide help assigning partitioning buckets for icon sets and colors, but
> everything else is working.
>
> I filed a big bug with Vaadin, listing 5 core design problems I've found
> with their Conditional Formatting implementation, and offering my
> replacement for their code that uses the new POI evaluator instead.  They
> bit, and are interested, but I won't make my first commit some behemoth
> that hasn't received any feedback.  I know there are conventions and ideas
> I've missed :)
>
>  I need both sets of changes for my day job, so I'm all-in on doing it
> right in both directions and facilitating the conversations.
>
> On Tue, Feb 7, 2017 at 11:50 PM Greg Woolsey  wrote:
>
>> Now this fork also contains ConditionalSpreadsheetEvaluator, and related
>> code.  The unit test is essentially a stub, but tests one basic style for
>> proof of concept.
>>
>> I've actually implemented a version of Vaadin Spreadsheet that uses this
>> new code to see how it performs, and I'm quite happy with both the improved
>> performance (~50% faster than theirs) and feature coverage/accuracy.  I've
>> found 5 major bugs so far in what they did, most likely the result of the
>> complexity of the document structure and the fact that several key pieces
>> of information where still buried in the implementation classes, and hadn't
>> been surfaced yet to the SS interfaces.  I've done that in this branch also.
>>
>> My code here is my own, I didn't like anything I saw elsewhere enough to
>> copy it :)
>>
>> Evaluation currently doesn't support range-based conditions, such as
>> TOP_10, DUPLICATE, etc.  Those don't seem like they'd be that bad to do, if
>> someone wants to take a stab at them.  I don't need them (yet), so they
>> just evaluate to "false" with a TODO comment for now.
>>
>> Likewise, there is no code to report which partition bucket a cell falls
>> into when the condition type is one of the partitioned styles, 2,3 or 4
>> value buckets, gradient fill, etc.  The fact that the rule matches (based
>> on range) is available, the caller would need to evaluate the rule type and
>> see what lies beneath.
>>
>> I assume interested parties will take a look as they have time and
>> inclination.  I'm sure there are areas to discuss, beyond where to put the
>> curly braces :)  I left some comments as to alternate strategies for some
>> areas, where I opted for less change to existing classes as a starting
>> point, even if it means a switch...case here or there when a new method
>> could be added to an Enum class instead.
>>
>> Hopefully the new methods on the SS interfaces are deemed minor - the
>> values were already there in most cases, at least on one side or the other
>> (HSSF/XSSF), with a static default to use for the other one per MS
>> documentation.
>>
>> Greg
>>
>> On Wed, Feb 1, 2017 at 5:38 PM Greg Woolsey 
>> wrote:
>>
>> Oh, the primary class is o.a.p.ss.formula.DataValidationEvaluator
>>
>> On Wed, Feb 1, 2017 at 5:37 PM Greg Woolsey 
>> wrote:
>>
>> My GitHub branch now contains Data Validation code and unit tests.  The
>> test file DataValidationEvaluations.xlsx contains a large set of validation
>> examples, including one formula example that applies to a range of cells
>> and uses a relative formula.  The evaluation code has corresponding logic
>> to offset the relative formula Ptgs from the top left of the region.
>>
>> Every test is labeled in the file with column A as a description, column B
>> as the cell with validation, and column C the expected result, TRUE =
>> valid, FALSE = invalid.
>>
>> The unit test compares the POI validation result with the expected column,
>> failing on boolean mismatches.
>>
>> Have not had time to run all tests yet, but this should only be code
>> additions, not modifications.  I'll run them soon.
>>
>> I'm sure there are code style discussions to be had - for example I
>> implemented some things as inner classes for now, but we may want them
>> top-level instead.
>>
>> Comments welcome, this is early code but is built on top of the SS
>> interfaces, so should be stable for HSSF and XSSF.
>>
>> Greg
>>
>> On Mon, Jan 30, 2017 at 9:55 AM Greg Woolsey 
>> 

Re: Build failed in Jenkins: POI-DSL-Maven #93

[Javen O'Neal]

I thought it was already doing that with
https://svn.apache.org/viewvc/poi/trunk/build.gradle?revision=1782118=markup#l80

80

tasks.withType(JavaCompile)
{
81

options.encoding
= 'UTF-8'
82

}

On Feb 10, 2017 4:54 AM, "Nick Burch"  wrote:

> I think the key errors for this are things like:
>
> [WARNING] /home/jenkins/jenkins-slave/workspace/POI-DSL-Maven/sonar/ma
> in/src/test/java/org/apache/poi/ss/usermodel/TestDateUtil.java:[113,27]
> unmappable character for encoding US-ASCII
> [WARNING] /home/jenkins/jenkins-slave/workspace/POI-DSL-Maven/sonar/ma
> in/src/test/java/org/apache/poi/ss/usermodel/TestDateUtil.java:[113,28]
> unmappable character for encoding US-ASCII
>
> Does someone need to tweak the Jenkins job to tell it we're now using UTF8
> encoding? Or do we need to use \u escape style encodings in the test
> file for safety?
>
> Nick
>
> On Fri, 10 Feb 2017, Apache Jenkins Server wrote:
>
> See 
>>
>> Changes:
>>
>> [nick] Update the big file test to use POIFSFileSystem.create(File), and
>> tweak javadocs
>>
>> --
>> [...truncated 1055 lines...]
>> Running org.apache.poi.hssf.record.chart.TestSeriesLabelsRecord
>> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec -
>> in org.apache.poi.hssf.record.chart.TestSeriesLabelsRecord
>> Running org.apache.poi.hssf.record.chart.TestLinkedDataRecord
>> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec -
>> in org.apache.poi.hssf.record.chart.TestLinkedDataRecord
>> Running org.apache.poi.hssf.record.chart.TestSeriesIndexRecord
>> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec -
>> in org.apache.poi.hssf.record.chart.TestSeriesIndexRecord
>> Running org.apache.poi.hssf.record.chart.TestObjectLinkRecord
>> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec -
>> in org.apache.poi.hssf.record.chart.TestObjectLinkRecord
>> Running org.apache.poi.hssf.record.chart.TestAreaRecord
>> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec -
>> in org.apache.poi.hssf.record.chart.TestAreaRecord
>> Running org.apache.poi.hssf.record.chart.TestDataFormatRecord
>> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec -
>> in org.apache.poi.hssf.record.chart.TestDataFormatRecord
>> Running org.apache.poi.hssf.record.chart.TestSeriesRecord
>> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec -
>> in org.apache.poi.hssf.record.chart.TestSeriesRecord
>> Running org.apache.poi.hssf.record.chart.TestTextRecord
>> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec -
>> in org.apache.poi.hssf.record.chart.TestTextRecord
>> Running org.apache.poi.hssf.record.chart.TestFrameRecord
>> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec -
>> in org.apache.poi.hssf.record.chart.TestFrameRecord
>> Running org.apache.poi.hssf.record.chart.TestAxisUsedRecord
>> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec -
>> in org.apache.poi.hssf.record.chart.TestAxisUsedRecord
>> Running org.apache.poi.hssf.record.chart.TestFontIndexRecord
>> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec -
>> in org.apache.poi.hssf.record.chart.TestFontIndexRecord
>> Running org.apache.poi.hssf.record.TestExtendedFormatRecord
>> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec -
>> in org.apache.poi.hssf.record.TestExtendedFormatRecord
>> Running org.apache.poi.hssf.record.TestFeatRecord
>> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec -
>> in org.apache.poi.hssf.record.TestFeatRecord
>> Running org.apache.poi.hssf.record.TestCommonObjectDataSubRecord
>> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec -
>> in org.apache.poi.hssf.record.TestCommonObjectDataSubRecord
>> Running org.apache.poi.hssf.record.TestObjRecord
>> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec -
>> in org.apache.poi.hssf.record.TestObjRecord
>> Running org.apache.poi.hssf.record.TestDrawingGroupRecord
>> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec -
>> in org.apache.poi.hssf.record.TestDrawingGroupRecord
>> Running org.apache.poi.hssf.record.TestNoteStructureSubRecord
>> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec -
>> in org.apache.poi.hssf.record.TestNoteStructureSubRecord
>> Running org.apache.poi.hssf.record.TestCFHeaderRecord
>> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec -
>> in org.apache.poi.hssf.record.TestCFHeaderRecord
>> Running org.apache.poi.hssf.record.TestNameCommentRecord
>> Tests 

Re: 3.16 Beta1 vs 3.15 FINAL

[Javen O'Neal]

And might as well use 3.16-beta2 since it was just released.

There were a couple new minor bugs in this beta, but we decided to release
it anyways. Had it been a final release, we would have fixed the bug found
from our regression testing, built another RC, gone through the testing
process again, and released the build two weeks later. It wasn't worth that
effort for a beta, so that's the danger of using a beta.

As Andi said, if you don't experience any bugs using the beta, use it if
you can.

On Feb 9, 2017 02:25, "kiwiwings"  wrote:

> Hi,
>
> we have this policies here too [in my $dayjob], about not using those evil
> beta releases.
> In my point of view there's not so much difference between a beta and a
> final release.
> Before releasing we crunch through a big corpus of office files and do some
> validations/verifications with our own test projects.
> I guess the difference is more in validating that we haven't introduced
> undocumented api breaks
> and that it works nicely with Tika.
>
> So if a beta works ok for your tests, then use the beta ... if not, please
> open a bugzilla entry!
>
> Best wishes,
> Andi
>
>
>
> --
> View this message in context: http://apache-poi.1045710.n5.
> nabble.com/3-16-Beta1-vs-3-15-FINAL-tp5726521p5726527.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
>
>

POI 3.16 beta 2 released

[Javen O'Neal]

The Apache POI PMC is pleased to announce the release of Apache POI 3.16 beta
2.

Apache POI is a Java library for reading and writing Microsoft Office files

For details of changes in this release, refer to the release notes:

https://www.apache.org/dyn/closer.lua/poi/dev/RELEASE-NOTES-3.16-beta2.txt
<https://www.apache.org/dyn/closer.lua/poi/release/RELEASE-NOTES.txt>

Thank you to all our contributors for making this release possible.

On behalf of the Apache POI PMC,

Javen O'Neal

Re: Saving modified Workbook in place

[Javen O'Neal]

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

This bug is still open as it hasn't been fully implemented for all
constructors and factories yet.

On Feb 1, 2017 06:50, "Murphy, Mark"  wrote:

> I thought that there was a way to save a workbook in place when using a
> File type input. But I can't find the secret sauce. If I open a Workbook
> using WorkbookFactory(new File(filename)); I cannot write to an output
> stream based on the same file name. If I write the modified workbook to an
> output stream based on a different file name, the original file is updated,
> but now I have a second file. If I do not write the changes, but instead
> just close the workbook, it does not create the second file, but it also
> does not update the existing file.
>
> So how can I update an existing spreadsheet without creating a secondary
> file? I am guessing that if I use an InputStream to open the initial file,
> I can write the updated workbook to an OutputStream without the original
> being updated?
>

RE: [VOTE] Apache POI 3.16 beta 2 release (RC1)

[Javen O'Neal]

Alright. Just a beta. I'll release it in a few hours.

On Jan 31, 2017 17:49, "Allison, Timothy B." <talli...@mitre.org> wrote:

Argh...sorry, no time this go around...

-Original Message-----
From: Javen O'Neal [mailto:one...@apache.org]
Sent: Tuesday, January 31, 2017 8:19 PM
To: POI Developers List <dev@poi.apache.org>
Subject: Re: [VOTE] Apache POI 3.16 beta 2 release (RC1)

Should I wait for the results of common crawl or other regression testing
before proceeding with the release?

On Jan 30, 2017 16:19, "Andreas Beeker" <kiwiwi...@apache.org> wrote:

> +1 from me
>
> I have only done a shallow check of the - not any more - usual
> suspects, as I'm quite busy with other stuff ... sorry
>
> Thank you Javen for taking care of this.
>
> Andi
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional
> commands, e-mail: dev-h...@poi.apache.org
>
>

Re: [VOTE] Apache POI 3.16 beta 2 release (RC1)

[Javen O'Neal]

Should I wait for the results of common crawl or other regression testing
before proceeding with the release?

On Jan 30, 2017 16:19, "Andreas Beeker"  wrote:

> +1 from me
>
> I have only done a shallow check of the - not any more - usual suspects,
> as I'm quite busy with other stuff ... sorry
>
> Thank you Javen for taking care of this.
>
> Andi
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
> For additional commands, e-mail: dev-h...@poi.apache.org
>
>

Re: [VOTE] Apache POI 3.16 beta 2 release (RC1)

[Javen O'Neal]

+1 from me.

Still reviewing API changes
https://builds.apache.org/view/POI/job/POI-DSL-API-Check/

On Jan 28, 2017 15:54, "Dominik Stadler" <dominik.stad...@gmx.at> wrote:

> Hi,
>
> I compared the the files, content looks good, I did not find anything that
> "slipped in".
>
> Also ran tests in various projects with the newer version, everything looks
> good compared to 3.16-beta1.
>
> +1 from me!
>
> Dominik.
>
> On Fri, Jan 27, 2017 at 7:04 PM, Javen O'Neal <one...@apache.org> wrote:
>
> > Hallo,
> >
> > I have prepared artifacts for the release of Apache POI 3.16-beta2 (RC1).
> >
> > Copied from the new summary section in the changelog [1], the most
> > notable changes in this release are:
> >
> > - The third-party jar for commons-collections4 is now required for
> handling of OLE2 properties
> > - Primitive (experimental) EMF/WMF text extraction support
> > - Unicode and internationalization improvements
> >
> > In addition, we have made significant progress in several administrative
> areas, thanks to Dominik and Andreas,
> > - Generating Jenkins continuous integration jobs [2] with a Groovy script
> > - Continued work on Gradle build system to eventually replace our Ant
> build system (Ant is still our official build system)
> > - JCmpApi to detect intentional (removing features that have been
> deprecated for at least 2 final releases) and unintentional API breaks
> (binary and source)
> > - SonarCube fixes
> > - fix open file leaks (mostly in unit tests)
> >
> >  https://dist.apache.org/repos/dist/dev/poi/3.16-beta2-RC1/
> >
> > What to look for?
> > - verify the artifacts' md5 and sha1 hashes and asc signature. This is
> > my second POI beta release signed with 8BABDD6C, so you
> > may need to import it into your keystore.
> > This key is included in the following KEYS files [3], [4].
> > It is also be found by searching on [5], [6], or most other PGP key
> servers.
> > Steps to verify this are at the end of this email.
> > - add, remove, or modify notable changes. Updating the release notes
> does not require rolling a new release
> > - run common-crawl test
> > - run file leak detector
> > - check for unintentional API breaks with JCmpApi
> >
> > Please vote [7] to release the artifacts. Please vote 0 if everything
> > looks good but you did not have time to test the artifacts in a POI
> > powered application.
> >
> > The vote stays open for at least 72hrs, 2017-01-31, 23:59 UTC, staying
> > open until we have analyzed the results of common-crawl.
> > If no issues are discovered, the planned release announcement date is
> > Thursday, 2017-02-02.
> >
> > Javen O'Neal
> >
> > Steps to verify the build artifacts:
> > wget https://dist.apache.org/repos/dist/dev/poi/KEYS; gpg --import KEYS
> > gpg --import KEYS
> > (alternatively,  gpg --keyserver pgp.mit.edu --recv-key 8BABDD6C)
> > svn checkout https://dist.apache.org/repos/dist/dev/poi/3.16-beta2-RC1
> > cd 3.16-beta2-RC1
> > find . -name "*.md5" -type f -execdir md5sum -c {} \;
> > find . -name "*.sha1" -type f -execdir sha1sum -c {} \;
> > find . -name "*.asc" -exec gpg --no-secmem-warning --verify {} \;
> >
> > More detailed instructions can be found athttps://poi.apache.org/
> download.html#verify
> >
> > [1] https://poi.apache.org/changes.html
> > [2] https://builds.apache.org/view/POI/
> > [3] https://dist.apache.org/repos/dist/dev/poi/KEYS
> > [4] https://svn.apache.org/repos/asf/poi/trunk/KEYS
> > [5] https://people.apache.org/keys/
> > [6] https://pgp.mit.edu/
> > [7]https://www.apache.org/foundation/voting.html#
> expressing-votes-1-0-1-and-fractions
> >
> >
>

Re: [VOTE] Apache POI 3.16-beta2 release (RC1)

[Javen O'Neal]

Please disregard this email chain and respond to the other [VOTE] 3.16 beta
2 email chain.

On Jan 27, 2017 12:58 AM, "Javen O'Neal" <one...@apache.org> wrote:

> Hallo,
>
> I have prepared artifacts for the release of Apache POI 3.16-beta2 (RC1).
>
> Copied from the new summary section in the changelog [1], the most
> notable changes in this release are:
>
> - The third-party jar for commons-collections4 is now required for
> handling of OLE2 properties
> - Primitive (experimental) EMF/WMF text extraction support
> - Unicode and internationalization improvements
>
> In addition, we have made significant progress in several administrative
> areas, thanks to Dominik and Andreas,
> - Generating Jenkins continuous integration jobs [2] with a Groovy script
> - Continued work on Gradle build system to eventually replace our Ant
> build system (Ant is still our official build system)
> - JCmpApi to detect intentional (removing features that have been
> deprecated for at least 2 final releases) and unintentional API breaks
> (binary and source)
> - SonarCube fixes
> - fix open file leaks (mostly in unit tests)
>
>  https://dist.apache.org/repos/dist/dev/poi/3.16-beta2-RC1/
>
> What to look for?
> - verify the artifacts' md5 and sha1 hashes and asc signature. This is
> my second POI beta release signed with 8BABDD6C, so you
> may need to import it into your keystore.
> This key is included in the following KEYS files [3], [4].
> It is also be found by searching on [5], [6], or most other PGP key
> servers.
> Steps to verify this are at the end of this email.
> - add, remove, or modify notable changes. Updating the release notes does
> not require rolling a new release
> - run common-crawl test
> - run file leak detector
> - check for unintentional API breaks with JCmpApi
>
> Please vote [7] to release the artifacts. Please vote 0 if everything
> looks good but you did not have time to test the artifacts in a POI
> powered application.
>
> The vote stays open for at least 72hrs, 2017-01-31, 23:59 UTC, staying
> open until we have analyzed the results of common-crawl.
> If no issues are discovered, the planned release announcement date is
> Thursday, 2017-02-02.
>
> Javen O'Neal
>
> Steps to verify the build artifacts:
> wget https://dist.apache.org/repos/dist/dev/poi/KEYS; gpg --import KEYS
> gpg --import KEYS
> (alternatively,  gpg --keyserver pgp.mit.edu --recv-key 8BABDD6C)
> svn checkout https://dist.apache.org/repos/dist/dev/poi/3.16-beta2-RC1
> cd 3.16-beta2-RC1
> find . -name "*.md5" -type f -execdir md5sum -c {} \;
> find . -name "*.sha1" -type f -execdir sha1sum -c {} \;
> find . -name "*.asc" -exec gpg --no-secmem-warning --verify {} \;
>
> More detailed instructions can be found at
> https://poi.apache.org/download.html#verify
>
> [1] https://poi.apache.org/changes.html
> [2] https://builds.apache.org/view/POI/
> [3] https://dist.apache.org/repos/dist/dev/poi/KEYS
> [4] https://svn.apache.org/repos/asf/poi/trunk/KEYS
> [5] https://people.apache.org/keys/
> [6] https://pgp.mit.edu/
> [7]
> https://www.apache.org/foundation/voting.html#expressing-votes-1-0-1-and-
> fractions
>
>
>

Re: Vote threads - don't reuse old threads

[Javen O'Neal]

Looks like Thunderbird was smarter than me at keeping the message headers
despite changing the subject.

I've resent the 3.16 beta 2 vote email in a fresh email chain. Please
disregard the old one.

On Jan 27, 2017 4:12 AM, "kiwiwings"  wrote:

> Hi,
>
> I've just noticed, that that Javens 3.16-beta2 vote mail was somehow buried
> in an old thread -
> and this happened to me too once in a while ...
>
> Please be aware, that using an old response as a template for a new thread
> leads to a continuation
> of the old thread (because of some header fields) - therefore copy
> the
> content and
> don't respond to the old thread.
>
> Not sure, if it makes to double-post the vote ...
>
> Anyways, thanks for taking care of the release, Javen!
>
> Andi
>
>
>
> --
> View this message in context: http://apache-poi.1045710.n5.
> nabble.com/Vote-threads-don-t-reuse-old-threads-tp5726386.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
>
>

[VOTE] Apache POI 3.16 beta 2 release (RC1)

[Javen O'Neal]

Hallo,

I have prepared artifacts for the release of Apache POI 3.16-beta2 (RC1).

Copied from the new summary section in the changelog [1], the most
notable changes in this release are:

- The third-party jar for commons-collections4 is now required for handling of 
OLE2 properties
- Primitive (experimental) EMF/WMF text extraction support
- Unicode and internationalization improvements

In addition, we have made significant progress in several administrative areas, 
thanks to Dominik and Andreas,
- Generating Jenkins continuous integration jobs [2] with a Groovy script
- Continued work on Gradle build system to eventually replace our Ant build 
system (Ant is still our official build system)
- JCmpApi to detect intentional (removing features that have been deprecated 
for at least 2 final releases) and unintentional API breaks (binary and source)
- SonarCube fixes
- fix open file leaks (mostly in unit tests)

 https://dist.apache.org/repos/dist/dev/poi/3.16-beta2-RC1/

What to look for?
- verify the artifacts' md5 and sha1 hashes and asc signature. This is
my second POI beta release signed with 8BABDD6C, so you
may need to import it into your keystore.
This key is included in the following KEYS files [3], [4].
It is also be found by searching on [5], [6], or most other PGP key servers.
Steps to verify this are at the end of this email.
- add, remove, or modify notable changes. Updating the release notes does not 
require rolling a new release
- run common-crawl test
- run file leak detector
- check for unintentional API breaks with JCmpApi

Please vote [7] to release the artifacts. Please vote 0 if everything
looks good but you did not have time to test the artifacts in a POI
powered application.

The vote stays open for at least 72hrs, 2017-01-31, 23:59 UTC, staying
open until we have analyzed the results of common-crawl.
If no issues are discovered, the planned release announcement date is
Thursday, 2017-02-02.

Javen O'Neal

Steps to verify the build artifacts:
wget https://dist.apache.org/repos/dist/dev/poi/KEYS; gpg --import KEYS
gpg --import KEYS
(alternatively,  gpg --keyserver pgp.mit.edu --recv-key 8BABDD6C)
svn checkout https://dist.apache.org/repos/dist/dev/poi/3.16-beta2-RC1
cd 3.16-beta2-RC1
find . -name "*.md5" -type f -execdir md5sum -c {} \;
find . -name "*.sha1" -type f -execdir sha1sum -c {} \;
find . -name "*.asc" -exec gpg --no-secmem-warning --verify {} \;

More detailed instructions can be found at
https://poi.apache.org/download.html#verify

[1] https://poi.apache.org/changes.html
[2] https://builds.apache.org/view/POI/
[3] https://dist.apache.org/repos/dist/dev/poi/KEYS
[4] https://svn.apache.org/repos/asf/poi/trunk/KEYS
[5] https://people.apache.org/keys/
[6] https://pgp.mit.edu/
[7]
https://www.apache.org/foundation/voting.html#expressing-votes-1-0-1-and-fractions




signature.asc
Description: OpenPGP digital signature

[VOTE] Apache POI 3.16-beta2 release (RC1)

[Javen O'Neal]

Hallo,

I have prepared artifacts for the release of Apache POI 3.16-beta2 (RC1).

Copied from the new summary section in the changelog [1], the most
notable changes in this release are:

- The third-party jar for commons-collections4 is now required for handling of 
OLE2 properties
- Primitive (experimental) EMF/WMF text extraction support
- Unicode and internationalization improvements

In addition, we have made significant progress in several administrative areas, 
thanks to Dominik and Andreas,
- Generating Jenkins continuous integration jobs [2] with a Groovy script
- Continued work on Gradle build system to eventually replace our Ant build 
system (Ant is still our official build system)
- JCmpApi to detect intentional (removing features that have been deprecated 
for at least 2 final releases) and unintentional API breaks (binary and source)
- SonarCube fixes
- fix open file leaks (mostly in unit tests)

 https://dist.apache.org/repos/dist/dev/poi/3.16-beta2-RC1/

What to look for?
- verify the artifacts' md5 and sha1 hashes and asc signature. This is
my second POI beta release signed with 8BABDD6C, so you
may need to import it into your keystore.
This key is included in the following KEYS files [3], [4].
It is also be found by searching on [5], [6], or most other PGP key servers.
Steps to verify this are at the end of this email.
- add, remove, or modify notable changes. Updating the release notes does not 
require rolling a new release
- run common-crawl test
- run file leak detector
- check for unintentional API breaks with JCmpApi

Please vote [7] to release the artifacts. Please vote 0 if everything
looks good but you did not have time to test the artifacts in a POI
powered application.

The vote stays open for at least 72hrs, 2017-01-31, 23:59 UTC, staying
open until we have analyzed the results of common-crawl.
If no issues are discovered, the planned release announcement date is
Thursday, 2017-02-02.

Javen O'Neal

Steps to verify the build artifacts:
wget https://dist.apache.org/repos/dist/dev/poi/KEYS; gpg --import KEYS
gpg --import KEYS
(alternatively,  gpg --keyserver pgp.mit.edu --recv-key 8BABDD6C)
svn checkout https://dist.apache.org/repos/dist/dev/poi/3.16-beta2-RC1
cd 3.16-beta2-RC1
find . -name "*.md5" -type f -execdir md5sum -c {} \;
find . -name "*.sha1" -type f -execdir sha1sum -c {} \;
find . -name "*.asc" -exec gpg --no-secmem-warning --verify {} \;

More detailed instructions can be found at
https://poi.apache.org/download.html#verify

[1] https://poi.apache.org/changes.html
[2] https://builds.apache.org/view/POI/
[3] https://dist.apache.org/repos/dist/dev/poi/KEYS
[4] https://svn.apache.org/repos/asf/poi/trunk/KEYS
[5] https://people.apache.org/keys/
[6] https://pgp.mit.edu/
[7]
https://www.apache.org/foundation/voting.html#expressing-votes-1-0-1-and-fractions




signature.asc
Description: OpenPGP digital signature

Re: Evaluating expressions outside a cell value context

[Javen O'Neal]

Formulas, or at least cell references, show up in a few other places. Any
field that could either be a cell reference or a list of literal values,
such as specifying either A1:A2 or {1,1} for a data source can't be parsed
by just CellReference.
...
3. Named Ranges
4. Pivot Table data source
5. Database data source, possibly
6. Charts

> That means I can't do the POI work on the more complex
and complete steps above.

I'd be interested in writing some of the formula handling code if you need
a fresh set of eyes.

On Jan 26, 2017 5:48 PM, "Greg Woolsey"  wrote:

There are two main types of formula/reference expressions that are not
stored or evaluated as a cell value in Excel files.  Evaluating them in POI
currently requires a hack.

If that paragraph doesn't indicate a topic you care about, stop reading,
the rest is long and detailed :)

--

The types are:

1. Conditional Formatting rules (sometimes, depending on the rule, and then
either one or two, depending on the rule type)
2. Data Validation value ranges

I haven't encountered others, but I can imagine an application where
someone may want to evaluate an arbitrary expression also, without setting
it first as a cell formula.

This can be done today by accessing the evaluate* package-scoped methods in
o.a.p.ss.formula.WorkbookEvaluator from a class defined in that package.
This requires some understanding of formula parsing and the resulting Ptg
array, and uses a method explicitly noted to not be for public use.

A general-purpose public method would look something like the other
evaluate* methods:

public ValueEval evaluate(String formula, CellReference ref, FormulaType
formulaType) {
final String sheetName = ref == null ? null : ref.getSheetName();
if (sheetName == null) throw new IllegalArgumentException("Sheet name
is required");
final int sheetIndex = getWorkbook().getSheetIndex(sheetName);
final OperationEvaluationContext ec = new
OperationEvaluationContext(this, getWorkbook(), sheetIndex, ref.getRow(),
ref.getCol(), new EvaluationTracker(_cache));
Ptg[] ptgs = FormulaParser.parse(formula, (FormulaParsingWorkbook)
getWorkbook(), formulaType, sheetIndex);
return evaluateNameFormula(ptgs, ec);
}

and be fairly simple.

However, we may also want a more semantic way to handle evaluating data
validations and conditional formatting.  Using them has several
complexities and wrinkles that make it hard to do right in all cases, and
are monkey motion that would require the same boilerplate code every time
they are used.  These are prime candidates for additions to the POI API.
In that case, we have these questions we can address via a higher-level API:

1. What data validation rule applies to a given cell?  Null for none
2. What are the valid values allowed for a given cell? (evaluate the data
validation rule if any, or null if no rule applies)
-- this can hide the complexity inherent in the OOXML spec, which stores
both a statically defined list as CSV text and a cell range as a range
expression
3. What cells use a given data validation rule?
4. What conditional formatting rule applies to a given cell?
-- this would check the cell value against defined rules to match their
"applies to" range and evaluate matching ones in rule order (currently the
API returns them in storage order, which has no relationship to Excel
defined priority, which is an attribute).
5. What cells currently match a given conditional format rule?
-- this would check all cells in the rule's "applies to" range using the
logic from #4
-- this might be useful for systems that render Excel files, to apply the
rule format to all the matching cells at once.

I think it would be good to address all of these in POI itself, to
standardize the logic and have tests that validate against results verified
by hand in Excel.

This is definitely a candidate for a branch/discuss/refine/merge workflow,
which I'm willing to pursue.  I haven't done SVN branches and merges in
about 7 years, but how bad can it be? :D

One wrinkle is that I've seen the Vaadin code that does the conditional
formatting, because I'm a licensed customer, but it is using their
commercial license.  That means I can't do the POI work on the more complex
and complete steps above.

The general-purpose method above is based on code I wrote and submitted to
them, so it's fine.

I also have code I've written for data validation evaluation, so I can do
that as well.

I'm also willing to get my boss to contact Vaadin and see if they will
release the relevant bits of conditional formatting code to us for use in
POI with the Apache 2 license.  She's very good at that sort of thing.  I
wouldn't want it directly, but the patterns it follows likely mirror some
of what we need, and I don't want to cause a problem where there doesn't
need to be one.

Greg

Re: Time for another release?

[Javen O'Neal]

I'll start the release process Fri 2017-01-27 00:00 UTC.
After this time, please open feature branches for ongoing development until
we have closed the vote for the the release artifacts.

On Jan 24, 2017 11:57 PM, "Javen O'Neal" <one...@apache.org> wrote:

> We could also fork the trunk to a release branch when we want to make a
> release candidate so that development can continue on the trunk. There
> likely wouldn't be any changes to make on the branch, so we would end up
> copying the release branch to a tag and deleting the release branch.
>
> This would require changing the release scripts, but is a possibility as
> we think about rewriting some of the release procedure in Gradle.
>
> On Jan 24, 2017 22:07, "Nick Burch" <apa...@gagravarr.org> wrote:
>
>> On Wed, 25 Jan 2017, Greg Woolsey wrote:
>>
>>> I have something I'm going to file an issue about tomorrow, but it could
>>> wait. Although having it in would help fix some bugs I'm working around
>>> with Vaadin Spreadsheet.  It would be my first official commit, so I don't
>>> want to do it near a code freeze, just in case.  It's a helper to expose
>>> the formula evaluation code more cleanly for evaluating formulas not tied
>>> to a specific cell, like conditional formatting and data validation
>>> expressions.
>>>
>>
>> I'd suggest you create a branch of trunk, and commit to that. I'm happy
>> to help review, especially the conditional formatting angle. Once we're all
>> happy, and the release is done, merge away!
>>
>> Nick
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
>> For additional commands, e-mail: dev-h...@poi.apache.org
>>
>>

Re: Time for another release?

[Javen O'Neal]

We could also fork the trunk to a release branch when we want to make a
release candidate so that development can continue on the trunk. There
likely wouldn't be any changes to make on the branch, so we would end up
copying the release branch to a tag and deleting the release branch.

This would require changing the release scripts, but is a possibility as we
think about rewriting some of the release procedure in Gradle.

On Jan 24, 2017 22:07, "Nick Burch"  wrote:

> On Wed, 25 Jan 2017, Greg Woolsey wrote:
>
>> I have something I'm going to file an issue about tomorrow, but it could
>> wait. Although having it in would help fix some bugs I'm working around
>> with Vaadin Spreadsheet.  It would be my first official commit, so I don't
>> want to do it near a code freeze, just in case.  It's a helper to expose
>> the formula evaluation code more cleanly for evaluating formulas not tied
>> to a specific cell, like conditional formatting and data validation
>> expressions.
>>
>
> I'd suggest you create a branch of trunk, and commit to that. I'm happy to
> help review, especially the conditional formatting angle. Once we're all
> happy, and the release is done, merge away!
>
> Nick
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
> For additional commands, e-mail: dev-h...@poi.apache.org
>
>

Re: Time for another release?

[Javen O'Neal]

I'll take this release, then.

Are there any outstanding changes that should be committed before creating
the the artifacts for 3.16 beta 2?

On Jan 24, 2017 10:45, "Greg Woolsey" <greg.wool...@gmail.com> wrote:

> I have a product release for my day job this week, best I sit this one out
> :)
>
> On Tue, Jan 24, 2017 at 8:40 AM Javen O'Neal <one...@apache.org> wrote:
>
> > Definitely go for a beta. Also want to check out how JCmpApi is doing to
> > find API breaks.
> >
> > Greg, do you want to be release manager for 3.16 beta 2? If not, I can do
> > it.
> >
> > On Jan 23, 2017 23:52, "Andreas Beeker" <kiwiwi...@apache.org> wrote:
> >
> > > I would go for another beta soon.
> > > Who will be the release manager?
> > >
> > > Andi
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
> > > For additional commands, e-mail: dev-h...@poi.apache.org
> > >
> > >
> >
>

Re: Time for another release?

[Javen O'Neal]

Definitely go for a beta. Also want to check out how JCmpApi is doing to
find API breaks.

Greg, do you want to be release manager for 3.16 beta 2? If not, I can do
it.

On Jan 23, 2017 23:52, "Andreas Beeker"  wrote:

> I would go for another beta soon.
> Who will be the release manager?
>
> Andi
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
> For additional commands, e-mail: dev-h...@poi.apache.org
>
>

Re: EMF/WMF files from our regression corpus

[Javen O'Neal]

All the EMF/WMF code is in scratchpad, is experimental, and hasn't seen a
final release yet.

At least until we have released 3.16 final, there's no need to @deprecated,
@Deprecated, or @Removal any of the EMF code.

On Jan 19, 2017 2:28 PM, "Andreas Beeker"  wrote:

> Hi Tim,
>
> the patch looks good - initially I thought it would be better to keep the
> String version of drawString,
> but HwmfGraphics is the place which combines everything, so this is good.
> As this is scratchpad, please either use the full form of deprecating
> (with @Removal(version))
> or simply remove the methods.
>
> Regarding the common objects/constants ... although I had a quick view
> over the EMF code,
> I haven't read the spec to say anything about that. As the WMF/EMF
> implementations look
> similar, I would simply progress to a more complete parser and eventually
> generalize the code.
>
> Thanks for your work.
>
> Andi
>
>
> On 19.01.2017 17:30, Allison, Timothy B. wrote:
> > That's what I thought, but I figured sharing might be helpful.
> >
> > Andi,
> >   If you have any time to review my initial commit for the wmf parser,
> I'd appreciate it.  The good parts I lifted from your emf code...the other
> parts...well...sorry. :)
> >   There may be some areas where the emf parser could leverage some wmf
> objects/constants...to reduce code...perhaps not, though.
> >
> > Onward.
> >
> > Thank you.
> >
> >   Best,
> >
> >  Tim
> >
> > -Original Message-
> > From: Andreas Beeker [mailto:kiwiwi...@apache.org]
> > Sent: Wednesday, January 18, 2017 6:24 PM
> > To: POI Developers List 
> > Subject: Re: EMF/WMF files from our regression corpus
> >
> > Hi Tim,
> >
> > thank you ... although I'm currently not working on WMF, this is very
> helpful!
> > There are still a lot of features currently not implemented but I
> haven't had examples for.
> >
> > Andi
> >
> > -
> > 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
> >
> >
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
> For additional commands, e-mail: dev-h...@poi.apache.org
>
>

Re: Using Apache Commons IO

[Javen O'Neal]

If having dependencies is seen as a negative, we could use Gradle to shadow
our dependencies (we could start with Apache Commons IO, for which we
currently use very little, but makes our code better where used).

If we shadow import just the classes that we need, this would be a decent
compromise between jar/class load time and consumed perm gen space, and
reducing our maintained code base.

On Jan 18, 2017 11:12, "Dominik Stadler" <dominik.stad...@gmx.at> wrote:

> Hi,
>
> I don't see the logic of "we should not add new dependencies because our
> user do not upgrade", the ones that do upgrade would probably easily manage
> as we already have a few of them. The ones that do not upgrade are not
> interested in new stuff anyway, but are not affected even if we do add new
> ones.
>
> And did people complain about breaking changes as long as we listed them
> properly via @Deprecated and in release notes? I mostly remember some
> discussions when we did not properly document them and thus caught people
> off guard.
>
> If you want to look at some facts about version-usage and upgrade-speed you
> can take a look at https://centic9.github.io/github-version-statistics/ it
> has both the current version-distribution and timeseries since around
> October last year. According to this, open-source projects on Github (only
> the ones using Gradle or Maven) use version 3.14 most often, with the
> following top 5 as of today:
>
> 3.14: 343
> 3.9: 276
> 3.13: 188
> 3.15: 167
> 3.12: 166
>
> Please note that these are not full numbers, but only the first ~2000
> entries found as Github has a 1000-result-limit when searching for the two
> buildsystems.
> Back in October the numbers were 3.14: 353, 3.9: 310, 3.13: 209, so older
> versions do slowly fade out and newer ones actually get used by a fair
> share of the projects after some time.
>
> So 3.9 really is still very popular for some reason despite
> http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.
> apache.poi%22%20AND%20a%3A%22poi%22
> and http://mvnrepository.com/artifact/org.apache.poi/poi sorting the
> versions properly!
>
> Dominik.
>
> On Wed, Jan 18, 2017 at 3:45 AM, Allison, Timothy B. <talli...@mitre.org>
> wrote:
>
> > Y, I agree with Nick.  I'm slightly inclined to not using Commons IO to
> > avoid potential conflicts, but I defer to the more active devs :).
> >
> > We can't do the equivalent of a maven-shade-plugin in Ant, can we?  Looks
> > like maybe in gradle...but...
> >
> >
> > -Original Message-
> > From: Nick Burch [mailto:apa...@gagravarr.org]
> > Sent: Tuesday, January 17, 2017 3:35 PM
> > To: POI Developers List <dev@poi.apache.org>
> > Subject: Re: Using Apache Commons IO
> >
> > On Tue, 17 Jan 2017, Javen O'Neal wrote:
> > > In the spirit of "the best code is no code", how would you feel about
> > > replacing our endian classes and IOUtils with Apache Commons IO?
> > >
> > > The downside is that it adds a dependency.
> > > https://poi.apache.org/overview.html#components
> >
> > How many classes do we need? Do those classes include all the methods we
> > need, or are there gaps?
> >
> > (Having dealt with yet another StackOverflow question today from someone
> > stuck on a really old POI version, and knowing that the ones who make it
> to
> > StackOverflow are actually the better ones, I'd rather inline a few
> classes
> > / do nothing instead of adding a dependency that people can get
> > wrong)
> >
> > Nick
> >
> > -
> > 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
> >
> >
>

Using Apache Commons IO

[Javen O'Neal]

In the spirit of "the best code is no code", how would you feel about
replacing our endian classes and IOUtils with Apache Commons IO?

The downside is that it adds a dependency.
https://poi.apache.org/overview.html#components


https://commons.apache.org/proper/commons-io/javadocs/api-release/index.html?org/apache/commons/io/package-summary.html

Re: Build failed in Jenkins: POI-DSL-1.8 #44

[Javen O'Neal]

Is this a transient javadoc error? Or did the jenkins javadoc get built by
a different version of Java? I didn't touch the files that are have the
reported javadoc errors.

On Jan 12, 2017 05:18, "Apache Jenkins Server" 
wrote:

> See 
>
> Changes:
>
> [onealj] update changelog for bug 60260: contributions from Zero: Sheet
> shiftRow formula parse exception when named range refers to a sheet with a
> unicode sheet name
>
> [onealj] bug 60260: parse unicode sheet names
>
> --
> [...truncated 6757 lines...]
>   [javadoc]  java/org/apache/poi/xssf/usermodel/XSSFFormulaEvaluator.java>:30: error:
> self-closing element not allowed
>   [javadoc]  * Evaluates formula cells.
>   [javadoc]^
>   [javadoc]  java/org/apache/poi/xssf/usermodel/XSSFMap.java>:37: error: self-closing
> element not allowed
>   [javadoc]  * 
>   [javadoc]^
>   [javadoc]  java/org/apache/poi/xssf/usermodel/XSSFName.java>:146: error: tag not
> allowed here: 
>   [javadoc]  * 
>   [javadoc] ^
>   [javadoc]  java/org/apache/poi/xssf/usermodel/XSSFName.java>:165: error: unexpected
> end tag: 
>   [javadoc] * 
>   [javadoc]   ^
>   [javadoc]  java/org/apache/poi/xssf/usermodel/XSSFName.java>:36: error: tag not
> allowed here: 
>   [javadoc]  * 
>   [javadoc] ^
>   [javadoc] 100 errors
>   [javadoc] 100 warnings
>   [jar] Building jar:  job/POI-DSL-1.8/ws/build/dist/maven/poi-ooxml/poi-ooxml-3.
> 16-beta2-javadoc.jar>
>
> assemble:
>   [zip] Building zip:  job/POI-DSL-1.8/ws/build/dist/poi-bin-3.16-beta2-20170112.zip>
>   [tar] Building tar:  job/POI-DSL-1.8/44/artifact/build/dist/poi-bin-3.16-beta2-20170112.tar.gz>
>   [zip] Building zip:  job/POI-DSL-1.8/ws/build/dist/poi-src-3.16-beta2-20170112.zip>
>   [tar] Building tar:  job/POI-DSL-1.8/44/artifact/build/dist/poi-src-3.16-beta2-20170112.tar.gz>
>  [echo] Creating Maven POMs
>
> maven-poms:
>  [copy] Copying 6 files to  job/POI-DSL-1.8/ws/build/dist/maven>
>  [echo] Maven POMs are located in  job/POI-DSL-1.8/ws/build/dist>
>  [echo] Use ant dist-nexus to deploy the artifacts in the remote
> repository
>  [echo] Distribution located in  job/POI-DSL-1.8/ws/build/dist>
>  [echo] Use "ant dist-checksum" to create md5/sha1 checksums and GPG
> signatures
>
> findbugs:
>   [get] Destination already exists (skipping): <
> https://builds.apache.org/job/POI-DSL-1.8/ws/lib/
> findbugs-noUpdateChecks-3.0.1.zip>
> [unzip] Expanding:  findbugs-noUpdateChecks-3.0.1.zip> into  job/POI-DSL-1.8/ws/build/findbugs>
>  [findbugs] Executing findbugs FindBugsTask from ant task
>  [findbugs] Running FindBugs...
>  [findbugs] Java Result: 137
>  [findbugs] Output saved to build/findbugs.xml
>  [xslt] Transforming into  job/POI-DSL-1.8/ws/build>
>  [xslt] Processing  job/POI-DSL-1.8/ws/build/findbugs.xml> to  job/POI-DSL-1.8/44/artifact/build/findbugs.html>
>  [xslt] Loading stylesheet jar: org/job/POI-DSL-1.8/ws/build/findbugs/lib/findbugs.jar!/fancy-hist.xsl>
>  [xslt] : Error! Premature end of file.
>  [xslt] : Error! 
> com.sun.org.apache.xml.internal.utils.WrappedRuntimeException:
> Premature end of file.
>  [xslt] Failed to process null
>
> BUILD FAILED
> :2266:
> javax.xml.transform.TransformerException: 
> javax.xml.transform.TransformerException:
> com.sun.org.apache.xml.internal.utils.WrappedRuntimeException: Premature
> end of file.
> at com.sun.org.apache.xalan.internal.xsltc.trax.
> TransformerImpl.transform(TransformerImpl.java:749)
> at com.sun.org.apache.xalan.internal.xsltc.trax.
> TransformerImpl.transform(TransformerImpl.java:351)
> at org.apache.tools.ant.taskdefs.optional.TraXLiaison.
> transform(TraXLiaison.java:197)
> at org.apache.tools.ant.taskdefs.XSLTProcess.process(
> XSLTProcess.java:844)
> at org.apache.tools.ant.taskdefs.XSLTProcess.execute(
> XSLTProcess.java:434)
> at org.apache.tools.ant.UnknownElement.execute(
> UnknownElement.java:293)
> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at 

Re: [Bug 60519] Extractor for *SSF embeddings

[Javen O'Neal]

Sounds like the need is more urgent than timeline of spawning an
incubator project.

In that case, pick whichever project (Tika or POI) will make it
easiest to minimize the package, class, constructor, argument, and
return value dependency on the rest foster parent project so that it's
easier to move to incubator later.

If POI is the better fit, drop it in scratchpad and add an @Internal
annotation so that you're free to make breaking changes at any time.

On Thu, Jan 5, 2017 at 5:00 AM, Allison, Timothy B. <talli...@mitre.org> wrote:
> Thank you Andi and Javen!
>
> Javen,
>
>   I respect your point about "not limited to MSOffice documents".  My 
> selfish/Tika-ish goal in processing them, frankly, is only to extract 
> embedded documents and their metadata.  Andi's patch demonstrated the need to 
> handle the "feature" distinction btwn how Mac xls and Windows xls handle 
> embedded pdf files -- in Windows, the pdf is available as a standalone 
> embedded file, with an emf to represent the icon; in Mac, the emf contains 
> the original pdf (and graphics to represent the icon?)...in short, over on 
> Tika, we're currently not extracting the PDF from the Mac xls, but we are 
> from the Windows xls.
>
>   So, y, a robust read/write EMF parser/writer would make sense as a 
> standalone project in incubator.  However, I don't have the energy/time to do 
> much more than read-only for this one very small problem.  POI's scratchpad 
> or Tika are the two immediate targets that I could easily contribute to.  If 
> there's a need and someone has the time, we could move whatever code there is 
> for this one small task into a future incubator project.
>
>   I also respect your point about inviting bug reports that would distract us 
> from focusing on MSOffice documents.  Sounds like there's loose consensus to 
> put this in Tika for now, and if anyone wants to take it on, move it to 
> incubator?
>
>   Cheers,
>
>   Tim
>
>
> P.S. As a side note, I suspect there are some interesting metadata items that 
> we can pull out of EMFs... For example, I saw some text content of the PDF in 
> the EMF portion of the mac EMF.  I also saw some original paths for the 
> embedded file in the EMF.
>
> -Original Message-
> From: Javen O'Neal [mailto:one...@apache.org]
> Sent: Wednesday, January 4, 2017 8:05 PM
> To: POI Developers List <dev@poi.apache.org>
> Subject: Re: [Bug 60519] Extractor for *SSF embeddings
>
> What about an Apache incubator project for reading and writing EMF(+) files?
>
> On Jan 4, 2017 2:53 PM, "Andreas Beeker" <kiwiwi...@apache.org> wrote:
>
>> Hi Tim,
>>
>> every now and then I play with the idea to provide an EMF parser like
>> the WMF parser, to render images inside slideshows. This could be of
>> course used to extract other content too.
>> The simplest way would be, to adapt the FreeHep library, but its GPL
>> licensed ... :(
>>
>> So for extracting embedded content, I guess it's not so difficult to
>> generically parse the emf(+) records and only handle the interesting ones.
>> This limited functionality should be in scratchpad or the example classes.
>> If it is not a huge code chunk, it could be in the Extractor class -
>> otherwise I would like to see it in Tika ...
>>
>> Andi
>>
>> -
>> 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: [Bug 60519] Extractor for *SSF embeddings

[Javen O'Neal]

What about an Apache incubator project for reading and writing EMF(+) files?

On Jan 4, 2017 2:53 PM, "Andreas Beeker"  wrote:

> Hi Tim,
>
> every now and then I play with the idea to provide an EMF parser like the
> WMF parser, to render images inside slideshows. This could be of course
> used to extract other content too.
> The simplest way would be, to adapt the FreeHep library, but its GPL
> licensed ... :(
>
> So for extracting embedded content, I guess it's not so difficult to
> generically parse the emf(+) records and only handle the interesting ones.
> This limited functionality should be in scratchpad or the example classes.
> If it is not a huge code chunk, it could be in the Extractor class -
> otherwise I would like to see it in Tika ...
>
> Andi
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
> For additional commands, e-mail: dev-h...@poi.apache.org
>
>

RE: [Bug 60519] Extractor for *SSF embeddings

[Javen O'Neal]

The Windows Enhanced Metafile format isn't specific to Microsoft Office
documents, so it probably doesn't belong in POI.
Even if we advertise this as rudimentary support only, it would likely
generate bug reports for POI, detracting from the time we spend on reading
and writing Office documents.

On the same token, POI doesn't maintain code to work with BMP or SVG
content, since there are other libraries that can work with this.

My vote is for a different project to support EMF files. This has an added
benefit of making EMF support for other Java applications without adding
POI as a dependency.

On Jan 4, 2017 11:13 AM, "Allison, Timothy B."  wrote:

> Andi,
>   I like what you've done with the patch for this issue.
>
> All,
>   Is it worthwhile adding a rudimentary EMF parser to POI?  It might help
> us explore what other "full docs" are stuffed inside EMF like the PDFs that
> you found.  I hacked out a version for Tika (locally), but I think this
> would be better in POI.  WDYT?
>
>  Cheers,
>
>  Tim
>
> -Original Message-
> From: bugzi...@apache.org [mailto:bugzi...@apache.org]
> Sent: Monday, December 26, 2016 6:06 PM
> To: dev@poi.apache.org
> Subject: [Bug 60519] Extractor for *SSF embeddings
>
> https://bz.apache.org/bugzilla/show_bug.cgi?id=60519
>
> --- Comment #1 from Andreas Beeker  --- The test
> data for EMF with embedded PDF can be found under
> https://people.apache.org/~kiwiwings/Basic_Expense_Template_2011.xls
>
> --
> 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
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
> For additional commands, e-mail: dev-h...@poi.apache.org
>
>

Re: [GitHub] poi pull request #44: update java doc for CellStyle#setDataFormat

[Javen O'Neal]

Thanks for the pull request, sixinli! Merged in svn r1777260.

On Jan 3, 2017 23:00, "asfgit"  wrote:

> Github user asfgit closed the pull request at:
>
> https://github.com/apache/poi/pull/44
>
>
> ---
> If your project is set up for it, you can reply to this email and have your
> reply appear on GitHub as well. If your project does not have this feature
> enabled and wishes so, or if the feature is enabled but not working, please
> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
> with INFRA.
> ---
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
> For additional commands, e-mail: dev-h...@poi.apache.org
>
>

Re: Too much memory is used by a hyperlink in a spreadsheet

[Javen O'Neal]

Thanks for the submission. I have opened bug 60416 [1] to work on this
and committed your patch.

Discussion can take place either on the bug or on the
dev@poi.apache.org mailing list. I have bcc'd u...@poi.apache.org out
of the email responses.

[1] https://bz.apache.org/bugzilla/show_bug.cgi?id=60416

On Thu, Nov 24, 2016 at 3:24 AM, Dmitry Katsubo  wrote:
> Dear POI community,
>
> I am trying to use SXSSFWorkbook (streaming version of workbook) to generate 
> XLSX spreadsheet with many rows and hyperlinks in the cells. It turned out 
> that effective streaming of such document is not possible, as hyperlinks are 
> accumulated in XSSFSheet#hyperlinks (see [1]). It's clear why this is 
> necessary:  XML element goes after  in , so 
> they need to be somehow preserved until all data rows are written. However it 
> turned out that each hyperlink is 2KB size, while the "useful" data (the 
> string link itself) is about 300 bytes (75% memory overhead). For document 
> with 6 hyperlinks, the memory used is 132MB (see attached 
> poi-hyperlink-dump.png). The most of memory is consumed by Cur$Locations 
> which has 7 arrays, 32 elements each, consuming 1KB in total (see attached 
> poi-hyperlink-dump-detailed.png). The stack trace is the following:
>
> Thread [main] (Suspended (breakpoint at line 493 in 
> org.apache.xmlbeans.impl.store.Cur$Locations))
> 
> org.apache.xmlbeans.impl.store.Cur$Locations.(org.apache.xmlbeans.impl.store.Locale)
>  line: 493
> 
> org.apache.xmlbeans.impl.store.Locale.(org.apache.xmlbeans.SchemaTypeLoader,
>  org.apache.xmlbeans.XmlOptions) line: 169
> 
> org.apache.xmlbeans.impl.store.Locale.getLocale(org.apache.xmlbeans.SchemaTypeLoader,
>  org.apache.xmlbeans.XmlOptions) line: 241
> 
> org.apache.xmlbeans.impl.store.Locale.newInstance(org.apache.xmlbeans.SchemaTypeLoader,
>  org.apache.xmlbeans.SchemaType, org.apache.xmlbeans.XmlOptions) line: 592
> 
> org.apache.xmlbeans.impl.schema.SchemaTypeLoaderImpl(org.apache.xmlbeans.impl.schema.SchemaTypeLoaderBase).newInstance(org.apache.xmlbeans.SchemaType,
>  org.apache.xmlbeans.XmlOptions) line: 198
> 
> org.apache.poi.POIXMLTypeLoader.newInstance(org.apache.xmlbeans.SchemaType, 
> org.apache.xmlbeans.XmlOptions) line: 84
> 
> org.openxmlformats.schemas.spreadsheetml.x2006.main.CTHyperlink$Factory.newInstance()
>  line: not available
> 
> org.apache.poi.xssf.usermodel.XSSFHyperlink.(org.apache.poi.common.usermodel.HyperlinkType)
>  line: 60
> 
> org.apache.poi.xssf.usermodel.XSSFCreationHelper.createHyperlink(org.apache.poi.common.usermodel.HyperlinkType)
>  line: 78
> 
> org.apache.poi.xssf.streaming.SXSSFCreationHelper.createHyperlink(org.apache.poi.common.usermodel.HyperlinkType)
>  line: 83
>
> By looking into tacktrace one can see that there is chance to optimize memory 
> in Locale#getLocale() by taking advantage of 
> options.hasOption(USE_SAME_LOCALE). However this option is not documented – 
> what could be the side effects?
>
> Another opportunity is to refactor XSSFHyperlink so that it does not create 
> CTHyperlink immediately but postpones that until that is really needed 
> (SXSSFWorkbook#write() is called), more specifically, when 
> XSSFHyperlink#getCTHyperlink() is called. However SXSSFCell#setHyperlink() 
> misuses this method [3] in a sense that it should use API of XSSFHyperlink 
> the same way as XSSFCell#setHyperlink() does (see SXSSFCell.java.patch).
>
> Summarizing above I would say that the following could be improved right now:
>
> * Document USE_SAME_LOCALE option. Provide a description of what could go 
> wrong if this options is used, especially when used in conjunction with 
> UNSYNCHRONIZED. Also the option assumes that Locale object could be somehow 
> instantiated but it's constructor is private and one cannot do something like 
> POIXMLTypeLoader.DEFAULT_XML_OPTIONS.put(Locale.USE_SAME_LOCALE, 
> Locale.getLocale(XmlBeans.getContextTypeLoader(), 
> POIXMLTypeLoader.DEFAULT_XML_OPTIONS));
> * Apply minor correction to documentation [4]:
>there are still things that still may consume a large amount of memory 
> based on which features you are using, e.g. merged regions, comments, ...
>there are still things that still may consume a large amount of memory 
> based on which features you are using, e.g. merged regions, hyperlinks, 
> comments, ...
> * Apply the attached SXSSFCell.java.patch.
>
> More advanced improvement of SXSSF would be to dump all problematic objects 
> (regions, hyperlinks, comments, ...) into temporary files and then merge them 
> into destination XSLX spreadsheet – then it would be a real streaming.
>
> POI v3.15. Links are to POI 3.12, but there are no conceptual differences.
>
> [1] 
> http://grepcode.com/file/repo1.maven.org/maven2/org.apache.poi/poi-ooxml/3.12/org/apache/poi/xssf/usermodel/XSSFSheet.java#137
> [2] 
> 

Re: svn commit: r1771220 - in /poi/site: publish/download.html src/documentation/content/xdocs/download.xml

[Javen O'Neal]

Is this sentence not enough?

These builds should not be used in production: they
are only intended for use by developers
to help with resolving bugs and evaluating new features.

http://svn.apache.org/viewvc/poi/site/publish/download.html?r1=1771220=1771219=1771220_format=l

On Thu, Nov 24, 2016 at 12:24 PM, Nick Burch  wrote:
> On Thu, 24 Nov 2016, one...@apache.org wrote:
>>
>> URL: http://svn.apache.org/viewvc?rev=1771220=rev
>> Log:
>> remove snarky disclaimer
>>
>> The POI nightly builds are run on the > href="https://builds.apache.org/view/POI/;>Jenkins continuous
>> integration server.
>> - Note that these are not officially verified builds and they are not
>> endorsed or even supported by the POI team.
>>  
>
>
> We're not supposed to direct "normal" users to nightly builds, see
> http://www.apache.org/dev/release.html#host-rc . So, some sort of disclaimer
> and warning is officially required
>
> Nick
>
> -
> 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: Interesting question on SO

[Javen O'Neal]

Looks like there is at least one other non-Apache package using the
org.apache.poi namespace. [1]

I would approach this from a friendly direction first.

I'm assuming they needed an o.a.p namespace so they would have access to
protected and package-private methods and variables. The alternative is to
fork POI and elevate the visibility of the classes, functions, and
variables that they need to access. The disadvantage of a forked project is
high overhead to keep it synchronized with the upstream project. This would
be messy if another

I like the idea of reaching out to these developers to see if they're
willing to donate some of their code under ASL 2.0. I'm guessing most of
this would be elevating visibility of private, package-private, and
protected methods, as well as adding some getters and setters. Other
changes would be adding a converters interface that they could implent or
extend.

Obviously we aren't interested in code that cannot be ASL 2.0 licensed,
such as the iTextPdf dependency.

The goal would be to allow these projects to use their own namespace
without needing to maintain a fork of POI.

[1] http://search.maven.org/#search%7Cga%7C1%7Corg.apache.poi

On Nov 21, 2016 14:57, "Nick Burch"  wrote:

> On Mon, 21 Nov 2016, Murphy, Mark wrote:
>
>> http://stackoverflow.com/questions/40723370/was-opensagres-
>> allowed-to-use-apache-poi-like-packages
>>
>> Does ASF defend its package names, or do we just ignore these kinds of
>> things and folks use them at their own peril?
>>
>
> I had a quick look at http://apache.org/foundation/marks/ but couldn't
> see anything there about java or maven package names. I have a feeling
> there is something somewhere that I saw a few years ago...
>
> If you have a bit of time, would you mind asking on trademarks@ [1] for
> advice / pointers?
>
> Nick
>
> [1] http://www.apache.org/foundation/marks/contact
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
> For additional commands, e-mail: dev-h...@poi.apache.org
>
>