[jira] [Commented] (XMLBEANS-540) Prevent trim of elements when pretty print is used

[Greg Woolsey (JIRA)]

[ 
https://issues.apache.org/jira/browse/XMLBEANS-540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819751#comment-16819751
 ] 

Greg Woolsey commented on XMLBEANS-540:
---

How does this not break desired leading spaces?  Sometimes our users indent 
cell values in XLSX files by manually entering spaces in the cell value.  This 
looks like it would lose those, thus reading the document incorrectly?

> Prevent trim of elements when pretty print is used
> --
>
> Key: XMLBEANS-540
> URL: https://issues.apache.org/jira/browse/XMLBEANS-540
> Project: XMLBeans
>  Issue Type: Wish
>Reporter: Srecko Mandelj
>Priority: Major
>
> It would be niice to resolve the issue described in XMLBEANS-22. I'm using a 
> local implementation as suggested by [~mattin] in the last comment. Is it 
> possible to make this a permanent fix in one of the future releases? I had 
> problems analyzing logs since space inside element sometimes causes errors in 
> business logic (like the example when search with space fails).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[ANNOUNCE] Apache POI 4.1.0 released

[Greg Woolsey]

The Apache POI project is pleased to announce the release of POI 4.1.0.
Featured are a handful of new areas of functionality, and numerous bug fixes.

See the downloads page for binary and source distributions:
https://poi.apache.org/download.html

Release Notes

Changes

The most notable changes in this release are:

* Improved support/fixes for Java 9+ and IBM JVM
* New EMF renderer and support of SVG images in XSLF
* Security, stability and memory/resource handling improvements
* Various bug fixes across function and conditional format rule evaluation
* Upgrade to XMLBeans 3.1.0
* Upgrade to Bouncycastle 1.61
* Upgrade to Curvesapi 1.06
* Upgrade to Commons-Codec 1.12
* Upgrade to Commons-Collections4 4.3
* Upgrade to XMLSec 2.1.2

A full list of changes is available in the change log:
https://poi.apache.org/changes.html.
People interested should also follow the dev mailing list to track
further progress.

Release Contents


This release comes in two forms:
 - pre-built binaries containing compiled versions of all Apache POI
components and documentation
   (poi-bin-4.1.0-20190412.zip or poi-bin-4.1.0-20190412.tar.gz)
 - source archive you can build POI from (poi-src-4.1.0-20190412.zip
or poi-src-4.1.0-20190412.tar.gz)
  Unpack the archive and use the following command to build all POI
components with Apache Ant 1.8+ and JDK 1.8 or higher:

  ant jar

 Pre-built versions of all POI components are also available in the
central Maven repository
 under Group ID "org.apache.poi" and Version "4.1.0"

All release artifacts are accompanied by MD5 checksums and PGP signatures
that you can use to verify the authenticity of your download.
The public key used for the PGP signature can be found at
*https://www.apache.org/dist/poi/KEYS
*

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


On behalf of the Apache POI PMC,
Greg

[ANNOUNCE] Apache POI 4.1.0 released

[Greg Woolsey]

The Apache POI project is pleased to announce the release of POI 4.1.0.
Featured are a handful of new areas of functionality, and numerous bug fixes.

See the downloads page for binary and source distributions:
https://poi.apache.org/download.html

Release Notes

Changes

The most notable changes in this release are:

* Improved support/fixes for Java 9+ and IBM JVM
* New EMF renderer and support of SVG images in XSLF
* Security, stability and memory/resource handling improvements
* Various bug fixes across function and conditional format rule evaluation
* Upgrade to XMLBeans 3.1.0
* Upgrade to Bouncycastle 1.61
* Upgrade to Curvesapi 1.06
* Upgrade to Commons-Codec 1.12
* Upgrade to Commons-Collections4 4.3
* Upgrade to XMLSec 2.1.2

A full list of changes is available in the change log:
https://poi.apache.org/changes.html.
People interested should also follow the dev mailing list to track
further progress.

Release Contents


This release comes in two forms:
 - pre-built binaries containing compiled versions of all Apache POI
components and documentation
   (poi-bin-4.1.0-20190412.zip or poi-bin-4.1.0-20190412.tar.gz)
 - source archive you can build POI from (poi-src-4.1.0-20190412.zip
or poi-src-4.1.0-20190412.tar.gz)
  Unpack the archive and use the following command to build all POI
components with Apache Ant 1.8+ and JDK 1.8 or higher:

  ant jar

 Pre-built versions of all POI components are also available in the
central Maven repository
 under Group ID "org.apache.poi" and Version "4.1.0"

All release artifacts are accompanied by MD5 checksums and PGP signatures
that you can use to verify the authenticity of your download.
The public key used for the PGP signature can be found at
*https://www.apache.org/dist/poi/KEYS
*

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


On behalf of the Apache POI PMC,
Greg

[ANNOUNCE] Apache POI 4.1.0 released

[Greg Woolsey]

The Apache POI project is pleased to announce the release of POI 4.1.0.
Featured are a handful of new areas of functionality, and numerous bug fixes.

See the downloads page for binary and source distributions:
https://poi.apache.org/download.html

Release Notes

Changes

The most notable changes in this release are:

* Improved support/fixes for Java 9+ and IBM JVM
* New EMF renderer and support of SVG images in XSLF
* Security, stability and memory/resource handling improvements
* Various bug fixes across function and conditional format rule evaluation
* Upgrade to XMLBeans 3.1.0
* Upgrade to Bouncycastle 1.61
* Upgrade to Curvesapi 1.06
* Upgrade to Commons-Codec 1.12
* Upgrade to Commons-Collections4 4.3
* Upgrade to XMLSec 2.1.2

A full list of changes is available in the change log:
https://poi.apache.org/changes.html.
People interested should also follow the dev mailing list to track
further progress.

Release Contents


This release comes in two forms:
 - pre-built binaries containing compiled versions of all Apache POI
components and documentation
   (poi-bin-4.1.0-20190412.zip or poi-bin-4.1.0-20190412.tar.gz)
 - source archive you can build POI from (poi-src-4.1.0-20190412.zip
or poi-src-4.1.0-20190412.tar.gz)
  Unpack the archive and use the following command to build all POI
components with Apache Ant 1.8+ and JDK 1.8 or higher:

  ant jar

 Pre-built versions of all POI components are also available in the
central Maven repository
 under Group ID "org.apache.poi" and Version "4.1.0"

All release artifacts are accompanied by MD5 checksums and PGP signatures
that you can use to verify the authenticity of your download.
The public key used for the PGP signature can be found at
https://svn.apache.org/repos/asf/poi/tags/REL_4_1_0/KEYS

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


On behalf of the Apache POI PMC,
Greg

New JavaDoc folder for 4.1.x?

[Greg Woolsey]

Per the release-guide.txt and what I see on the site currently, I think I
need to build javadoc and move it to a new folder, plus updating links in
the apidocs/index.xml file.

That's what I'm working on today, unless anyone has a strong opinion
otherwise.

Re: [VOTE] Apache POI 4.1.0 release (RC3)

[Greg Woolsey]

Vote passes with 5 +1 and 1 +0 votes.

I'll begin the release process.  Thank you all for your help, checks, and
discussion.

Greg

On Mon, Apr 8, 2019 at 2:12 PM Tim Allison  wrote:

> Hi Andi,
>
> Y, to be clear, I really like what you’ve done and it is all a bunch
> cleaner than my earlier stuff; I wasn’t at all questioning the design. The
> question was more to back compat. There was quite a bit of red when I made
> the upgrade and before I modernized our code on Tika.
>
> As long as we’re all on board, off we go!
>
> As to my two recent commits, please let me know if there are better options
> for 4.1.1.
>
> Thank you!
>
> Cheers,
>
>   Tim
>
> On Mon, Apr 8, 2019 at 4:55 PM Andreas Beeker 
> wrote:
>
> > Hi Tim,
> >
> > I've made that changes on purpose, as I wanted to make the EMF API
> similar
> > to the WMF one.
> >
> > > oap.hemf.extractor.HemfExtractor -> oap.hemf.usermodel.HemfPicture
> > All (?) our user models are called by their content and being similar to
> > WMF, I had to rename the class.
> >
> > > HwmfRecord.getRecordType() -> getWmfRecordType()
> > The EMF records extends the WMF records, so this makes it more clear what
> > kind of record type to ask for.
> >
> > > oap.hemf.record.AbstractHemfComment -> oap.hemf.record.hemf.Comment
> > > oap.hemf.record.HemfRecord -> oap.h.r.emf.HemfRecord
> > >
> > As both sets (emf and emfplus) contain quite a few records, I've decided
> > to split their packages.
> >
> > I'm now looking at the other (not yet resolved) issues you opened.
> >
> > Andi
> >
> >
> >
>

Re: [VOTE] Apache POI 4.1.0 release (RC3)

[Greg Woolsey]

It is my understanding these changes were part of what motivated the
version change from initial 4.0.2 to 4.1.0, but that's not an area of code
I'm familiar with.

On Mon, Apr 8, 2019 at 6:07 AM Tim Allison  wrote:

> Are we ok with the backward incompatibilities in EMF...These are just
> a few.  I realize these classes are @Internal, and the updates look
> great.
>
> HwmfRecord.getRecordType() -> getWmfRecordType()
>
> oap.hemf.record.AbstractHemfComment -> oap.hemf.record.hemf.Comment
> oap.hemf.record.HemfRecord -> oap.h.r.emf.HemfRecord
> oap.hemf.record.HemfRecord -> oap.h.r.emf.HemfRecord
>
> oap.hemf.extractor.HemfExtractor -> oap.hemf.usermodel.HemfPicture
>
> On Sun, Apr 7, 2019 at 8:27 AM Yegor Kozlov  wrote:
> >
> > +1
> >
> > Looks good to me
> >
> > сб, 6 апр. 2019 г., 2:32 Greg Woolsey :
> >
> > > I've prepared artifacts for Apache POI release 4.1.0 (RC3).
> > >
> > > Notable changes since 4.0.1:
> > >
> > > * Improved support/fixes for Java 9+ and IBM JVM
> > > * New EMF renderer and support of SVG images in XSLF
> > > * Security, stability and memory/resource handling improvements
> > > * Various bug fixes across function and conditional format rule
> evaluation
> > > * Upgrade to XMLBeans 3.1.0
> > > * Upgrade to Bouncycastle 1.61
> > > * Upgrade to Curvesapi 1.06
> > > * Upgrade to Commons-Codec 1.12
> > > * Upgrade to Commons-Collections4 4.3
> > > * Upgrade to XMLSec 2.1.2
> > >
> > > https://dist.apache.org/repos/dist/dev/poi/4.1.0-RC3/
> > >
> > > All tests pass.
> > > ASC signatures verify, key is in the KEYS file in /dist/dev/poi/.
> > > SHA* hashes match files.
> > >
> > > Latest regression run results looked good, Dominik was going to kick
> off
> > > another (probably still running) to verify some last minute changes
> cleared
> > > up some new errors found from augmented regression checks.
> > >
> > > Please vote on these artifacts.
> > >
> > > The vote is open until April 8, planning release announcement late that
> > > day.
> > >
> > > I'm +1 at this point, contents match 4.0.1, with updated dependency
> > > versions.
> > >
> > > Greg
> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
> For additional commands, e-mail: dev-h...@poi.apache.org
>
>

[VOTE] Apache POI 4.1.0 release (RC3)

[Greg Woolsey]

I've prepared artifacts for Apache POI release 4.1.0 (RC3).

Notable changes since 4.0.1:

* Improved support/fixes for Java 9+ and IBM JVM
* New EMF renderer and support of SVG images in XSLF
* Security, stability and memory/resource handling improvements
* Various bug fixes across function and conditional format rule evaluation
* Upgrade to XMLBeans 3.1.0
* Upgrade to Bouncycastle 1.61
* Upgrade to Curvesapi 1.06
* Upgrade to Commons-Codec 1.12
* Upgrade to Commons-Collections4 4.3
* Upgrade to XMLSec 2.1.2

https://dist.apache.org/repos/dist/dev/poi/4.1.0-RC3/

All tests pass.
ASC signatures verify, key is in the KEYS file in /dist/dev/poi/.
SHA* hashes match files.

Latest regression run results looked good, Dominik was going to kick off
another (probably still running) to verify some last minute changes cleared
up some new errors found from augmented regression checks.

Please vote on these artifacts.

The vote is open until April 8, planning release announcement late that day.

I'm +1 at this point, contents match 4.0.1, with updated dependency
versions.

Greg

Re: Ready for 4.1.0 release?

[Greg Woolsey]

Ignore the RC2, I will be doing an RC3 after some meetings.  Discovered my
FORREST_HOME was in Cygwin/Linux path format, which broke documentation
creation, meaning the RC2 artifacts are missing site and other
documentation folders/files.

Turns out the XMLBeans build needs the Cygwin format, but POI build has
platform-specific content that expect the format to match the OS.

Sorry for the email/commit spam, I think I'm close now to working out the
last kinks in my understanding and environment.

Greg

On Fri, Apr 5, 2019 at 2:08 AM kiwiwings  wrote:

> Hi Greg,
>
> probably my private mail didn't make it through.
> I've updated the openpgp library - we also have a Jenkins job [1] for it.
>
> Please update the openpgp link to [2]
>
> Sorry for not updating the link earlier.
>
> Andi
>
> [1] https://builds.apache.org/job/POI-Commons-OpenPGP/
> [2]
>
> https://repository.apache.org/content/groups/snapshots/org/apache/commons/commons-openpgp/1.0-SNAPSHOT/commons-openpgp-1.0-20190121.221905-12.jar
>
>
>
> --
> 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: Ready for 4.1.0 release?

[Greg Woolsey]

I've prepared a 4.1.0 (RC1) and commited it to the dist/dev/poi repo,
however before I bother calling a vote, I wanted to ask about an issue I
had with running

release-prep3

It failed to sign the files until I downgraded to BouncyCastle 1.51 due to
commons-openpgp, which is stuck on BouncyCastle 1.51 or older because it
uses an API method removed in 1.52.

I updated the dsig.bouncycastle* and dist.bouncycastle* properties to 1.51
in build.xml and it worked, but I think that reverts the build dependency
also then, not just the signing?  Updating just dsig.bouncycastle*
properties puts both versions in the build/release/compile-lib folder, and
the 1.61 version gets loaded when I run ant.

Maybe it's just jetlag, but I'm unclear on what needs changing to make sure
only the signing step uses the 1.51 libs, and the rest uses the latest
version.

I think the RC artifacts are fine, but let me know if we should straighten
this out first, and possibly do an RC2.

It looks like the build.xml referenced 1.60 for the 4.0.2 release, but the
BC source history shows the method in question disappeared years ago.

Here's the stack I got with 1.61 in the path, for reference.  Note the
single-arg constructor doesn't exist in 1.61:

dist-checksum:
  [get] Destination already exists (skipping):
\svn\ApachePOI\build\release\compile-lib\bcprov-ext-jdk15on-1.61.jar
  [get] Destination already exists (skipping):
\svn\ApachePOI\build\release\compile-lib\bcpg-jdk15on-1.61.jar
  [get] Destination already exists (skipping):
\svn\ApachePOI\build\release\compile-lib\commons-openpgp-1.0-SNAPSHOT.jar

BUILD FAILED
\svn\ApachePOI\build.xml:2651: The following error occurred while executing
this line:
\svn\ApachePOI\build\release\build.xml:2410: java.lang.NoSuchMethodError:
org.bouncycastle.openpgp.PGPObjectFactory.(Ljava/io/InputStream;)V
at
org.apache.commons.openpgp.BouncyCastleKeyRing.addSecretKeyRing(BouncyCastleKeyRing.java:86)
at
org.apache.commons.openpgp.BouncyCastleKeyRing.(BouncyCastleKeyRing.java:58)
at
org.apache.commons.openpgp.ant.OpenPgpSignerTask.execute(OpenPgpSignerTask.java:139)
at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:293)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:435)
at org.apache.tools.ant.Target.performTasks(Target.java:456)
at
org.apache.tools.ant.Project.executeSortedTargets(Project.java:1405)
at
org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
at org.apache.tools.ant.Project.executeTargets(Project.java:1260)
at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:441)
at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:293)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:435)
at org.apache.tools.ant.Target.performTasks(Target.java:456)
at
org.apache.tools.ant.Project.executeSortedTargets(Project.java:1405)
at org.apache.tools.ant.Project.executeTarget(Project.java:1376)
at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1260)
at org.apache.tools.ant.Main.runBuild(Main.java:857)
at org.apache.tools.ant.Main.startAnt(Main.java:236)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:287)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:113)

On Thu, Apr 4, 2019 at 11:02 AM Greg Woolsey  wrote:

> Changed the build.xml URL.
>
> On Thu, Apr 4, 2019 at 10:56 AM Dominik Stadler 
> wrote:
>
>> Try using https://nexus.pentaho.org/, seems the repository moved some
>> time
>> ago.
>>
>> I'll add the relevant fetch-target to the build-target "jenkins" so it is
>> executed in CI and we find such issues earlier.
>>
>> Dominik.
>>
>> On Thu, Apr 4, 2019 at 6:49 PM Greg Woolsey 
>> wrote:
>>
>> > I get "Access Denied" when I try to run release-prep1 when it tries to
>> > retrieve this file:
>> >
>> > Can't get
>> >
>> >
>> http://repo.pentaho.

[ANNOUNCE] Apache XMLBeans 3.1.0 released

[Greg Woolsey]

The Apache POI project is pleased to announce the release of Apache
XMLBeans 3.1.0.
This is the 4th release since the POI team took over the ownership of
XMLBeans.

Featured are a handful of memory, stability, coverage, and security fixes.
The release package organization has also been updated to align better with
POI and other Apache project deliverables.

See the downloads page for binary and source distributions:
https://xmlbeans.apache.org/download

Note: The Apache Software Foundation uses an extensive mirroring network for
distributing releases. It is possible that the mirror you are using may not
have replicated the release yet. If that is the case, please try another
mirror.
This also goes for Maven access.



Release Notes

Changes

The most notable changes in this release are:

* update build and deployment artifacts to standardize naming and remove
unused items
* XMLBEANS-502: Allow to clear all ThreadLocals from the current thread
* XMLBEANS-503: Allow to specify -nowarn in the Ant task
* XMLBEANS-537: Add missing StscState.end() to avoid memory leaks
* XMLBEANS-532: Streamline build.xml and update tests to Junit4
* XMLBEANS-531: Fix schema gen of attributes
* XMLBEANS-530: Allow namespaces of XmlOptions to be passed to the XQuery
engine
* XMLBEANS-529: Format xmlobjects to the correct string representation on
XPath access
* XMLBEANS-528: Allow document locator to be set after initialization
* XMLBEANS-527: Rename shell script directory, to align on typical
directory layout
* XMLBEANS-526: Fix issue with loading META-INF/services files
* XMLBEANS-538: fix issue with parsing DOM with DTD

A full list of changes is available in the change log:
https://xmlbeans.apache.org/status.html

People interested should also follow the *POI* dev mailing list to track
further progress.



Release Contents


This release comes in two forms:
 - pre-built binaries containing compiled versions of all Apache XMLBeans
components and documentation
   (xmlbeans-bin-3.1.0.zip or xmlbeans-bin-3.1.0.tgz)
 - source archive you can build XMLBeans from (xmlbeans-src-3.1.0.zip or
xmlbeans-src-3.1.0.tgz)
  Unpack the archive and use the following command to build all XMLBeans
components with Apache Ant 1.8+ and JDK 1.6 or higher:

  ant deploy

 Pre-built versions of all XMLBeans components are also available in the
central Maven repository
 under Group ID "org.apache.xmlbeans" and Version "3.1.0"

All release artifacts are accompanied by SHA checksums and PGP signatures
that you can use to verify the authenticity of your download.
The public key used for the PGP signature can be found at

https://www.apache.org/dist/poi/KEYS


About Apache XMLBeans
---

XMLBeans is a tool that allows access to the full power of XML in a Java
friendly way.
The idea is to take advantage of the richness and features of XML and XML
Schema
and have these features mapped as naturally as possible to the equivalent
Java
language and typing constructs.

See https://xmlbeans.apache.org for more details


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


On behalf of the Apache POI PMC,
Greg

Re: Returned post for annou...@apache.org

[Greg Woolsey]

Well that makes sense!  I thought I cribbed things from the POI
release-guide.txt in building a similar document for XMLBeans, so perhaps I
missed something or the POI guide is out of date (I've found a few things
like references to Java 6).  I'll go do better research and try again.

On Thu, Apr 4, 2019 at 6:32 PM Dave Fisher  wrote:

> You don’t have links to the download or download page. Take a look at
> previous announcements.
>
> Sent from my iPhone
>
> > On Apr 4, 2019, at 6:09 PM, Greg Woolsey  wrote:
> >
> > Anyone see anything wrong with my XMLBeans announcement below, before I
> try
> > again?  Looks right to me.  My Apache account is valid, it's what I use
> to
> > commit and use this dev list :)
> >
> > Greg
> >
> >
> > -- Forwarded message -
> > From: 
> > Date: Thu, Apr 4, 2019 at 3:58 PM
> > Subject: Returned post for annou...@apache.org
> > To: 
> >
> >
> >
> > Hi! This is the ezmlm program. I'm managing the
> > annou...@apache.org mailing list.
> >
> > I'm sorry, the list moderators for the announce list
> > have failed to act on your post. Thus, I'm returning it to you.
> > If you feel that this is in error, please repost the message
> > or contact a list moderator directly.
> >
> > --- Enclosed, please find the message you sent.
> >
> >
> >
> >
> >
> > -- Forwarded message --
> > From: Greg Woolsey 
> > To: POI Users List , POI Developers List <
> > dev@poi.apache.org>, gene...@poi.apache.org, annou...@apache.org
> > Cc:
> > Bcc:
> > Date: Sat, 30 Mar 2019 10:54:58 -0700
> > Subject: [ANNOUNCE] Apache XMLBeans 3.1.0 released
> > The Apache POI PMC is pleased to announce the release of Apache XMLBeans
> > 3.1.0.
> >
> > Apache XMLBeans is a technology for accessing XML by binding it to Java
> > types.
> >
> > For detailed changes in this release, refer to the release notes [1] and
> > the changelog [2].
> >
> > Thank you to all our contributors for making this release possible.
> >
> > On behalf of the Apache POI PMC,
> >
> > Greg Woolsey
> >
> > [1] Release notes:
> >
> https://www.apache.org/dyn/closer.lua/poi/xmlbeans/release/dev/RELEASE-NOTES-3.1.0.txt
> > [2] Changelog: https://xmlbeans.apache.org/status.html#rel_310
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
> For additional commands, e-mail: dev-h...@poi.apache.org
>
>

Fwd: Returned post for annou...@apache.org

[Greg Woolsey]

Anyone see anything wrong with my XMLBeans announcement below, before I try
again?  Looks right to me.  My Apache account is valid, it's what I use to
commit and use this dev list :)

Greg


-- Forwarded message -
From: 
Date: Thu, Apr 4, 2019 at 3:58 PM
Subject: Returned post for annou...@apache.org
To: 



Hi! This is the ezmlm program. I'm managing the
annou...@apache.org mailing list.

I'm sorry, the list moderators for the announce list
have failed to act on your post. Thus, I'm returning it to you.
If you feel that this is in error, please repost the message
or contact a list moderator directly.

--- Enclosed, please find the message you sent.





-- Forwarded message --
From: Greg Woolsey 
To: POI Users List , POI Developers List <
dev@poi.apache.org>, gene...@poi.apache.org, annou...@apache.org
Cc:
Bcc:
Date: Sat, 30 Mar 2019 10:54:58 -0700
Subject: [ANNOUNCE] Apache XMLBeans 3.1.0 released
The Apache POI PMC is pleased to announce the release of Apache XMLBeans
3.1.0.

Apache XMLBeans is a technology for accessing XML by binding it to Java
types.

For detailed changes in this release, refer to the release notes [1] and
the changelog [2].

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

On behalf of the Apache POI PMC,

Greg Woolsey

[1] Release notes:
https://www.apache.org/dyn/closer.lua/poi/xmlbeans/release/dev/RELEASE-NOTES-3.1.0.txt
[2] Changelog: https://xmlbeans.apache.org/status.html#rel_310

Re: Ready for 4.1.0 release?

[Greg Woolsey]

Changed the build.xml URL.

On Thu, Apr 4, 2019 at 10:56 AM Dominik Stadler 
wrote:

> Try using https://nexus.pentaho.org/, seems the repository moved some time
> ago.
>
> I'll add the relevant fetch-target to the build-target "jenkins" so it is
> executed in CI and we find such issues earlier.
>
> Dominik.
>
> On Thu, Apr 4, 2019 at 6:49 PM Greg Woolsey 
> wrote:
>
> > I get "Access Denied" when I try to run release-prep1 when it tries to
> > retrieve this file:
> >
> > Can't get
> >
> >
> http://repo.pentaho.org//content/groups/omni/tigris/svnClientAdapter/svnant-1.3.0/svnClientAdapter-svnant-1.3.0.jar
> >
> > Anyone know why?
> >
> > Ant output:
> >
> > BUILD FAILED
> > C:\Users\GregWoolsey\svn\ApachePOI\build.xml:868: The following error
> > occurred while executing this line:
> > C:\Users\GregWoolsey\svn\ApachePOI\build.xml:625: Can't get
> >
> >
> http://repo.pentaho.org//content/groups/omni/tigris/svnClientAdapter/svnant-1.3.0/svnClientAdapter-svnant-1.3.0.jar
> >
> > On Wed, Apr 3, 2019 at 6:28 AM Dominik Stadler 
> > wrote:
> >
> > > Sorry for the late reply, I will try to start another run toda, but you
> > > don't to delay release work because of it.
> > >
> > > Dominik
> > >
> > > On Tue, Apr 2, 2019, 00:15 Greg Woolsey 
> wrote:
> > >
> > > > Dominik, is it worth running the regression corpus again, to verify
> how
> > > > many of the new errors are cleaned up?
> > > >
> > > > On Sat, Mar 30, 2019 at 9:38 PM Greg Woolsey  >
> > > > wrote:
> > > >
> > > > > Build working again.  Latest fix should also remove most of the
> > > > > differences in the regression run seen last week.  I'm happy with
> the
> > > > > current state for a 4.1.0 release.  Bit of churn today, but they
> were
> > > > small
> > > > > changes and are now sorted.
> > > > >
> > > > > On Sat, Mar 30, 2019 at 2:14 PM Kai Grabfelder <
> > > nos...@kaigrabfelder.de>
> > > > > wrote:
> > > > >
> > > > >> Would it be possible to also include
> > > > >> https://bz.apache.org/bugzilla/show_bug.cgi?id=61700? I can also
> > > > provide
> > > > >> a pull request if that is prefered over the patch.
> > > > >>
> > > > >> Best Regards
> > > > >>
> > > > >> Kai Grabfelder
> > > > >> Greg Woolsey schrieb am 30.03.19 um 21:16:
> > > > >>
> > > > >> Anyone have anything else they want in before I start the build
> and
> > > > release
> > > > >> process?
> > > > >>
> > > > >> I just cleaned up the recent issues that mattered to me around
> > formula
> > > > >> evaluation and data formatting.  Turns out they were somewhat
> > related
> > > in
> > > > >> code, but unrelated in discovery.
> > > > >>
> > > > >>
> > > > >>
> > > >
> > >
> >
>

Re: Ready for 4.1.0 release?

[Greg Woolsey]

I get "Access Denied" when I try to run release-prep1 when it tries to
retrieve this file:

Can't get
http://repo.pentaho.org//content/groups/omni/tigris/svnClientAdapter/svnant-1.3.0/svnClientAdapter-svnant-1.3.0.jar

Anyone know why?

Ant output:

BUILD FAILED
C:\Users\GregWoolsey\svn\ApachePOI\build.xml:868: The following error
occurred while executing this line:
C:\Users\GregWoolsey\svn\ApachePOI\build.xml:625: Can't get
http://repo.pentaho.org//content/groups/omni/tigris/svnClientAdapter/svnant-1.3.0/svnClientAdapter-svnant-1.3.0.jar

On Wed, Apr 3, 2019 at 6:28 AM Dominik Stadler 
wrote:

> Sorry for the late reply, I will try to start another run toda, but you
> don't to delay release work because of it.
>
> Dominik
>
> On Tue, Apr 2, 2019, 00:15 Greg Woolsey  wrote:
>
> > Dominik, is it worth running the regression corpus again, to verify how
> > many of the new errors are cleaned up?
> >
> > On Sat, Mar 30, 2019 at 9:38 PM Greg Woolsey 
> > wrote:
> >
> > > Build working again.  Latest fix should also remove most of the
> > > differences in the regression run seen last week.  I'm happy with the
> > > current state for a 4.1.0 release.  Bit of churn today, but they were
> > small
> > > changes and are now sorted.
> > >
> > > On Sat, Mar 30, 2019 at 2:14 PM Kai Grabfelder <
> nos...@kaigrabfelder.de>
> > > wrote:
> > >
> > >> Would it be possible to also include
> > >> https://bz.apache.org/bugzilla/show_bug.cgi?id=61700? I can also
> > provide
> > >> a pull request if that is prefered over the patch.
> > >>
> > >> Best Regards
> > >>
> > >> Kai Grabfelder
> > >> Greg Woolsey schrieb am 30.03.19 um 21:16:
> > >>
> > >> Anyone have anything else they want in before I start the build and
> > release
> > >> process?
> > >>
> > >> I just cleaned up the recent issues that mattered to me around formula
> > >> evaluation and data formatting.  Turns out they were somewhat related
> in
> > >> code, but unrelated in discovery.
> > >>
> > >>
> > >>
> >
>

Re: Ready for 4.1.0 release?

[Greg Woolsey]

As the Vaadin developers are waiting for 4.1.0, and no one has responded
with additional work worth waiting for or fixes needed, I'll start the
release prep Thursday. Best not to do it while I'm offline over the
Atlantic today.

On Tue, Apr 2, 2019 at 12:15 AM Greg Woolsey  wrote:

> Dominik, is it worth running the regression corpus again, to verify how
> many of the new errors are cleaned up?
>
> On Sat, Mar 30, 2019 at 9:38 PM Greg Woolsey 
> wrote:
>
>> Build working again.  Latest fix should also remove most of the
>> differences in the regression run seen last week.  I'm happy with the
>> current state for a 4.1.0 release.  Bit of churn today, but they were small
>> changes and are now sorted.
>>
>> On Sat, Mar 30, 2019 at 2:14 PM Kai Grabfelder 
>> wrote:
>>
>>> Would it be possible to also include
>>> https://bz.apache.org/bugzilla/show_bug.cgi?id=61700? I can also
>>> provide a pull request if that is prefered over the patch.
>>>
>>> Best Regards
>>>
>>> Kai Grabfelder
>>> Greg Woolsey schrieb am 30.03.19 um 21:16:
>>>
>>> Anyone have anything else they want in before I start the build and release
>>> process?
>>>
>>> I just cleaned up the recent issues that mattered to me around formula
>>> evaluation and data formatting.  Turns out they were somewhat related in
>>> code, but unrelated in discovery.
>>>
>>>
>>>

Re: Ready for 4.1.0 release?

[Greg Woolsey]

Dominik, is it worth running the regression corpus again, to verify how
many of the new errors are cleaned up?

On Sat, Mar 30, 2019 at 9:38 PM Greg Woolsey  wrote:

> Build working again.  Latest fix should also remove most of the
> differences in the regression run seen last week.  I'm happy with the
> current state for a 4.1.0 release.  Bit of churn today, but they were small
> changes and are now sorted.
>
> On Sat, Mar 30, 2019 at 2:14 PM Kai Grabfelder 
> wrote:
>
>> Would it be possible to also include
>> https://bz.apache.org/bugzilla/show_bug.cgi?id=61700? I can also provide
>> a pull request if that is prefered over the patch.
>>
>> Best Regards
>>
>> Kai Grabfelder
>> Greg Woolsey schrieb am 30.03.19 um 21:16:
>>
>> Anyone have anything else they want in before I start the build and release
>> process?
>>
>> I just cleaned up the recent issues that mattered to me around formula
>> evaluation and data formatting.  Turns out they were somewhat related in
>> code, but unrelated in discovery.
>>
>>
>>

Re: Ready for 4.1.0 release?

[Greg Woolsey]

Build working again.  Latest fix should also remove most of the differences
in the regression run seen last week.  I'm happy with the current state for
a 4.1.0 release.  Bit of churn today, but they were small changes and are
now sorted.

On Sat, Mar 30, 2019 at 2:14 PM Kai Grabfelder 
wrote:

> Would it be possible to also include
> https://bz.apache.org/bugzilla/show_bug.cgi?id=61700? I can also provide
> a pull request if that is prefered over the patch.
>
> Best Regards
>
> Kai Grabfelder
> Greg Woolsey schrieb am 30.03.19 um 21:16:
>
> Anyone have anything else they want in before I start the build and release
> process?
>
> I just cleaned up the recent issues that mattered to me around formula
> evaluation and data formatting.  Turns out they were somewhat related in
> code, but unrelated in discovery.
>
>
>

Fwd: svn commit: r1856655 - in /poi/trunk/src: java/org/apache/poi/ss/formula/SheetNameFormatter.java testcases/org/apache/poi/hssf/usermodel/TestHSSFEvaluationSheet.java

[Greg Woolsey]

I handled this similarly to other code that converted missing external
sheet info to empty String values, but if someone thinks this should still
throw an exception, I'm open to discussing a new "MissingExternalReference"
checked exception or something like that.  Appears Excel does this to avoid
errors, so POI has been also, just not for this case but not on purpose.

-- Forwarded message -
From: 
Date: Sat, Mar 30, 2019 at 8:49 PM
Subject: svn commit: r1856655 - in /poi/trunk/src:
java/org/apache/poi/ss/formula/SheetNameFormatter.java
testcases/org/apache/poi/hssf/usermodel/TestHSSFEvaluationSheet.java
To: 


Author: gwoolsey
Date: Sun Mar 31 03:49:16 2019
New Revision: 1856655

URL: http://svn.apache.org/viewvc?rev=1856655=rev
Log:
fix a condition not seen until a recent expansion of the stress test.
Gracefully ignore missing/invalid external sheet references in one more
path (there were several already with comments like "this seems to be what
Excel does in this case")

Modified:
poi/trunk/src/java/org/apache/poi/ss/formula/SheetNameFormatter.java

poi/trunk/src/testcases/org/apache/poi/hssf/usermodel/TestHSSFEvaluationSheet.java

Modified:
poi/trunk/src/java/org/apache/poi/ss/formula/SheetNameFormatter.java
URL:
http://svn.apache.org/viewvc/poi/trunk/src/java/org/apache/poi/ss/formula/SheetNameFormatter.java?rev=1856655=1856654=1856655=diff
==
--- poi/trunk/src/java/org/apache/poi/ss/formula/SheetNameFormatter.java
(original)
+++ poi/trunk/src/java/org/apache/poi/ss/formula/SheetNameFormatter.java
Sun Mar 31 03:49:16 2019
@@ -179,7 +179,7 @@ public final class SheetNameFormatter {

int len = rawSheetName.length();
if(len < 1) {
-   throw new RuntimeException("Zero length string is
an invalid sheet name");
+   return false; // some cases we get missing external
references, resulting in empty sheet names
}
if(Character.isDigit(rawSheetName.charAt(0))) {
// sheet name with digit in the first position
always requires delimiting

Modified:
poi/trunk/src/testcases/org/apache/poi/hssf/usermodel/TestHSSFEvaluationSheet.java
URL:
http://svn.apache.org/viewvc/poi/trunk/src/testcases/org/apache/poi/hssf/usermodel/TestHSSFEvaluationSheet.java?rev=1856655=1856654=1856655=diff
==
---
poi/trunk/src/testcases/org/apache/poi/hssf/usermodel/TestHSSFEvaluationSheet.java
(original)
+++
poi/trunk/src/testcases/org/apache/poi/hssf/usermodel/TestHSSFEvaluationSheet.java
Sun Mar 31 03:49:16 2019
@@ -17,9 +17,12 @@

 package org.apache.poi.hssf.usermodel;

+import org.apache.poi.hssf.HSSFTestDataSamples;
 import org.apache.poi.ss.formula.EvaluationSheet;
 import org.apache.poi.ss.usermodel.BaseTestXEvaluationSheet;
+import org.apache.poi.ss.usermodel.Name;
 import org.apache.poi.ss.usermodel.Sheet;
+import org.junit.Test;

 import java.util.AbstractMap;
 import java.util.Map;
@@ -30,4 +33,15 @@ public class TestHSSFEvaluationSheet ext
 HSSFSheet sheet = new HSSFWorkbook().createSheet();
 return new AbstractMap.SimpleEntry<>(sheet, new
HSSFEvaluationSheet(sheet));
 }
+
+@Test
+public void testMissingExternalName() {
+HSSFWorkbook wb =
HSSFTestDataSamples.openSampleWorkbook("external_name.xls");
+for (Name name : wb.getAllNames()) {
+// this sometimes causes exceptions
+if(!name.isFunctionName()) {
+name.getRefersToFormula();
+}
+}
+}
 }



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

Fwd: Build failed in Jenkins: POI-DSL-1.13 #12

[Greg Woolsey]

The failing test is new - it's a stack trace that also showed up new in the
regression test run.  I was going to put off looking into it, but I guess
I'll do that now.  Not sure what changed that it started showing up in unit
tests, as it isn't related to today's changes.

-- Forwarded message -
From: Apache Jenkins Server 
Date: Sat, Mar 30, 2019 at 7:36 PM
Subject: Build failed in Jenkins: POI-DSL-1.13 #12
To: 


See <
https://builds.apache.org/job/POI-DSL-1.13/12/display/redirect?page=changes>

Changes:

[gwoolsey] fix unit test that I merged wrong.

[gwoolsey] #61700 getForceFormulaRecalculation() returns wrong value

changed to use the proper OOXML attribute instead of a hack about
calculation engine version ID.  Reporter was right, the behavior was wrong
in some cases, but it turns out the fix was a bit more.  See issue for
details.

[fanningpj] [bug-61700] getForceFormulaRecalculation() returns wrong value.
Fix thanks to Kai G

[fanningpj] fix build issue

[gwoolsey] #63292 1904 date windowing flag not used for some format cases

[gwoolsey] #63291 CellFormat global cache isn't thread-safe

move date format synchronization down to where the problem instance is held.

[gwoolsey] #63302 Formula evaluation of names with offset or row function
is incorrect

thanks to John Lincoln White for the patch, including new unit tests.

[fanningpj] [bug-63291] support concurrent date formatting with same
DataFormatter

[fanningpj] add test for concurrent use of DataFormatter

[fanningpj] use released version of xmlbeans 3.1.0

--
[...truncated 318.06 KB...]
[junit] Reading
spreadsheet/evaluate_formula_with_structured_table_references.xlsx with
OPCFileHandler
[junit] Reading spreadsheet/evencontinuation.txt with NullFileHandler
[junit] Reading spreadsheet/ex41187-19267.xls with HSSFFileHandler
[junit] Reading spreadsheet/ex41187-19267.xls with HPSFFileHandler
[junit] Reading spreadsheet/ex42564-21435.xls with HSSFFileHandler
[junit] Reading spreadsheet/ex42564-21435.xls with HPSFFileHandler
[junit] Reading spreadsheet/ex42564-21503.xls with HSSFFileHandler
[junit] Reading spreadsheet/ex42564-21503.xls with HPSFFileHandler
[junit] Reading spreadsheet/ex42564-elementOrder.xls with
HSSFFileHandler
[junit] Reading spreadsheet/ex42564-elementOrder.xls with
HPSFFileHandler
[junit] Reading spreadsheet/ex42570-20305.xls with HSSFFileHandler
[junit] Reading spreadsheet/ex42570-20305.xls with HPSFFileHandler
[junit] Reading spreadsheet/ex44921-21902.xls with HSSFFileHandler
[junit] Reading spreadsheet/ex44921-21902.xls with HPSFFileHandler
[junit] Reading spreadsheet/ex45046-21984.xls with HSSFFileHandler
[junit] Reading spreadsheet/ex45046-21984.xls with HPSFFileHandler
[junit] Reading spreadsheet/ex45582-22397.xls with HSSFFileHandler
[junit] Reading spreadsheet/ex45582-22397.xls with HPSFFileHandler
[junit] Reading spreadsheet/ex45672.xls with HSSFFileHandler
[junit] Reading spreadsheet/ex45672.xls with HPSFFileHandler
[junit] Reading spreadsheet/ex45698-22488.xls with HSSFFileHandler
[junit] Reading spreadsheet/ex45698-22488.xls with HPSFFileHandler
[junit] Reading spreadsheet/ex45978-extraLinkTableSheets.xls with
HSSFFileHandler
[junit] Reading spreadsheet/ex45978-extraLinkTableSheets.xls with
HPSFFileHandler
[junit] Reading spreadsheet/ex46548-23133.xls with HSSFFileHandler
[junit] Reading spreadsheet/ex46548-23133.xls with HPSFFileHandler
[junit] Reading spreadsheet/ex47747-sharedFormula.xls with
HSSFFileHandler
[junit] Reading spreadsheet/ex47747-sharedFormula.xls with
HPSFFileHandler
[junit] Reading spreadsheet/excel_with_embeded.xls with HSSFFileHandler
[junit] Reading spreadsheet/excel_with_embeded.xls with HPSFFileHandler
[junit] Reading spreadsheet/excelant.xls with HSSFFileHandler
[junit] Reading spreadsheet/excelant.xls with HPSFFileHandler
[junit] Reading spreadsheet/extendedtextstrings.txt with NullFileHandler
[junit] Reading spreadsheet/externalFunctionExample.xls with
HSSFFileHandler
[junit] Reading spreadsheet/externalFunctionExample.xls with
HPSFFileHandler
[junit] Reading spreadsheet/external_image.xls with HSSFFileHandler
[junit] Reading spreadsheet/external_image.xls with HPSFFileHandler
[junit] Reading spreadsheet/external_name.xls with HSSFFileHandler
[junit] Failed: spreadsheet/external_name.xls
[junit] Reading spreadsheet/external_name.xls with HPSFFileHandler
[junit] Reading spreadsheet/finance.xls with HSSFFileHandler
[junit] Reading spreadsheet/finance.xls with HPSFFileHandler
[junit] Reading spreadsheet/florida_data.ashx.xls with HSSFFileHandler
[junit] Reading spreadsheet/florida_data.ashx.xls with HPSFFileHandler
[junit] Reading spreadsheet/headerFooterTest.xlsx with XSSFFileHandler
[junit] Reading spreadsheet/headerFooterTest.xlsx with OPCFileHandler

Ready for 4.1.0 release?

[Greg Woolsey]

Anyone have anything else they want in before I start the build and release
process?

I just cleaned up the recent issues that mattered to me around formula
evaluation and data formatting.  Turns out they were somewhat related in
code, but unrelated in discovery.

[ANNOUNCE] Apache XMLBeans 3.1.0 released

[Greg Woolsey]

The Apache POI PMC is pleased to announce the release of Apache XMLBeans
3.1.0.

Apache XMLBeans is a technology for accessing XML by binding it to Java
types.

For detailed changes in this release, refer to the release notes [1] and
the changelog [2].

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

On behalf of the Apache POI PMC,

Greg Woolsey

[1] Release notes:
https://www.apache.org/dyn/closer.lua/poi/xmlbeans/release/dev/RELEASE-NOTES-3.1.0.txt
[2] Changelog: https://xmlbeans.apache.org/status.html#rel_310

Re: XMLBeans 3.1.0 candidate build

[Greg Woolsey]

>
>
> > It's ok, but not nice to have the bin directory in the src dist
> duplicated in (/bin, /src/shell) - we can change that on the next release.
> I still think it's better to have the shell scripts not under /bin in the
> source tree.
>
> +1
>

I agree, I didn't like it in /bin, but that's where it has been
historically for this project, and it was noted as missing when it moved to
/src/shell, so I put it back in the build.  In the next version we can make
that a prominent "feature" noted in the release docs and move it from
/bin.  Probably not used very often these days anyway.


> > I don't like to have the javadocs in the src dist, but rather would like
> to see them in bin dist.
>
> +1
>

They are in the bin dist as a JAR file.  Again these were noted as missing
from the src package, so I put them in.  I don't have a strong opinion
either way.  I don't generally use them directly, relying on IDE
integrations to display relevant docs.


> >
> > In my view, the src dist is a copy of the trunk whereas the bin dist
> contains all the compiled/generated artifacts.
>
> +1
>

Makes sense.  This particular project appears to have been a bit muddied in
it's far distant past in that regard.


> >
> > The pgp signature (*.asc) doesn't need to be check-summed - for Nexus,
> I'm not sure if they are automatically created on uploading the signature
> files.
>
> +1, it doesn’t serve any purpose I’ve only ever seen it on a single
> project in the incubator and at least on Apache dist they should be removed.
>

I agree.  I have no explanation or excuse for why I did that.  Probably a
misreading of something as I attempted to build release instructions from
scratch and crib much of the info from the POI release-guide.txt.  Will
remove them before moving to the release folder.

>
> > - the KEYS file: I'd like to have one merged KEYS file for both projects
> and use svn externals to link to the one place.
>
> Since they are both in the same dist area in on Apache then they must be
> merged or the main one has all the keys.
>
> There is one place on dist and never inside a release.
>

Yes, Dominik and I have corresponded over that a bit, as his key in
production was out of date or listed twice, depending on the file.
Something to do for the next release for sure.

Greg

[VOTE] XMLBeans 3.1.0 release

[Greg Woolsey]

Release artifacts:

https://repository.apache.org/content/repositories/staging/org/apache/xmlbeans/xmlbeans/3.1.0/

https://dist.apache.org/repos/dist/dev/poi/xmlbeans/bin
https://dist.apache.org/repos/dist/dev/poi/xmlbeans/src

The vote will remain open for 3 days.

See the CHANGES.txt file for release details.  The minor version bump is
for the packaging changes to clean up old content and update naming
conventions.

Greg

XMLBeans 3.1.0 candidate build

[Greg Woolsey]

I have pushed xmlbeans 3.1.0 release candidate to:

https://repository.apache.org/content/repositories/staging/org/apache/xmlbeans/xmlbeans/3.1.0/

https://dist.apache.org/repos/dist/dev/poi/xmlbeans/bin
https://dist.apache.org/repos/dist/dev/poi/xmlbeans/src

This has discussed version # changes, updates to various text files that
were out of date, and packaging modifications to make it less of a change
from previous releases while still adjusting naming and folder conventions
to be more in line with POI's naming.

Should we do a formal vote, say 3 days?  If this looks good, I can release
on Monday, then later next week, once Maven artifacts are available, I can
work on a POI 4.1.0 candidate.

Greg

Re: XML Beans 3.0.3 candidate build

[Greg Woolsey]

Turns out the shell scripts *are* in the src zip, they are just moved to
/src/shell.  Andi did that to avoid a top-level folder called "bin" because
that conflicts with IDE default output folders.

I can leave it, and document the change in the README and CHANGES files, or
exclude that directory when building, and include it mapped to /bin, like
the xmlbeans-bin zip file.

Thoughts?  I lean toward moving it to /bin in the src zip, to match the bin
zip.  I'll work on that unless someone has a reason not to.

On Thu, Mar 21, 2019 at 10:51 AM Greg Woolsey 
wrote:

> I hard from Andi, who is text-only on a vacation.  He redid the build to
> align names better with POI naming conventions and remove unnecessary
> things like the separate public jar.
>
> I think the following changes would be helpful, but beyond that I think it
> looks fine:
>
> 1. include the bin/* scripts in the src zip
> 2. bump the version to 3.1.0 and mention the packaging changes in the
> changelog
> 3. fix the README version #
>
> Then I would do a 3.1.0 XMLBeans build and deploy to staging.
>
> How does that sound to folks?
>
>
> On Thu, Mar 21, 2019 at 10:28 AM Greg Woolsey 
> wrote:
>
>> I'm OK with changing the number and re-doing a build.  Reminds me I need
>> to go install JDK 1.6, I don't have it yet on the new laptop.  It looks to
>> me like the changes were intentional to get rid of old stuff no longer
>> needed by anyone, but I don't know who still uses it, and is using the
>> newer builds we produce.
>>
>> Looks like Javadoc is now in a jar, which is probably fine, as most
>> people access it via IDE, which look for it in jars.  Easy enough to unzip
>> if you want the HTML directly.
>>
>> As for the scripts, I suspect they should still go in the src file, as I
>> would expect that file to have everything needed to build and use the
>> package.
>>
>> On Thu, Mar 21, 2019 at 10:02 AM Dominik Stadler 
>> wrote:
>>
>>> Hi,
>>>
>>> Maybe Andi can comment on some of these if changes were on-purpose or
>>> unintentional. I also don't have any experience whats-o-ever with
>>> XMLBeans,
>>> so am not sure myself.
>>>
>>> Missing jars may be fine to get rid of some old cruft, renaming of
>>> tgz/zip
>>> should not cause much issues as nowadays most people drag in dependencies
>>> via maven/gradle.
>>>
>>> Missing javadoc and bin/scripts I would investigate because it may mean
>>> that important pieces are missing.
>>>
>>> Finally should we use a different version number, e.g. 3.1.0 to indicate
>>> that some more changes in functionality did occur, 3.0.3 would suggest
>>> "drop in replacement", which will not guarantee here?
>>>
>>> Thanks... Dominik.
>>>
>>> On Thu, Mar 21, 2019 at 5:21 PM Greg Woolsey 
>>> wrote:
>>>
>>> > xmlpublic.jar and the other different/missing pieces are all due to the
>>> > revamping of build.xml.  Many targets have been removed in the current
>>> > version.
>>> >
>>> > The XMLBeans web site says xmlpublic.jar was just the "public" API, a
>>> > slimmed-down dependency if projects were not going to need the whole
>>> > thing.  Not sure that matters for our purposes, as we are releasing
>>> updates
>>> > targeted primarily for POI, and the JAR size differences aren't enough
>>> to
>>> > matter in my mind.
>>> >
>>> > I can't find any reference to xmlbean_xpath.jar in the old build.xml,
>>> web
>>> > site, or any other file in the source tree, so I don't know where that
>>> > comes from or why it was included.
>>> >
>>> > On Thu, Mar 21, 2019 at 8:25 AM Greg Woolsey 
>>> > wrote:
>>> >
>>> > > Removed 3.0.2 artifacts from the dist/dev tree.
>>> > >
>>> > > I pulled the zips from the Jenkins build artifacts, and then
>>> repackaged
>>> > > them to *.tgz as well.  The build.xml has been heavily modified since
>>> > > 3.0.2, so perhaps some things got lost along the way, as well as
>>> renamed.
>>> > > This is the first new release since the reworking of the XMLBeans
>>> build.
>>> > >
>>> > > If the package artifacts should be named differently, that should go
>>> in
>>> > > build.xml, not manual steps after.
>>> > >
>>> > > I don't know XMLBeans at all, so I have no frame of refer

Re: XML Beans 3.0.3 candidate build

[Greg Woolsey]

I hard from Andi, who is text-only on a vacation.  He redid the build to
align names better with POI naming conventions and remove unnecessary
things like the separate public jar.

I think the following changes would be helpful, but beyond that I think it
looks fine:

1. include the bin/* scripts in the src zip
2. bump the version to 3.1.0 and mention the packaging changes in the
changelog
3. fix the README version #

Then I would do a 3.1.0 XMLBeans build and deploy to staging.

How does that sound to folks?


On Thu, Mar 21, 2019 at 10:28 AM Greg Woolsey 
wrote:

> I'm OK with changing the number and re-doing a build.  Reminds me I need
> to go install JDK 1.6, I don't have it yet on the new laptop.  It looks to
> me like the changes were intentional to get rid of old stuff no longer
> needed by anyone, but I don't know who still uses it, and is using the
> newer builds we produce.
>
> Looks like Javadoc is now in a jar, which is probably fine, as most people
> access it via IDE, which look for it in jars.  Easy enough to unzip if you
> want the HTML directly.
>
> As for the scripts, I suspect they should still go in the src file, as I
> would expect that file to have everything needed to build and use the
> package.
>
> On Thu, Mar 21, 2019 at 10:02 AM Dominik Stadler 
> wrote:
>
>> Hi,
>>
>> Maybe Andi can comment on some of these if changes were on-purpose or
>> unintentional. I also don't have any experience whats-o-ever with
>> XMLBeans,
>> so am not sure myself.
>>
>> Missing jars may be fine to get rid of some old cruft, renaming of tgz/zip
>> should not cause much issues as nowadays most people drag in dependencies
>> via maven/gradle.
>>
>> Missing javadoc and bin/scripts I would investigate because it may mean
>> that important pieces are missing.
>>
>> Finally should we use a different version number, e.g. 3.1.0 to indicate
>> that some more changes in functionality did occur, 3.0.3 would suggest
>> "drop in replacement", which will not guarantee here?
>>
>> Thanks... Dominik.
>>
>> On Thu, Mar 21, 2019 at 5:21 PM Greg Woolsey 
>> wrote:
>>
>> > xmlpublic.jar and the other different/missing pieces are all due to the
>> > revamping of build.xml.  Many targets have been removed in the current
>> > version.
>> >
>> > The XMLBeans web site says xmlpublic.jar was just the "public" API, a
>> > slimmed-down dependency if projects were not going to need the whole
>> > thing.  Not sure that matters for our purposes, as we are releasing
>> updates
>> > targeted primarily for POI, and the JAR size differences aren't enough
>> to
>> > matter in my mind.
>> >
>> > I can't find any reference to xmlbean_xpath.jar in the old build.xml,
>> web
>> > site, or any other file in the source tree, so I don't know where that
>> > comes from or why it was included.
>> >
>> > On Thu, Mar 21, 2019 at 8:25 AM Greg Woolsey 
>> > wrote:
>> >
>> > > Removed 3.0.2 artifacts from the dist/dev tree.
>> > >
>> > > I pulled the zips from the Jenkins build artifacts, and then
>> repackaged
>> > > them to *.tgz as well.  The build.xml has been heavily modified since
>> > > 3.0.2, so perhaps some things got lost along the way, as well as
>> renamed.
>> > > This is the first new release since the reworking of the XMLBeans
>> build.
>> > >
>> > > If the package artifacts should be named differently, that should go
>> in
>> > > build.xml, not manual steps after.
>> > >
>> > > I don't know XMLBeans at all, so I have no frame of reference other
>> than
>> > > previous builds to know what was intentional and what was accidental
>> in
>> > the
>> > > modifications since October.
>> > >
>> > > I can update the README if we want, but I'd be doing so without a good
>> > > sense of where the project stands, as I've never used it outside of a
>> POI
>> > > dependency.
>> > >
>> > > On Thu, Mar 21, 2019 at 12:14 AM Dominik Stadler <
>> dominik.stad...@gmx.at
>> > >
>> > > wrote:
>> > >
>> > >> Can you remove the 3.0.2 files from
>> > >> https://dist.apache.org/repos/dist/dev/poi/xmlbeans/, they are
>> > available
>> > >> as
>> > >> official release anyway.
>> > >>
>> > >> File names are slightly different now, not sure if this is intended
>>

Re: XML Beans 3.0.3 candidate build

[Greg Woolsey]

I'm OK with changing the number and re-doing a build.  Reminds me I need to
go install JDK 1.6, I don't have it yet on the new laptop.  It looks to me
like the changes were intentional to get rid of old stuff no longer needed
by anyone, but I don't know who still uses it, and is using the newer
builds we produce.

Looks like Javadoc is now in a jar, which is probably fine, as most people
access it via IDE, which look for it in jars.  Easy enough to unzip if you
want the HTML directly.

As for the scripts, I suspect they should still go in the src file, as I
would expect that file to have everything needed to build and use the
package.

On Thu, Mar 21, 2019 at 10:02 AM Dominik Stadler 
wrote:

> Hi,
>
> Maybe Andi can comment on some of these if changes were on-purpose or
> unintentional. I also don't have any experience whats-o-ever with XMLBeans,
> so am not sure myself.
>
> Missing jars may be fine to get rid of some old cruft, renaming of tgz/zip
> should not cause much issues as nowadays most people drag in dependencies
> via maven/gradle.
>
> Missing javadoc and bin/scripts I would investigate because it may mean
> that important pieces are missing.
>
> Finally should we use a different version number, e.g. 3.1.0 to indicate
> that some more changes in functionality did occur, 3.0.3 would suggest
> "drop in replacement", which will not guarantee here?
>
> Thanks... Dominik.
>
> On Thu, Mar 21, 2019 at 5:21 PM Greg Woolsey 
> wrote:
>
> > xmlpublic.jar and the other different/missing pieces are all due to the
> > revamping of build.xml.  Many targets have been removed in the current
> > version.
> >
> > The XMLBeans web site says xmlpublic.jar was just the "public" API, a
> > slimmed-down dependency if projects were not going to need the whole
> > thing.  Not sure that matters for our purposes, as we are releasing
> updates
> > targeted primarily for POI, and the JAR size differences aren't enough to
> > matter in my mind.
> >
> > I can't find any reference to xmlbean_xpath.jar in the old build.xml, web
> > site, or any other file in the source tree, so I don't know where that
> > comes from or why it was included.
> >
> > On Thu, Mar 21, 2019 at 8:25 AM Greg Woolsey 
> > wrote:
> >
> > > Removed 3.0.2 artifacts from the dist/dev tree.
> > >
> > > I pulled the zips from the Jenkins build artifacts, and then repackaged
> > > them to *.tgz as well.  The build.xml has been heavily modified since
> > > 3.0.2, so perhaps some things got lost along the way, as well as
> renamed.
> > > This is the first new release since the reworking of the XMLBeans
> build.
> > >
> > > If the package artifacts should be named differently, that should go in
> > > build.xml, not manual steps after.
> > >
> > > I don't know XMLBeans at all, so I have no frame of reference other
> than
> > > previous builds to know what was intentional and what was accidental in
> > the
> > > modifications since October.
> > >
> > > I can update the README if we want, but I'd be doing so without a good
> > > sense of where the project stands, as I've never used it outside of a
> POI
> > > dependency.
> > >
> > > On Thu, Mar 21, 2019 at 12:14 AM Dominik Stadler <
> dominik.stad...@gmx.at
> > >
> > > wrote:
> > >
> > >> Can you remove the 3.0.2 files from
> > >> https://dist.apache.org/repos/dist/dev/poi/xmlbeans/, they are
> > available
> > >> as
> > >> official release anyway.
> > >>
> > >> File names are slightly different now, not sure if this is intended or
> > >> will
> > >> cause issues: xmlbeans-3.0.2-src.tgz
> > >> <
> > >>
> >
> https://dist.apache.org/repos/dist/dev/poi/xmlbeans/src/xmlbeans-3.0.2-src.tgz
> > >> >
> > >> vs. xmlbeans-src-3.0.3.tgz
> > >> <
> > >>
> >
> https://dist.apache.org/repos/dist/dev/poi/xmlbeans/src/xmlbeans-src-3.0.3.tgz
> > >> >,
> > >> similar for bin: xmlbeans-3.0.2.tgz
> > >> <
> > >>
> >
> https://dist.apache.org/repos/dist/dev/poi/xmlbeans/bin/xmlbeans-3.0.2.tgz
> > >> >
> > >> vs. xmlbeans-bin-3.0.3.tgz
> > >> <
> > >>
> >
> https://dist.apache.org/repos/dist/dev/poi/xmlbeans/bin/xmlbeans-bin-3.0.3.tgz
> > >> >
> > >>
> > >> Inside the files I found the following differences compared to 3.0.2:
> > >>
> > >> * In

XML Beans 3.0.3 candidate build

[Greg Woolsey]

I have pushed xmlbeans 3.0.3 release candidate to:

https://repository.apache.org/content/repositories/staging/org/apache/xmlbeans/xmlbeans/3.0.3/

https://dist.apache.org/repos/dist/dev/poi/xmlbeans/bin
https://dist.apache.org/repos/dist/dev/poi/xmlbeans/src

If those look good to folks, what do I do to "release" from staging in the
repository?  Do I just click the "Release" button in the web interface,
perhaps selecting "Public Repositories" if there is a prompt?

I assume I then modify site docs like site.xml, modifying 3.0.2 to 3.0.3,
then running forrest and committing.  It's my understanding we don't need
to do anything special to release the site changes?

Any other steps?  I'm thinking I should also commit what I've done in a
build instructions file so this thread and the previous one aren't the
source for future releases.

Maybe also mentioning the AdblockPlus Chrome and Firefox extensions break
nexus uploads unless you exclude the repository domain.  That cost me a bit
of time.

Re: Next release of POI/XmlBeans?

[Greg Woolsey]

When was the previous regression run?

Some of the formula errors mention invalid sheet names, including
empty strings.  The fix for #60460 committed Dec. 30 handled null
sheet names in SheetNameEvaluator, but perhaps that change should also
check and handle empty strings?

I've never actually touched HSSF, but since the vast majority of these
new failures in o.a.p.ss.formula.* involve stacks with "*Name*"
methods and HSSF files, this seems like a reasonable place to start
looking.

Several of the o.a.p.ss.formula.* errors are for known
not-yet-supported items, like SxNamePtg (id=0x18, prints as "24" in
the stacks)

On Wed, Mar 20, 2019 at 6:28 AM Dominik Stadler  wrote:
>
> A first run of the regression tests for Apache POI is done. It still uses
> XMLBeans 3.0.2, I will re-run a 2nd time later when we have XmlBeans 3.0.3
> final available.
>
> There are new failures with a high amount of failing documents compared to
> 4.0.x, however these are caused by the addition of a call to
> HSSFOptimiser.optimiseFonts() in the regression test itself, so these are
> not actual regressions, just more testing.
>
> Apart from that a number of SlideShow drawing related items, probably due
> to support for more features and a few FormulaParser related ones which we
> should take a quick look at why they fail now.
>
> Details are available at the following links:
>
>- 4.0.1-RC1 to 4.1.0-RC1
>
> 
>- 4.1.0-RC1-All
>
> 
>
> Dominik.
>
> On Tue, Mar 19, 2019 at 10:41 PM pj.fanning  wrote:
>
> > For xmlbeans, I would recommend getting the release jars and zips from
> >
> > https://builds.apache.org/view/P/view/POI/job/POI-XMLBeans-DSL-1.6/lastSuccessfulBuild/artifact/build/
> >
> > This guarantees the jars were built with Java 6.
> >
> > For the nexus release, I follow this guide:
> >
> > https://central.sonatype.org/pages/manual-staging-bundle-creation-and-deployment.html
> >
> > I use `gpg -ab` to create the asc files for the 3 jars and for the pom
> > file.
> > I use the pom file from the previous release and edit it to update the
> > version. Create a bundle.jar as described in the sonatype link and upload
> > the bundle.jar to https://repository.apache.org/
> >
> > To release the source and bin bundles, you need to use svn to work with
> > https://dist.apache.org/repos/dist/release/poi/xmlbeans/release svn repo.
> >
> > The xmlbeans site is updated using the svn repo
> > https://svn.apache.org/repos/asf/xmlbeans/site
> >
> > If you have questions, feel free to reach out.
> >
> >
> >
> >
> >
> > --
> > 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
> >
> >

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

Re: Next release of POI/XmlBeans?

[Greg Woolsey]

OK, I think I'm reasonably familiar now with the POI release build
process, thank you to all who have contributed to the detailed
release-guide.txt.

However, there is no such document I can find for XMLBeans, and it
sounds like there may be an open question or two there?

Further, if I'm reading the emails correctly, there are changes to
XMLBeans that should be released first, so that POI can be updated to
use that new version before building a POI release candidate.  Is that
correct?

So, my questions, for timing and completeness, are:

1. what work remains before releasing a new XMLBeans?
2. How do I build, tag, and release XMLBeans?
3. What version numbers do we want to use?  These seem to be the next ones up:
   - XMLBeans 3.0.3
   - POI 4.1.0

I'm sure there will be more, not having driven a release before, and
experiencing a high "don't screw this up" quotient :)

Greg

On Mon, Mar 18, 2019 at 12:47 PM Andreas Beeker  wrote:
>
> On 18.03.19 06:11, Greg Woolsey wrote:
> > I've not done a release yet, but I'd be willing to read the docs and
> > take a stab at it if no one else has time.
>
> Regarding POI:
>
> After setting up the environment - its merely calling the release-prep* 
> scripts.
> I haven't yet updated the link to commons-openpgp - the current snapshot 
> version should be compatible to the current bouncycastle jar.
>
>
> Regarding XmlBeans:
>
> I've started to modify the build to include the maven pom on my branch,
> but for trunk you need to download a recent pom.xml and update the 
> information manually,
>
> @PJ: since 19.01.19 there's xmlbeans nexus upload lingering around - maybe 
> you want to drop it?
>
>
> For both projects, you should be able to access the nexus staging areas:
> http://repository.apache.org
> -> login with your Apache credentials
> -> Staging profiles : should contain xmlbeans and poi entries
>
> Andi
>
>

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

Re: Next release of POI/XmlBeans?

[Greg Woolsey]

I don't notice XMLBeans except when it breaks, and it hasn't been for
me, so I'm happy with that.  I'd love a new release soon with the
change I just made, that would help a lot with some significant
changes I'm submitting to the Vaadin UI component that uses POI.  And
it was my math error in the first place.  Sigh.

I've not done a release yet, but I'd be willing to read the docs and
take a stab at it if no one else has time.

On Sat, Mar 16, 2019 at 1:30 PM Andreas Beeker  wrote:
>
> Hi *,
>
> I'm currently working on getting XmlBeans fit for Java 9+ - i.e. moving the 
> resources from /schemaorg_apache_xmlbeans to a real package and being 
> compatible to former releases - and it gives me a bit of a hard time.
>
> But nevertheless we might want push the next release for POI and XmlBeans.
>
> I'm busy next week, but could take care about the releases the week 
> afterwards.
>
> How is everyone with the current snapshot of both?
>
> Anyone willing to jump in as a release manager?
>
> Andi
>
>

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

Unit Test failure

[Greg Woolsey]

Job POI-DSL-OpenJDK fails, since before my recent change, apparently,
with this stack.  It passes for me locally, and the other build
flavors pass.

Anyone know what's going on with this one?

javax.imageio.IIOException: Invalid argument to native writeImage
at com.sun.imageio.plugins.jpeg.JPEGImageWriter.writeImage(Native Method)
at 
com.sun.imageio.plugins.jpeg.JPEGImageWriter.writeOnThread(JPEGImageWriter.java:1067)
at com.sun.imageio.plugins.jpeg.JPEGImageWriter.write(JPEGImageWriter.java:363)
at javax.imageio.ImageWriter.write(ImageWriter.java:615)
at javax.imageio.ImageIO.doWrite(ImageIO.java:1612)
at javax.imageio.ImageIO.write(ImageIO.java:1578)
at org.apache.poi.hssf.usermodel.TestBugs.test46515(TestBugs.java:2949)

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

Re: Poi thread running since a long time

[Greg Woolsey]

Which version of POI are you using?  That line # is not in that method
in the latest version.  Many performance and bug fixes have gone into
releases over the last couple years.  If you have a file we can
examine/test, or even better a unit test that shows the issue against
the latest release, that would be the best way for us to help.
Testing against the latest release is the best first step, to see if
the issue has already been fixed in a newer version.

Secondly, which specific Sheet implementation are you using - HSSF,
XSSF, or SXSSF?  They all have their own implementations of
row.removeCell() which is where the manipulation of the CT* row and
cell objects takes place.


On Thu, Feb 14, 2019 at 5:53 AM smitha  wrote:
>
> Hi ,
>
> We have a import excel functionality where the user uploads a file with data
> to import.For few of the files (we do not have those samples) , the thread
> is running since a long time (252 + minutes ) at the following line  where
> we check to see if there are empty rows :
>
> java.lang.Thread.State: RUNNABLE
> at org.apache.xmlbeans.impl.store.Xobj.remove_element(Xobj.java:2232)
> at
> org.openxmlformats.schemas.spreadsheetml.x2006.main.impl.CTSheetDataImpl.removeRow(Unknown
> Source)
> - locked <0x0006d6e764f8> (a 
> org.apache.xmlbeans.impl.store.Locale)
> at 
> org.apache.poi.xssf.usermodel.XSSFSheet.removeRow(XSSFSheet.java:1990)
> at
> com.razor.app.ra.common.importer.factory.impl.XlsxExcelImporter.deleteEmptyRows(XlsxExcelImporter.java:240)
>
> Any help would be appreciated .
>
> Thanks !
>
>
>
>
> --
> 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
>

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

Re: Proposal: make HSSF/XSSF/SXSSF behavior consistent

[Greg Woolsey]

I like this, but wonder about the change to throwing runtime exceptions
(IllegalArgumentException specifically) in new cases, especially where we
are deprecating a given _input_ but not an entire function, like
setCellFormula(null).  That seems like it will break a lot of downstream
code, and cause a bunch of bug reports and mailing list traffic from folks
who haven't read the release notes.  It may be worth it, but wanted to
bring it up as a consideration.

Of course this would need to be in a 4.1.0 version, not a 4.0.2 due to the
breaking changes to API behavior (even though we could call most of this
bug fixes).

On Fri, Jan 4, 2019 at 3:15 PM Vladislav Galas  wrote:

> 1. setCellType() should be deprecated. Any value/format conversions should
> be performed outside of the cell through its public interface.
> While it's still available, we'll have to stick with conversions. In
> the next list, for any previous type not specified explicitly, the default
> value for the new type will be set.
> 1.0. In all cases except BLANK, (ignore formula and handle only
> values) OR (remove formula)? I vote for ignoring the formula. We operate on
> values here, not formula.
> 1.1. _NONE: throw IllegalArgumentException
> 1.2. BLANK: as is. Remove formula and value, keep style, comments etc.
> Should evolve into a setBlank() method someday.
> 1.3. BOOLEAN. Default value: false.
> 1.3.1 Strings: equalsIgnoreCase("true") ? true : false
> 1.3.2. Numbers: getNumericValue() != 0
> 1.4. NUMERIC. Default value: 0.
> 1.4.1. Strings: Double.parseString, default value if fails.
> 1.4.2. Bools: getBooleanValue ? 1 : 0.
> 1.5. STRING. Default value: "" (empty string).
> 1.5.1. Bools: getBooleanValue ? "TRUE" : "FALSE" (defined as
> static constants, at least in XSSF).
> 1.5.2. Numbers: Double.toString(getNumericValue()).
> 1.5. FORMULA. Throw IllegalArgumentException. Setting cell type to
> formula makes no sense.
> 2. setCellFormula()
> 2.1. setCellFormula(!null). In our reference, Excel, it's seemingly
> impossible to set a formula without Excel immediately evaluating it, even
> in manual calculation mode.
> I tried to tinker with unpacked XML. It's possible to set value
> type in a formula cell to another type, and it's possible to remove the
> value (in this case, Excel immediately converts it to 0 on load).
> Therefore, I vote for keeping old value, if any. If the cell was
> blank, set value to 0. State when formula is set and value is not should be
> illegal.
> 2.2. setCellFormula(null) shall keep the value by all means, that's
> what Excel does.
> A method removeFormula() should be added to Cell. Calling
> setCellFormula with null shall be discouraged by throwing an
> IllegalArgumentException telling user to call removeFormula().
> 3. getValueType() should be added as a transition. Implementation: return
> getCellType() == FORMULA ? getCachedFormulaResultType() : getCellType().
> Possible values will be BLANK, BOOLEAN, NUMERIC, STRING, ERROR.
> 4. get*Value should throw IllegalStateException if stored value type
> doesn't match the method.
> 5. Usage of {byte getErrorCellValue()} and setErrorCellValue(byte) should
> be discouraged in favor of using FormulaError.
> Note: writing a cell with a CIRCULAR_REF to xlsx produces a corrupt
> file. I don't have a good soultion for this. Scanning all cells for a
> circular ref and handling it somehow is clumsy and costly.
> 6. setCellValue() should ignore the formula, if any, and simply write the
> value, changing the underlying storage, if necessary. Previous value shall
> be discarded.
>
> That's it... Hope it helps us get a skinny yet complete interface and
> consistent implementations.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
> For additional commands, e-mail: dev-h...@poi.apache.org
>
>

Re: Proposal: make HSSF/XSSF/SXSSF behavior consistent

[Greg Woolsey]

Good thoughts - I'm glad you are on board and thinking about the
hard-to-track-down issues when implementations of interfaces differ in
their behavior.  I've not used the different hierarchies much, sticking
mostly to XSSF, but I can see how this could lead to tricky bugs.

I'm personally partial to default methods in interfaces now that we are up
to Java 8 for base support. That can help when the methods are well-defined
and don't need much instance state in cases where we want/need further
class distinctions and hierarchy on one branch of the implementations but
not others.  Moving to a common superclass locks in things that maybe we
want left more flexible.  I don't have an example off the top for POI, but
I've seen that other places.

However, if there is enough common behavior that it requires significant
instance state to perform, default methods become harder to maintain and a
superclass starts to look more appealing.

Looking forward to your suggestions and discussion topics.

Greg

On Fri, Jan 4, 2019 at 1:41 PM Vladislav Galas  wrote:

> Actually value/type conversion logic could (and should, imho) be moved to
> a superclass.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
> For additional commands, e-mail: dev-h...@poi.apache.org
>
>

Re: [Bug 62969] HYPERLINK() function needs a way to return link reference when display label is also specified

[Greg Woolsey]

That replacement method is no longer available, and the maps appear to be
static, so making a change would affect all threads, so I don't like that
option.  Perhaps a separate override map local to an evaluator instance
would be a possibility, but then it would need to be available in the
proper function lookup context, which may or may not be a simple option.

Good thought though, about allowing function customization, especially if
there are other functions that have side effects or multiple possible
values needed to implement Excel behavior.

On Sat, Dec 1, 2018 at 12:54 AM  wrote:

> https://bz.apache.org/bugzilla/show_bug.cgi?id=62969
>
> --- Comment #3 from Dominik Stadler  ---
> Created attachment 36288
>   --> https://bz.apache.org/bugzilla/attachment.cgi?id=36288=edit
> Workaround by overloading FunctionEval.functions
>
> I had the same problem some time ago and used a workaround by putting a
> class
> into the org.apache.poi.ss.formula.eval package and accessing the protected
> FunctionEval.functions-array this way, see the attached sample code.
>
> // MyHyperlink returns the URL Value instead of the normal text-value
> returned
> usually by the Hyperlink function
> Function func = new MyHyperlink();
>
> BuiltinFunctionsOverloader.replaceBuiltinFunction(359, func);
>
>
> Maybe we can make it possible to override functions this way in
> FunctionEval
> natively via a static FunctionEval.replaceBuiltinFunction() and provide the
> alternative implementation of Hyperlink together with sample code? This
> would
> spare us from breaking existing interfaces.
>
> --
> 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: Usage of XmlBeans triggers "clearThreadLocalMap" warnings in Tomcat with XSSF

[Greg Woolsey]

+1 for more information, like container type and version, platform, jre,
etc.  I've been using poi in a tomcat deployed webapp for nearly 15 years
and never seen this.

On Sat, Nov 3, 2018, 14:10 Dominik Stadler  There are many places in XmlBeans where ThreadLocal is used and as far as I
> could see after a quick glance, there is no easy workaround, so it would be
> good if you can report a bug at
> https://issues.apache.org/jira/secure/CreateIssue!default.jspa with some
> more description about what type of processing you perform.
>
> Thanks... Dominik.
>
>
> On Thu, Nov 1, 2018 at 6:45 AM Janakiraman <
> janakiraman.natara...@inswit.com>
> wrote:
>
> > catalina.2013-07-30.log.bz2:SEVERE: The web application /ure_v3 created
> > a ThreadLocal with key of type
> > org.apache.xmlbeans.impl.schema.SchemaTypeLoaderImpl$1 (value
> > org.apache.xmlbeans.impl.schema.SchemaTypeLoaderImpl$1@57a73656) and a
> > value of type java.util.ArrayList (value
> > java.lang.ref.SoftReference@22e0750f) but failed to remove it when the
> > web application was stopped. Threads are going to be renewed over time
> > to try and avoid a probable memory leak.
> > catalina.2013-07-30.log.bz2:SEVERE: The web application /ure_v3 created
> > a ThreadLocal with key of type org.apache.xmlbeans.impl.store.CharUtil$1
> > (value org.apache.xmlbeans.impl.store.CharUtil$1@32c00f6e) and a value
> > of type java.lang.ref.SoftReference (value
> > java.lang.ref.SoftReference@3e253dac) but failed to remove it when the
> > web application was stopped. Threads are going to be renewed over time
> > to try and avoid a probable memory leak.
> > catalina.2013-07-30.log.bz2:SEVERE: The web application /ure_v3 created
> > a ThreadLocal with key of type
> > org.apache.xmlbeans.impl.schema.SchemaTypeLoaderImpl$1 (value
> > org.apache.xmlbeans.impl.schema.SchemaTypeLoaderImpl$1@57a73656) and a
> > value of type java.util.ArrayList (value
> > java.lang.ref.SoftReference@7ef40713) but failed to remove it when the
> > web application was stopped. Threads are going to be renewed over time
> > to try and avoid a probable memory leak.
> >
> >
> > Any workaround code for able issue. I am using latest version of
> > xmlbeans3.0.1 and POI 4.0.1.
> >
> >
> > Regards,
> >
> > Janakiraman N
> >
> >
>

Re: POI 4.0.1 release

[Greg Woolsey]

+1 for next weekend/week as well.

Liking the current state of things after the initial 4.0.0 public feedback.

On Tue, Oct 30, 2018 at 8:31 AM Alain FAGOT BÉAREZ 
wrote:

> +1 to release 4.0.1
>
> The blocking issues related to charts in XDDF are now fixed. Related
> Bugzilla issue has also been resolved.
>
> Some tricks from StackOverflow tickets have been integrated into the code
> base and in the examples. Some Bugzilla issues were resolved as side
> effect.
>
> Remaining chart related issues in Bugzilla will require either some
> investigation (shifting rows and columns in XSSF) or brand new
> implementation (chart extensions like TreeMap and SunBurst). The easiest
> one is more about gathering examples from various SO tickets and building a
> new example, rather than improvement of the API for charts.
>
> ⁣Gesendet mit BlueMail ​
>
> Von: "pj.fanning"
> Gesendet: Tue Oct 30 04:59:08 GMT-03:00 2018
> An: dev@poi.apache.org
> Betreff: POI 4.0.1 release
>
> Is it time for us to look at doing a POI 4.0.1 release?
>
> Are there any issues we would like to see completed before we proceed?
>
>
>
> --
> 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
>
>
>  Originale Nachricht 
> Von: "pj.fanning" 
> Gesendet: Tue Oct 30 04:59:08 GMT-03:00 2018
> An: dev@poi.apache.org
> Betreff: POI 4.0.1 release
>
> Is it time for us to look at doing a POI 4.0.1 release?
>
> Are there any issues we would like to see completed before we proceed?
>
>
>
> --
> 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: svn commit: r1844311 - /poi/trunk/src/ooxml/java/org/apache/poi/xssf/usermodel/BaseXSSFFormulaEvaluator.java

[Greg Woolsey]

Thanks for fixing that before I got back online. Not sure how I didn't run
those tests locally.

On Fri, Oct 19, 2018 at 12:43 AM  wrote:

> Author: fanningpj
> Date: Fri Oct 19 07:43:04 2018
> New Revision: 1844311
>
> URL: http://svn.apache.org/viewvc?rev=1844311=rev
> Log:
> fix class cast issur recently introduced in BaseXSSFFormulaEvaluator
>
> Modified:
>
> poi/trunk/src/ooxml/java/org/apache/poi/xssf/usermodel/BaseXSSFFormulaEvaluator.java
>
> Modified:
> poi/trunk/src/ooxml/java/org/apache/poi/xssf/usermodel/BaseXSSFFormulaEvaluator.java
> URL:
> http://svn.apache.org/viewvc/poi/trunk/src/ooxml/java/org/apache/poi/xssf/usermodel/BaseXSSFFormulaEvaluator.java?rev=1844311=1844310=1844311=diff
>
> ==
> ---
> poi/trunk/src/ooxml/java/org/apache/poi/xssf/usermodel/BaseXSSFFormulaEvaluator.java
> (original)
> +++
> poi/trunk/src/ooxml/java/org/apache/poi/xssf/usermodel/BaseXSSFFormulaEvaluator.java
> Fri Oct 19 07:43:04 2018
> @@ -73,9 +73,14 @@ public abstract class BaseXSSFFormulaEva
>  }
>
>  protected void setCellType(Cell cell, CellType cellType) {
> -EvaluationWorkbook evaluationWorkbook = getEvaluationWorkbook();
> -BaseXSSFEvaluationWorkbook xewb =
> BaseXSSFEvaluationWorkbook.class.isAssignableFrom(evaluationWorkbook.getClass())
> ? (BaseXSSFEvaluationWorkbook) evaluationWorkbook : null;
> -
> -((XSSFCell) cell).setCellType(cellType, xewb);
> +if (cell instanceof  XSSFCell) {
> +EvaluationWorkbook evaluationWorkbook =
> getEvaluationWorkbook();
> +BaseXSSFEvaluationWorkbook xewb =
> BaseXSSFEvaluationWorkbook.class.isAssignableFrom(evaluationWorkbook.getClass())
> ? (BaseXSSFEvaluationWorkbook) evaluationWorkbook : null;
> +
> +((XSSFCell) cell).setCellType(cellType, xewb);
> +} else {
> +// could be an SXSSFCell
> +cell.setCellType(cellType);
> +}
>  }
>  }
>
>
>
> -
> To unsubscribe, e-mail: commits-unsubscr...@poi.apache.org
> For additional commands, e-mail: commits-h...@poi.apache.org
>
>

Re: "Could not resolve external workbook name" after setupReferencedWorkbooks

[Greg Woolsey]

I recently got this working, but noticed these points of fragility in doing
so with the current released code:

1. If the file names had spaces in them, I had to replace them with "%20"
in the map keys passed to setupReferencedWorkbooks(), as that's the value
used in the stored formula expressions in my end-user produced workbooks.

2. I had to be very careful to map the exact FormulaEvaluator instances
used with each workbook. If the map contained an evaluator instance
different than the one doing the evaluating for any expression, I would get
the same error you did.

3. I had to call formulaEvaluator.setupReferencedWorkbooks(evaluatorMap)
for _every_ evaluator in the map, and again, the map had to reference the
exact same evaluator instance as the one having its setup method called.

It turns out at first I had several places where new FormulaEvaluator
instances were being created, often
via workbook.getCreationHelper().createFormulaEvaluator() behind the
scenes.  This caused no end of grief until I could ensure the same instance
was used for a given workbook in a given thread every time.

I hope this helps.  Any thoughts or patches that might help facilitate
documenting how to set it up and perhaps validating setup when calling
would be appreciated.  I agree this is an area that is lightly documented
and easy to encounter problems with complex causes that are hard to trace.

On Wed, Sep 26, 2018 at 5:26 PM wimgoe...@gmail.com 
wrote:

> Hello,
>
> I need to evaluate all the formulas in a workbook which has references to
> other workbooks. Based on my findings I found that I had to use
> FormulaEvaluator#setupReferencedWorkbooks in order to link all the
> workbooks, but that did not work, and still resulted in a RuntimeException
> saying "Could not resolve external workbook name 'file.xlsx'. Workbook
> environment has not been set up."
>
> I managed to work around the problem through some hacks with reflection.
>
> BaseFormulaEvaluator seems to use static members of
> CollaboratingWorkbooksEnvironment, which creates instances of
> CollaboratingWorkbooksEnvironment. However, these instances seem to be
> constructed but not used (see CollaboratingWorkbooksEnvironment.java:75 --
> [new CollaboratingWorkbooksEnvironment(evaluatorsByName, evaluators);])
>
> I copied the contents of those methods to create a
> CollaboratingWorkbooksEnvironment, and forced it into the
> _collaboratingWorkbookEnvironment field of my WorkbookEvaluator instance.
> This solved my problem entirely.
>
> Since this solved my issue I suspect this is a bug, so decided to share it
> here in the hopes it may get fixed in the official repository.
>
> Best regards,
> Wim
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
> For additional commands, e-mail: dev-h...@poi.apache.org
>
>

Re: [VOTE] Apache POI 4.0.0 release (RC1)

[Greg Woolsey]

+1

with these sets of regression results plus the detailed checks done earlier
on the artifact contents.

On Wed, Sep 5, 2018 at 8:07 AM Tim Allison  wrote:

> +1
>
> Reports are here:
> http://162.242.228.174/reports/poi-4.0.0-reports-e.tgz
>
> These reports compare 3.17 with 4.0.0-RC1.
>
> There are numerous fixed exceptions.  The new exceptions appear to be
> caused by better exception reporting for truncated files.
>
> Two small issues that I'm ok with for now:
> 1) We're still getting _some_ more "boilerplate" language in ppt and
> pptx, e.g. "click", "level", etc.
> 2) I opened 2 issues earlier for the regressions in reading macros.
> In general, we're getting far more macros, but in a few files, those
> exceptions are causing fewer macros to be extracted.  I'm still ok
> with those as "to be fixed".
>
> Thank you, Andi!  Thank you, team!
> On Wed, Sep 5, 2018 at 12:42 AM Dominik Stadler 
> wrote:
> >
> > Hi,
> >
> > regression tests on the large corpus are done now, results are at
> >
> http://people.apache.org/~centic/poi_regression/reports/index317to400RC1.html
> > and
> >
> http://people.apache.org/~centic/poi_regression/reportsAll/index317to400RC1.html
> >
> > A number of TIMEOUT are reported, but are likely unrelated. Probably due
> to
> > the test-tool and the test-machine, currently I run this on a fairly
> small
> > machine, a larger one would definitely be better... It could be that we
> use
> > a bit more memory now somewhere which requires me to adjust memory
> settings
> > a bit.
> >
> > Otherwise only very few things, one ArrayIndexOutOfBoundsException in
> HSLF
> > related code a few times, might have been in there before and hidden by
> > OOMs/TIMEOUTs.
> >
> > So I am +1 for release.
> >
> > Dominik.
> >
> > On Sat, Sep 1, 2018 at 5:45 PM Dominik Stadler 
> > wrote:
> >
> > > Hi,
> > >
> > > Content of release-archives look good compared to 3.17.
> > >
> > > Only found a very minor glitch: osgi/build.xml and sonar/**/pom.xml
> still
> > > contain "4.0.0-SNAPSHOT", but I would not redo the release just
> because of
> > > that.
> > >
> > > Full regression test on our large body of documents is underway,
> results
> > > expected Monday, I will vote when I have those results.
> > >
> > > Dominik.
> > >
> > > On Fri, Aug 31, 2018 at 11:22 PM Andreas Beeker 
> > > wrote:
> > >
> > >> Hi,
> > >>
> > >> I've prepared artifacts for the release of Apache POI 4.0.0 (RC1).
> > >>
> > >> The most notable changes in this release are:
> > >>
> > >> - Removed support for Java 6 and 7 making Java 8 the minimum version
> > >> supported
> > >> - Unsplit packages for Jigsaw / Java 9 compatibility
> > >> - OutputStreams aren't closed by write(OutputStream) methods anymore
> > >> - Depends on new XMLBeans 3.0.1 release
> > >> - New ooxml-schema version 1.4 - use via poi-ooxml-schema (preferred)
> or
> > >> ooxml-schema artifact
> > >> - OPOIFS* classes removed / NPOIFS* classes renamed to OPOIFS*
> > >> - new XDDF classes for shared diagram/chart functionality of X**F
> modules
> > >>
> > >> https://dist.apache.org/repos/dist/dev/poi/4.0.0-RC1/
> > >>
> > >> All tests pass. ASC files verify and SHA* are correct.
> > >> There's no clutter in the src/bin packages.
> > >>
> > >> Please vote to release the artifacts.
> > >> The vote keeps open until we have have feedback from TIKA and a
> consent
> > >> on the govdocs results.
> > >>
> > >> Planned release announcement date is open.
> > >>
> > >> Here is my +1
> > >>
> > >> Andi
> > >>
> > >>
> > >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
> For additional commands, e-mail: dev-h...@poi.apache.org
>
>

Re: Remove OPOIFSFileSystem for 4.0.0?

[Greg Woolsey]

3->4 is already a big upgrade, with lots of other API changes (all the
Enums, for example).  I think the direct use of NPOIFS will be small, and
one more easy renaming migration step isn't that bad.  I'd rather not keep
even deprecated classes around longer than necessary.

On Mon, Aug 27, 2018 at 2:58 AM pj.fanning  wrote:

> I'd prefer if we rename the NPOIFS classes to POIFS but also keep
> deprecated
> NPOIFS subclasses to reduce the impact on users who will be upgrading from
> POI 3 to 4.
>
>
>
> --
> 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: Upgrade OOXML schema to 3rd edition?

[Greg Woolsey]

I don't know enough about the differences to have an opinion either way,
and won't have time to Google the diffs for myself for a few weeks.  As
long as the POI APIs stay backward compatible (with current 4.0.0 APIs) it
shouldn't matter to me.  The few places I touch CT* classes outside POI,
it's almost always because I'm stuck on an older version and I've
improved/extended the higher level APIs in trunk already to remove that
dependency when I update.

Greg

On Thu, Aug 16, 2018 at 3:04 PM Andreas Beeker  wrote:

> Hi,
>
> as we have a discussion on the user list - how about upgrading to OOXML
> v3? (see bug #56205)
>
> Andi
>
> PS: I'm still busy with removing OPOIFS ... but I think I could move this
> one in ...
>
>
>

Re: Use forrest 0.9?

[Greg Woolsey]

+1

On Tue, Jul 10, 2018 at 8:54 AM Javen O'Neal  wrote:

> +1
>

Re: [Bug 59287] Provide a write() method and change semantics of close() to not automatically write

[Greg Woolsey]

I definitely want/need an option to open a document, make changes, and
perform the equivalent of "Save As..." on the modified version.  I have
some static files I use as templates and don't want/can't modify them.
They are typically read-only files in the context of the Java process.

On Mon, Jun 25, 2018 at 1:06 PM  wrote:

> https://bz.apache.org/bugzilla/show_bug.cgi?id=59287
>
> --- Comment #5 from Mark Murphy  ---
> Seems to me that I had an issue at one point (XML document) where I wanted
> to
> read a template, make changes, and save the output as a regular document,
> but,
> it would always update the template in place. I don't know if that would
> have
> anything to do with this, but we might want to make sure that we can do
> that as
> long as we are making changes here.
>
> --
> 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: [VOTE] Re: Review #62355

[Greg Woolsey]

I also vote

a) -0 b) -1 c) +1

since 4.0 has lots of other breaking changes (removing deprecated APIs in
particular) requiring some import reorganizations isn't a big deal in my
opinion, and doesn't block the advancement toward supporting future Java
versions.

I'd rather not need to publish an additional JAR file and document which
one was needed for what contexts/purposes, and all the questions coming
from people not RTFM or JFGI.

Leaving things as-is doesn't hurt me in the next couple of years, but as
always, the longer one takes to migrate to the latest, the more pain is
involved when the time comes due.

On Mon, May 21, 2018 at 3:17 AM Andreas Beeker  wrote:

> Hi,
>
> We had a few arguments on #62355, but no decision and I don't want it to
> peter out.
>
> Would you mind, if we have a vote?
>
> a) leave it as-is - the classes stay in the java packages
>
> b) provide an additional one-big-jar
>
> c) apply the patch
>
> FYI -  there might be more changes necessary for the automatic modules to
> work,
> but in my use case (POI-Visualizer) I didn't receive any more errors.
>
> Here is my vote: a) -0 b) -1 c) +1
>
> Of course I'm open for further discussions on b)
>
> Please have a look at code modifications votings before you vote:
> https://www.apache.org/foundation/voting.html
>
> Andi
>
>

Re: Format code in XSSFSheetXMLHandler.SheetContentsHandler

[Greg Woolsey]

Don't know the history, but the value is not that straightforward.  If the
cell has a specifically assigned format, it is used.  However, format may
also be derived from conditional formatting, which may not be evaluated in
that context.  In fact, conditional formatting evaluation is quite a recent
addition to POI.  I haven't checked, but since the same or similar
formatting constructs are used, it could also come from theme or table
styles.

On Sun, May 6, 2018, 20:55 Wilson de Carvalho  wrote:

> Hi, everyone.
>
> I've been working in a solution with an implementation
> of XSSFSheetXMLHandler.SheetContentsHandler interface and struggled with
> date-formatted cells. I wonder why the format code that is present in the
> style file is not provided in method
>
> public void cell(String cellReference, String formattedValue, XSSFComment
> comment),
>
> thus making it something like:
>
> public void cell(String cellReference, String formattedValue, XSSFComment
> comment, String formatString)
>
>
> It would greatly improve user code flexibility if the format string that is
> used to define a cell was also provided in this method. It would avoid the
> need of extending org.xml.sax.helpers.DefaultHandler when the sole purpouse
> is to have access to the cell format string.
>
> Any thoughts or considerations?
>
>
> Regards,
>
> --
> Wilson de Carvalho.
>

Re: 3.18? Or push for 4?

[Greg Woolsey]

I could use a release, but if we do one soon I have some changes to
commit.  We did a bunch of work replacing ints with Enums, which are
breaking changes in most cases - would we branch somehow to avoid those?
They were slated or a theoretical 3.18 initially, I think.

On Fri, May 4, 2018 at 2:23 AM Nick Burch  wrote:

> Hi All
>
> We released 3.17 back in September, which is over 6 months ago. The
> changelog  says we've done quite a bit
> since then
>
> What do we think about another release? Do a 3.18, then breaking changes
> for 4.0 afterwards to release that in the summer? Or just finish stuff up
> and push 4.0 out soon?
>
> Nick
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
> For additional commands, e-mail: dev-h...@poi.apache.org
>
>

Re: Adding a function or two...

[Greg Woolsey]

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 
> >> 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 
>

Re: publishing poi xmlbeans jars

[Greg Woolsey]

+1

On Wed, Mar 7, 2018 at 10:03 AM Mark Murphy  wrote:

> +1
>
>
> On Wed, Mar 7, 2018 at 12:40 PM, Dave Fisher 
> wrote:
>
> > Hi -
> >
> > Let’s get back on track.
> >
> > We want to release XMLBeans 2.7.0 with the org.apache.xmlbeans namespace
> > for the benefit of all of the users who are dependent on it. If POI does
> > not want to do this then XMLBeans will need to go to the Incubator.
> >
> > Should we VOTE?
> >
> > If yes then we can ask Infra to open the JIRA and move the svn somewhere
> > with the history. We also ask for the return of the website to our LDAP.
> >
> > Regards,
> > Dave
> >
> > > On Mar 7, 2018, at 4:04 AM, Murphy, Mark 
> > wrote:
> > >
> > > If we do that, it needs to be in a major release because namespaces
> > change. If we are going to repackage to support Java 9 modules, that
> should
> > also happen at the same time.
> > >
> > > -Original Message-
> > > From: pj.fanning [mailto:fannin...@yahoo.com]
> > > Sent: Tuesday, March 06, 2018 4:35 PM
> > > To: dev@poi.apache.org
> > > Subject: Re: publishing poi xmlbeans jars
> > >
> > > I have an experimental xmlbeans jar where I changed the package name to
> > org.apache.poi.xmlbeans just to see if it was feasible to get it build. I
> > also have a poi branch that successfully uses this jar.
> > > https://repo1.maven.org/maven2/com/github/pjfanning/
> > xmlbeans/2.7.0-beta1/
> > > It should be feasible to use a commons based package name if that was
> > the route we went.
> > >
> > >
> > >
> > > --
> > > 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
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
> > > For additional commands, e-mail: dev-h...@poi.apache.org
> > >
> >
> >
>

Re: Fwd: Challenge on automatic generation of documentation

[Greg Woolsey]

+1

"never down vote an offer to document open source code" :)
I much prefer answering questions to writing documentation.

On Thu, Mar 1, 2018 at 11:42 AM 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: baffling save behavior

[Greg Woolsey]

I did it - I created a reproducible test case that involves pure POI API
calls, no starting workbook produced elsewhere.  I'll file a new bug to
reference when I commit.

On Fri, Feb 23, 2018 at 10:13 PM Greg Woolsey <greg.wool...@gmail.com>
wrote:

> Yes, I thought of a possible approach to a test case tonight while doing
> the kids' activities transportation. If I have time this weekend I'll give
> it a stab.
>
> On Fri, Feb 23, 2018, 21:48 Dominik Stadler <dominik.stad...@gmx.at>
> wrote:
>
>> Hi,
>>
>> Your analysis sounds sensible and changing onDocumentWrite() looks ok to
>> me
>> as well from a quick look at the code, we would only add an allocation of
>> the array, which is quit performance-wise compared to all the stuff that
>> happens while saving the document.
>>
>> A reproducing test-case would be nice, so we can verify this going
>> forward.
>>
>> Dominik.
>>
>>
>> On Fri, Feb 23, 2018 at 10:34 PM, Greg Woolsey <greg.wool...@gmail.com>
>> wrote:
>>
>> > I'm finally able to work around the problem by changing
>> > XSSFRow.onDocumentWrite() to always copy the current state of the _cells
>> > collection to the _row CArray, instead of only when things don't look
>> like
>> > they are ordered.  There are several cases I've uncovered where the two
>> > groups can be the same size, with the same cell reference strings in the
>> > same order, but still not equal.  One involves adding cells then saving
>> > then editing, another involves possible side effects of
>> > XSSFCell.setBlank().
>> >
>> > The safest option I can see is to just simply the method to just the
>> code
>> > inside the if(!isOrdered) statement, without the precondition
>> checking.  I
>> > copied that code to my test project and applied it after every data
>> table
>> > row update, and that fixed my issue without appearing to cause a
>> > performance hit.  In fact, removing the ordering checking probably
>> makes it
>> > a constant time change, since it was doing essentially the same loops
>> > whether it applied any changes or not.
>> >
>> > Anyone want to weigh in on that simplification of
>> > XSSFRow.onDocumentWrite()?
>> >
>> >
>> > On Fri, Feb 23, 2018 at 12:55 PM Greg Woolsey <greg.wool...@gmail.com>
>> > wrote:
>> >
>> > > For what it's worth, I'm using a build from last August.  The code
>> > changes
>> > > I'm seeing since then are almost entirely about API changes to use
>> Enums
>> > > and ints and remove deprecated methods.
>> > >
>> > > I'm suspicious there are not a lot of use cases where a document is
>> > > opened, edited, saved, edited again without re-opening, then saved
>> again.
>> > > That's where I'm seeing the sync issues, after the first save.  Then
>> some
>> > > subsequent edits get lost.  it appears to be for cells that did not
>> exist
>> > > originally, then were added by edits.  After the first save, edits to
>> > these
>> > > cells are not passed on to the CTRow, causing the second save to
>> contain
>> > > incorrect data.  I'm still digging.
>> > >
>> > > On Fri, Feb 23, 2018 at 11:09 AM Alain FAGOT BÉAREZ <
>> > abea...@for-scala.it>
>> > > wrote:
>> > >
>> > >> Hi,
>> > >>
>> > >> It might have been the same symptoms which have led Sandeep Tiwari to
>> > >> make a code change that I was reluctant to accept in the branch about
>> > >> charts in XWPF. His explanations were in the line of yours. But I
>> > couldn't
>> > >> not accept the idea that such a fundamental feature had been broken.
>> > >>
>> > >> I hope to have some time this weekend to dive into the commits
>> history
>> > to
>> > >> point out any change done recently that might affect that.
>> > >>
>> > >> Best regards,
>> > >> Alain FAGOT BÉAREZ
>> > >>
>> > >> ⁣
>> > >>
>> > >> Von: Greg Woolsey
>> > >> Gesendet: Fri Feb 23 03:53:08 GMT-03:00 2018
>> > >> An: POI Developers List
>> > >> Betreff: baffling save behavior
>> > >>
>> > >> I hesitate to even bring it up, thinking I should be able to figure
>> it
>> > >> out,
>> > >> but I've never see

Re: baffling save behavior

[Greg Woolsey]

Yes, I thought of a possible approach to a test case tonight while doing
the kids' activities transportation. If I have time this weekend I'll give
it a stab.

On Fri, Feb 23, 2018, 21:48 Dominik Stadler <dominik.stad...@gmx.at> wrote:

> Hi,
>
> Your analysis sounds sensible and changing onDocumentWrite() looks ok to me
> as well from a quick look at the code, we would only add an allocation of
> the array, which is quit performance-wise compared to all the stuff that
> happens while saving the document.
>
> A reproducing test-case would be nice, so we can verify this going forward.
>
> Dominik.
>
>
> On Fri, Feb 23, 2018 at 10:34 PM, Greg Woolsey <greg.wool...@gmail.com>
> wrote:
>
> > I'm finally able to work around the problem by changing
> > XSSFRow.onDocumentWrite() to always copy the current state of the _cells
> > collection to the _row CArray, instead of only when things don't look
> like
> > they are ordered.  There are several cases I've uncovered where the two
> > groups can be the same size, with the same cell reference strings in the
> > same order, but still not equal.  One involves adding cells then saving
> > then editing, another involves possible side effects of
> > XSSFCell.setBlank().
> >
> > The safest option I can see is to just simply the method to just the code
> > inside the if(!isOrdered) statement, without the precondition checking.
> I
> > copied that code to my test project and applied it after every data table
> > row update, and that fixed my issue without appearing to cause a
> > performance hit.  In fact, removing the ordering checking probably makes
> it
> > a constant time change, since it was doing essentially the same loops
> > whether it applied any changes or not.
> >
> > Anyone want to weigh in on that simplification of
> > XSSFRow.onDocumentWrite()?
> >
> >
> > On Fri, Feb 23, 2018 at 12:55 PM Greg Woolsey <greg.wool...@gmail.com>
> > wrote:
> >
> > > For what it's worth, I'm using a build from last August.  The code
> > changes
> > > I'm seeing since then are almost entirely about API changes to use
> Enums
> > > and ints and remove deprecated methods.
> > >
> > > I'm suspicious there are not a lot of use cases where a document is
> > > opened, edited, saved, edited again without re-opening, then saved
> again.
> > > That's where I'm seeing the sync issues, after the first save.  Then
> some
> > > subsequent edits get lost.  it appears to be for cells that did not
> exist
> > > originally, then were added by edits.  After the first save, edits to
> > these
> > > cells are not passed on to the CTRow, causing the second save to
> contain
> > > incorrect data.  I'm still digging.
> > >
> > > On Fri, Feb 23, 2018 at 11:09 AM Alain FAGOT BÉAREZ <
> > abea...@for-scala.it>
> > > wrote:
> > >
> > >> Hi,
> > >>
> > >> It might have been the same symptoms which have led Sandeep Tiwari to
> > >> make a code change that I was reluctant to accept in the branch about
> > >> charts in XWPF. His explanations were in the line of yours. But I
> > couldn't
> > >> not accept the idea that such a fundamental feature had been broken.
> > >>
> > >> I hope to have some time this weekend to dive into the commits history
> > to
> > >> point out any change done recently that might affect that.
> > >>
> > >> Best regards,
> > >> Alain FAGOT BÉAREZ
> > >>
> > >> ⁣
> > >>
> > >> Von: Greg Woolsey
> > >> Gesendet: Fri Feb 23 03:53:08 GMT-03:00 2018
> > >> An: POI Developers List
> > >> Betreff: baffling save behavior
> > >>
> > >> I hesitate to even bring it up, thinking I should be able to figure it
> > >> out,
> > >> but I've never seen behavior like this. Keep reading if you want to
> > twist
> > >> your brain in knots like mine.
> > >>
> > >> TL/DR - stop now if you'd rather be productive for your day job.
> > >>
> > >> Somehow, I have a consistent state where a file originating in Excel,
> > >> modified through POI, then saved and opened in Excel causes not just
> an
> > >> Excel repair, but incorrect/old data as well.
> > >>
> > >> So far, just a coding error, I figure. But the weirdness starts when I
> > use
> > >> the debugger to check on things. A specific row that I know c

Re: baffling save behavior

[Greg Woolsey]

I'm finally able to work around the problem by changing
XSSFRow.onDocumentWrite() to always copy the current state of the _cells
collection to the _row CArray, instead of only when things don't look like
they are ordered.  There are several cases I've uncovered where the two
groups can be the same size, with the same cell reference strings in the
same order, but still not equal.  One involves adding cells then saving
then editing, another involves possible side effects of XSSFCell.setBlank().

The safest option I can see is to just simply the method to just the code
inside the if(!isOrdered) statement, without the precondition checking.  I
copied that code to my test project and applied it after every data table
row update, and that fixed my issue without appearing to cause a
performance hit.  In fact, removing the ordering checking probably makes it
a constant time change, since it was doing essentially the same loops
whether it applied any changes or not.

Anyone want to weigh in on that simplification of XSSFRow.onDocumentWrite()?


On Fri, Feb 23, 2018 at 12:55 PM Greg Woolsey <greg.wool...@gmail.com>
wrote:

> For what it's worth, I'm using a build from last August.  The code changes
> I'm seeing since then are almost entirely about API changes to use Enums
> and ints and remove deprecated methods.
>
> I'm suspicious there are not a lot of use cases where a document is
> opened, edited, saved, edited again without re-opening, then saved again.
> That's where I'm seeing the sync issues, after the first save.  Then some
> subsequent edits get lost.  it appears to be for cells that did not exist
> originally, then were added by edits.  After the first save, edits to these
> cells are not passed on to the CTRow, causing the second save to contain
> incorrect data.  I'm still digging.
>
> On Fri, Feb 23, 2018 at 11:09 AM Alain FAGOT BÉAREZ <abea...@for-scala.it>
> wrote:
>
>> Hi,
>>
>> It might have been the same symptoms which have led Sandeep Tiwari to
>> make a code change that I was reluctant to accept in the branch about
>> charts in XWPF. His explanations were in the line of yours. But I couldn't
>> not accept the idea that such a fundamental feature had been broken.
>>
>> I hope to have some time this weekend to dive into the commits history to
>> point out any change done recently that might affect that.
>>
>> Best regards,
>> Alain FAGOT BÉAREZ
>>
>> ⁣
>>
>> Von: Greg Woolsey
>> Gesendet: Fri Feb 23 03:53:08 GMT-03:00 2018
>> An: POI Developers List
>> Betreff: baffling save behavior
>>
>> I hesitate to even bring it up, thinking I should be able to figure it
>> out,
>> but I've never seen behavior like this. Keep reading if you want to twist
>> your brain in knots like mine.
>>
>> TL/DR - stop now if you'd rather be productive for your day job.
>>
>> Somehow, I have a consistent state where a file originating in Excel,
>> modified through POI, then saved and opened in Excel causes not just an
>> Excel repair, but incorrect/old data as well.
>>
>> So far, just a coding error, I figure. But the weirdness starts when I use
>> the debugger to check on things. A specific row that I know comes out
>> wrong has the right cell values when I use
>> wb.getSheet(#).getRow(#).getCell(#).toString(), but when I check the CTRow
>> and CTCell objects, then I find the old values still. So somehow, I've got
>> the XSSFRow._cells collection out of sync with the CTRow _row contents.
>>
>> Anyone know how I could have done that?
>>
>> I may be calling workbook.write() in multiple places for different
>> purposes/copies. It looks to me like XSSFRow.onDocumentWrite() explicitly
>> replaces the CTRow array of CTCell beans with new ones due to bug, #56170,
>> but it is replacing the CTCell references in the XSSFCell objects with the
>> new copies, .
>>
>> I haven't found a smoking gun yet, but any thoughts are welcome. Perhaps
>> the issue may lie with the formula evaluator created prior to the save
>> event?
>>
>> It may be related to that bug, or even directly tied to it, as that was
>> about updating tables, and that's part of the updates my process is doing
>> as well.
>>
>> Sorry for the long document, normally I just figure these out on my own,
>> but I've been at this a week so far, which has never happened before. If
>> it comes down to black box behavior by XMLBeans, that would help explain
>> it, as I know next to nothing about that library's details.
>>
>> Greg
>>
>>
>>  Originale Nachricht 
>> Von: Greg Woolsey <greg.wool...@gmail.com>
>> Gesendet

Re: baffling save behavior

[Greg Woolsey]

For what it's worth, I'm using a build from last August.  The code changes
I'm seeing since then are almost entirely about API changes to use Enums
and ints and remove deprecated methods.

I'm suspicious there are not a lot of use cases where a document is opened,
edited, saved, edited again without re-opening, then saved again.  That's
where I'm seeing the sync issues, after the first save.  Then some
subsequent edits get lost.  it appears to be for cells that did not exist
originally, then were added by edits.  After the first save, edits to these
cells are not passed on to the CTRow, causing the second save to contain
incorrect data.  I'm still digging.

On Fri, Feb 23, 2018 at 11:09 AM Alain FAGOT BÉAREZ <abea...@for-scala.it>
wrote:

> Hi,
>
> It might have been the same symptoms which have led Sandeep Tiwari to make
> a code change that I was reluctant to accept in the branch about charts in
> XWPF. His explanations were in the line of yours. But I couldn't not accept
> the idea that such a fundamental feature had been broken.
>
> I hope to have some time this weekend to dive into the commits history to
> point out any change done recently that might affect that.
>
> Best regards,
> Alain FAGOT BÉAREZ
>
> ⁣
>
> Von: Greg Woolsey
> Gesendet: Fri Feb 23 03:53:08 GMT-03:00 2018
> An: POI Developers List
> Betreff: baffling save behavior
>
> I hesitate to even bring it up, thinking I should be able to figure it out,
> but I've never seen behavior like this. Keep reading if you want to twist
> your brain in knots like mine.
>
> TL/DR - stop now if you'd rather be productive for your day job.
>
> Somehow, I have a consistent state where a file originating in Excel,
> modified through POI, then saved and opened in Excel causes not just an
> Excel repair, but incorrect/old data as well.
>
> So far, just a coding error, I figure. But the weirdness starts when I use
> the debugger to check on things. A specific row that I know comes out
> wrong has the right cell values when I use
> wb.getSheet(#).getRow(#).getCell(#).toString(), but when I check the CTRow
> and CTCell objects, then I find the old values still. So somehow, I've got
> the XSSFRow._cells collection out of sync with the CTRow _row contents.
>
> Anyone know how I could have done that?
>
> I may be calling workbook.write() in multiple places for different
> purposes/copies. It looks to me like XSSFRow.onDocumentWrite() explicitly
> replaces the CTRow array of CTCell beans with new ones due to bug, #56170,
> but it is replacing the CTCell references in the XSSFCell objects with the
> new copies, .
>
> I haven't found a smoking gun yet, but any thoughts are welcome. Perhaps
> the issue may lie with the formula evaluator created prior to the save
> event?
>
> It may be related to that bug, or even directly tied to it, as that was
> about updating tables, and that's part of the updates my process is doing
> as well.
>
> Sorry for the long document, normally I just figure these out on my own,
> but I've been at this a week so far, which has never happened before. If
> it comes down to black box behavior by XMLBeans, that would help explain
> it, as I know next to nothing about that library's details.
>
> Greg
>
>
>  Originale Nachricht 
> Von: Greg Woolsey <greg.wool...@gmail.com>
> Gesendet: Fri Feb 23 03:53:08 GMT-03:00 2018
> An: POI Developers List <dev@poi.apache.org>
> Betreff: baffling save behavior
>
> I hesitate to even bring it up, thinking I should be able to figure it out,
> but I've never seen behavior like this.  Keep reading if you want to twist
> your brain in knots like mine.
>
> TL/DR - stop now if you'd rather be productive for your day job.
>
> Somehow, I have a consistent state where a file originating in Excel,
> modified through POI, then saved and opened in Excel causes not just an
> Excel repair, but incorrect/old data as well.
>
> So far, just a coding error, I figure.  But the weirdness starts when I use
> the debugger to check on things.  A specific row that I know comes out
> wrong has the right cell values when I use
> wb.getSheet(#).getRow(#).getCell(#).toString(), but when I check the CTRow
> and CTCell objects, then I find the old values still.  So somehow, I've got
> the XSSFRow._cells collection out of sync with the CTRow _row contents.
>
> Anyone know how I could have done that?
>
> I may be calling workbook.write() in multiple places for different
> purposes/copies.  It looks to me like XSSFRow.onDocumentWrite() explicitly
> replaces the CTRow array of CTCell beans with new ones due to bug, #56170,
> but it is replacing the CTCell references in the XSSFCell objects with the
> new copies, .
>
> I haven't 

baffling save behavior

[Greg Woolsey]

I hesitate to even bring it up, thinking I should be able to figure it out,
but I've never seen behavior like this.  Keep reading if you want to twist
your brain in knots like mine.

TL/DR - stop now if you'd rather be productive for your day job.

Somehow, I have a consistent state where a file originating in Excel,
modified through POI, then saved and opened in Excel causes not just an
Excel repair, but incorrect/old data as well.

So far, just a coding error, I figure.  But the weirdness starts when I use
the debugger to check on things.  A specific row that I know comes out
wrong has the right cell values when I use
wb.getSheet(#).getRow(#).getCell(#).toString(), but when I check the CTRow
and CTCell objects, then I find the old values still.  So somehow, I've got
the XSSFRow._cells collection out of sync with the CTRow _row contents.

Anyone know how I could have done that?

I may be calling workbook.write() in multiple places for different
purposes/copies.  It looks to me like XSSFRow.onDocumentWrite() explicitly
replaces the CTRow array of CTCell beans with new ones due to bug, #56170,
but it is replacing the CTCell references in the XSSFCell objects with the
new copies, .

I haven't found a smoking gun yet, but any thoughts are welcome.  Perhaps
the issue may lie with the formula evaluator created prior to the save
event?

It may be related to that bug, or even directly tied to it, as that was
about updating tables, and that's part of the updates my process is doing
as well.

Sorry for the long document, normally I just figure these out on my own,
but I've been at this a week so far, which has never happened before.  If
it comes down to black box behavior by XMLBeans, that would help explain
it, as I know next to nothing about that library's details.

Greg

Re: Failing gump tests

[Greg Woolsey]

+1 to stop.

I thought it was for something that depended on POI, not the other way
around.

On Sun, Feb 4, 2018, 05:11 Dominik Stadler  wrote:

> Hi,
>
> In general Gump tries to build Apache projects against the latest trunk
> versions of all the dependencies, i.e. trunk of commons-*, trunk of ant,
> ... The idea is to show newly introduced incompatibilities as early as
> possible.
>
> Unfortunately the build-configuration of Gump is a bit complicated to
> adjust, it relies on some Maven magic to inject the newer files, I have an
> installation locally that I used to adjust some small things and can take a
> look at the new dependencies if necessary. However it's overall usefulness
> is questionable for me, so we could also decide to quit using it and get
> rid of this additional hassle each time we add dependencies as we very
> rarely detect issues through it at all.
>
> How about a quick vote? Does anybody think we should keep using it for
> Apache POI or stop? Let's vote if we should stop using it:
>
> Please vote +1 if you are in favor of discontinuing it's use. -1 if you
> think it is useful and should kept operational for Apache POI
>
> I am +1 to stop using the Gump-Service.
>
> Thanks... Dominik.
>
> On Fri, Feb 2, 2018 at 12:59 PM, pj.fanning  wrote:
>
> > Hi,
> > I don't know much about the gump tests. They are failing due to the
> mockito
> > code. The gump environment seems to be set up with a CLASSPATH
> environment
> > variable and this doesn't include mockito or its dependencies (byte-buddy
> > and objenesis).
> > Can anyone give me pointers?
> >
> > http://vmgump-vm3.apache.org/poi/poi/index.html
> >
> >
> >
> > --
> > 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: ***UNCHECKED*** RE: adding dependencies on h2 and mockito

[Greg Woolsey]

If the goal is to allow for a very large shared strings hashtable, perhaps
a lighter weight option like MapDB [1][2] is a better fit?  It's JAR is
only 700K, and it looks quite reasonably featured (has an implementation of
HashMap) and flexible in its configuration for trading
memory/performance/scalability, including mmapped files and some level of
on-disk encryption [3].

[1] https://jankotek.gitbooks.io/mapdb/content/
[2] https://github.com/jankotek/mapdb/
[3] https://jankotek.gitbooks.io/mapdb/content/format/


On Fri, Jan 26, 2018 at 1:23 PM Dave Fisher <dave2w...@comcast.net> wrote:

> Hi -
>
> We need to be really careful not to make OOXML deployments larger.
>
> Why is H2, a database engine, being considered?
>
> Regards,
> Dave
>
> Sent from my iPhone
>
> > On Jan 26, 2018, at 11:55 AM, Alain FAGOT BÉAREZ <abea...@for-scala.it>
> wrote:
> >
> > You might have heard of Hypersonic SQL, some 10 years ago. H2 is the
> second version thereof.
> >
> > ⁣Gesendet mit BlueMail ​
> >
> >
> >  Originale Nachricht 
> > Von: Greg Woolsey <greg.wool...@gmail.com>
> > Gesendet: Fri Jan 26 16:42:44 GMT-03:00 2018
> > An: POI Developers List <dev@poi.apache.org>
> > Betreff: Re: ***UNCHECKED*** RE: adding dependencies on h2 and mockito
> >
> > Total dependency size is important to my deployment, and probably others.
> > I don't use SXSSF at all, and would not need/want the dependency (which
> > I've never heard of in 20 years of database and Java development, which
> is
> > strange to me, but irrelevant).  My preference is to make it optional,
> even
> > though it's more work to code.  Default would be the current behavior,
> > which works for almost everyone, apparently, and an option would be to
> > enable this behavior and manage the package availability externally.
> >
> > I suppose one could manually exclude the package as well, if SXSSF isn't
> > used at all, since Java wouldn't try to load the classes unless a class
> > referencing them was loaded, but that behavior is always subject to
> change
> > and should not be relied upon.  Plus I wouldn't want to impose that on
> > existing users who don't need/want it.
> >
> >> On Fri, Jan 26, 2018 at 4:47 AM pj.fanning <fannin...@yahoo.com> wrote:
> >>
> >> I could make h2 a `provided` dependency in our poi-ooxml pom.
> >> The use of h2 is opt-in in the new code in my PR but I'll need to
> refactor
> >> the code to allow our code not to throw ClassNotFoundException if the h2
> >> classes are not on the runtime classpath. This is do-able but my
> concern is
> >> that this is difficult to automate tests for (checking the code works
> when
> >> the h2 jar is available and when it is not).
> >>
> >> https://mvnrepository.com/artifact/com.h2database/h2 is very common
> >> dependency, so my preference would be to have the explicit dependency
> from
> >> poi-ooxml on h2 - but I'll go with whatever the consensus is.
> >>
> >>
> >>
> >> --
> >> 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
> >>
> >>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
> For additional commands, e-mail: dev-h...@poi.apache.org
>
>

Re: ***UNCHECKED*** RE: adding dependencies on h2 and mockito

[Greg Woolsey]

Total dependency size is important to my deployment, and probably others.
I don't use SXSSF at all, and would not need/want the dependency (which
I've never heard of in 20 years of database and Java development, which is
strange to me, but irrelevant).  My preference is to make it optional, even
though it's more work to code.  Default would be the current behavior,
which works for almost everyone, apparently, and an option would be to
enable this behavior and manage the package availability externally.

I suppose one could manually exclude the package as well, if SXSSF isn't
used at all, since Java wouldn't try to load the classes unless a class
referencing them was loaded, but that behavior is always subject to change
and should not be relied upon.  Plus I wouldn't want to impose that on
existing users who don't need/want it.

On Fri, Jan 26, 2018 at 4:47 AM pj.fanning  wrote:

> I could make h2 a `provided` dependency in our poi-ooxml pom.
> The use of h2 is opt-in in the new code in my PR but I'll need to refactor
> the code to allow our code not to throw ClassNotFoundException if the h2
> classes are not on the runtime classpath. This is do-able but my concern is
> that this is difficult to automate tests for (checking the code works when
> the h2 jar is available and when it is not).
>
> https://mvnrepository.com/artifact/com.h2database/h2 is very common
> dependency, so my preference would be to have the explicit dependency from
> poi-ooxml on h2 - but I'll go with whatever the consensus is.
>
>
>
> --
> 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: XMLBeans in 4.0.0 release

[Greg Woolsey]

+1 for either of those options resulting in 4.0.0 depending on an updated
and fixed XML Beans. I don't care which.  An updated attic release is
slightly preferable to me, but if that's troublesome to pull off then a POI
fork is fine.

On Tue, Jan 9, 2018, 00:28 Nick Burch  wrote:

> On Mon, 8 Jan 2018, pj.fanning wrote:
> > I understand the desire to replace XMLBeans altogether but I don't think
> > we have enough developer time available to do this in the 4.0.0 time
> > frame.
>
> Given the amount of work that'd take, and a desire for other features and
> bugs to be worked on in the mean time, I'd agree!
>
>
> > 1. Keep Apache XMLBeans 2.6.0 dependency - if users run into issues with
> > XMLBeans, they can choose to configure their own project builds to swap
> in
> > https://github.com/pjfanning/xmlbeans instead.
>
> I don't think that's a good new-user experience (nor upgrading user
> experience), the "default" they're pushed towards is known to have
> problems and they'll likely struggle with them for a while before
> discovering the fix
>
> > 2. Make https://github.com/pjfanning/xmlbeans the default dependency
> > 3. Delay POI 4.0.0 release until we can get an adequate replacement for
> > XMLBeans.
>
> I'd suggest we either go back to the Attic PMC and do a fixed release of
> XMLBeans there (based on your fixed github fork), or fork XMLBeans within
> POI (based on your fixed fork) and release a fixed release ourselves.
>
> Either way, we then have POI depend on a known-fixed rather than
> known-broken jar by default!
>
> Nick
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
> For additional commands, e-mail: dev-h...@poi.apache.org
>
>

Re: Can't compile EvaluationConditionalFormatRule

[Greg Woolsey]

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

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

On Fri, Jan 5, 2018 at 8:29 PM Blake Watson <blake.wat...@pnmac.com> wrote:

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

Re: Can't compile EvaluationConditionalFormatRule

[Greg Woolsey]

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

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

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



On Fri, Jan 5, 2018 at 4:10 PM Greg Woolsey <greg.wool...@gmail.com> wrote:

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

Re: Can't compile EvaluationConditionalFormatRule

[Greg Woolsey]

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

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

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

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

[Greg Woolsey]

Anyone know what's up with the "permission denied" errors?

On Wed, Nov 15, 2017 at 12:06 PM Apache Jenkins Server <
jenk...@builds.apache.org> wrote:

> See <
> https://builds.apache.org/job/POI-DSL-Maven/402/display/redirect?page=changes
> >
>
> Changes:
>
> [gwoolsey] ignore a unit test that snuck in.  It was created to
> investigate an open bug report.  It fails, as expected, which broke the
> build.
>
> --
> [...truncated 99.25 KB...]
> Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec
> - in org.apache.poi.ss.formula.functions.TestMatch
> Running org.apache.poi.ss.formula.functions.TestMid
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec - in
> org.apache.poi.ss.formula.functions.TestMid
> Running org.apache.poi.ss.formula.functions.TestMirr
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec
> - in org.apache.poi.ss.formula.functions.TestMirr
> Running org.apache.poi.ss.formula.functions.TestCountFuncs
> Tests run: 16, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.008 sec
> - in org.apache.poi.ss.formula.functions.TestCountFuncs
> Running org.apache.poi.ss.formula.functions.TestIntercept
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec - in
> org.apache.poi.ss.formula.functions.TestIntercept
> Running org.apache.poi.ss.formula.functions.TestSumifs
> Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec - in
> org.apache.poi.ss.formula.functions.TestSumifs
> Running
> org.apache.poi.ss.formula.functions.TestWeekNumFunctionsFromSpreadsheet2013
> Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec - in
> org.apache.poi.ss.formula.functions.TestWeekNumFunctionsFromSpreadsheet2013
> Running org.apache.poi.ss.formula.functions.TestSubtotal
> Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
> - in org.apache.poi.ss.formula.functions.TestSubtotal
> Running org.apache.poi.ss.formula.functions.TestComplex
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec - in
> org.apache.poi.ss.formula.functions.TestComplex
> Running org.apache.poi.ss.formula.functions.TestAddress
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec - in
> org.apache.poi.ss.formula.functions.TestAddress
> Running org.apache.poi.ss.formula.functions.TestBin2Dec
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec - in
> org.apache.poi.ss.formula.functions.TestBin2Dec
> Running org.apache.poi.ss.formula.functions.TestSumif
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec - in
> org.apache.poi.ss.formula.functions.TestSumif
> Running org.apache.poi.ss.formula.functions.TestText
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
> - in org.apache.poi.ss.formula.functions.TestText
> Running org.apache.poi.ss.formula.functions.TestValue
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec - in
> org.apache.poi.ss.formula.functions.TestValue
> Running org.apache.poi.ss.formula.functions.TestStatsLib
> Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec - in
> org.apache.poi.ss.formula.functions.TestStatsLib
> Running
> org.apache.poi.ss.formula.functions.TestIndexFunctionFromSpreadsheet
> Tests run: 98, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009 sec
> - in org.apache.poi.ss.formula.functions.TestIndexFunctionFromSpreadsheet
> Running org.apache.poi.ss.formula.functions.TestLen
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec - in
> org.apache.poi.ss.formula.functions.TestLen
> Running org.apache.poi.ss.formula.functions.TestDec2Hex
> Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.015 sec
> - in org.apache.poi.ss.formula.functions.TestDec2Hex
> Running org.apache.poi.ss.formula.functions.TestNpv
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec
> - in org.apache.poi.ss.formula.functions.TestNpv
> Running org.apache.poi.ss.formula.functions.TestOct2Dec
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec - in
> org.apache.poi.ss.formula.functions.TestOct2Dec
> Running org.apache.poi.ss.formula.functions.TestAverage
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec - in
> org.apache.poi.ss.formula.functions.TestAverage
> Running
> org.apache.poi.ss.formula.functions.TestDStarFunctionsFromSpreadsheet
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec - in
> org.apache.poi.ss.formula.functions.TestDStarFunctionsFromSpreadsheet
> Running org.apache.poi.ss.formula.functions.TestPPMT
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec
> - in org.apache.poi.ss.formula.functions.TestPPMT
> Running org.apache.poi.ss.formula.functions.TestDelta
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec - in
> 

Re: svn commit: r1812097 - in /poi/trunk/src: java/org/apache/poi/ddf/ java/org/apache/poi/hpsf/ java/org/apache/poi/hssf/record/aggregates/ java/org/apache/poi/hssf/usermodel/ java/org/apache/poi/ss/

[Greg Woolsey]

Shoot, I was on vacation.  The changes in PR #75 revert performance changes
from bug #57840 [1].  I don't know what the proper way to annotate them
might be, but in my testing of large files with lots of formulas, the cost
of Integer.valueOf() vs. new Integer(int) was quite large.

That usefullness of that static analysis result in particular depends on
context.

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

On Fri, Oct 13, 2017 at 2:40 AM  wrote:

> Author: centic
> Date: Fri Oct 13 09:40:22 2017
> New Revision: 1812097
>
> URL: http://svn.apache.org/viewvc?rev=1812097=rev
> Log:
> Fix some findbugs-issues and apply some code-cleanup and apply some
> smaller pull requests.
> This closes #74, This closes #75, This closes #76
>
> Modified:
> poi/trunk/src/java/org/apache/poi/ddf/AbstractEscherOptRecord.java
> poi/trunk/src/java/org/apache/poi/ddf/EscherDggRecord.java
> poi/trunk/src/java/org/apache/poi/hpsf/Variant.java
>
> poi/trunk/src/java/org/apache/poi/hssf/record/aggregates/ColumnInfoRecordsAggregate.java
> poi/trunk/src/java/org/apache/poi/hssf/usermodel/DVConstraint.java
>
> poi/trunk/src/java/org/apache/poi/ss/formula/EvaluationConditionalFormatRule.java
> poi/trunk/src/java/org/apache/poi/ss/formula/FormulaParser.java
>
> poi/trunk/src/java/org/apache/poi/ss/formula/constant/ConstantValueParser.java
> poi/trunk/src/java/org/apache/poi/ss/formula/functions/Mode.java
>
> poi/trunk/src/java/org/apache/poi/ss/formula/functions/TextFunction.java
> poi/trunk/src/java/org/apache/poi/ss/formula/functions/Value.java
> poi/trunk/src/java/org/apache/poi/ss/usermodel/DataFormatter.java
>
> poi/trunk/src/java/org/apache/poi/ss/usermodel/ExcelStyleDateFormatter.java
>
> poi/trunk/src/ooxml/java/org/apache/poi/poifs/crypt/dsig/facets/OOXMLSignatureFacet.java
>
> poi/trunk/src/ooxml/java/org/apache/poi/xssf/binary/XSSFBHyperlinksTable.java
>
> poi/trunk/src/ooxml/java/org/apache/poi/xssf/eventusermodel/XSSFBReader.java
>
> poi/trunk/src/ooxml/java/org/apache/poi/xssf/extractor/XSSFExportToXml.java
> poi/trunk/src/ooxml/java/org/apache/poi/xssf/usermodel/XSSFComment.java
> poi/trunk/src/ooxml/java/org/apache/poi/xssf/usermodel/XSSFRow.java
> poi/trunk/src/ooxml/java/org/apache/poi/xssf/usermodel/XSSFSheet.java
> poi/trunk/src/ooxml/java/org/apache/poi/xwpf/usermodel/XWPFTable.java
> poi/trunk/src/resources/devtools/findbugs-filters.xml
> poi/trunk/src/scratchpad/src/org/apache/poi/hdgf/chunks/Chunk.java
> poi/trunk/src/scratchpad/src/org/apache/poi/hsmf/dev/TypesLister.java
> poi/trunk/src/scratchpad/src/org/apache/poi/hwpf/model/CHPBinTable.java
>
> poi/trunk/src/scratchpad/src/org/apache/poi/hwpf/model/OldCHPBinTable.java
>
> poi/trunk/src/scratchpad/src/org/apache/poi/hwpf/model/OldSectionTable.java
>
> poi/trunk/src/scratchpad/src/org/apache/poi/hwpf/model/OldTextPieceTable.java
> poi/trunk/src/scratchpad/src/org/apache/poi/hwpf/model/PAPBinTable.java
>
> poi/trunk/src/scratchpad/src/org/apache/poi/hwpf/model/SectionTable.java
>
> poi/trunk/src/scratchpad/src/org/apache/poi/hwpf/model/TextPieceTable.java
>
> poi/trunk/src/scratchpad/src/org/apache/poi/hwpf/usermodel/BookmarksImpl.java
>
> poi/trunk/src/scratchpad/src/org/apache/poi/hwpf/usermodel/FieldsImpl.java
>
> Modified:
> poi/trunk/src/java/org/apache/poi/ddf/AbstractEscherOptRecord.java
> URL:
> http://svn.apache.org/viewvc/poi/trunk/src/java/org/apache/poi/ddf/AbstractEscherOptRecord.java?rev=1812097=1812096=1812097=diff
>
> ==
> --- poi/trunk/src/java/org/apache/poi/ddf/AbstractEscherOptRecord.java
> (original)
> +++ poi/trunk/src/java/org/apache/poi/ddf/AbstractEscherOptRecord.java Fri
> Oct 13 09:40:22 2017
> @@ -17,7 +17,6 @@
>  package org.apache.poi.ddf;
>
>  import java.util.ArrayList;
> -import java.util.Collections;
>  import java.util.Comparator;
>  import java.util.Iterator;
>  import java.util.List;
> @@ -135,16 +134,14 @@ public abstract class AbstractEscherOptR
>   */
>  public void sortProperties()
>  {
> -Collections.sort( properties, new Comparator()
> -{
> +properties.sort(new Comparator() {
>  @Override
> -public int compare( EscherProperty p1, EscherProperty p2 )
> -{
> +public int compare(EscherProperty p1, EscherProperty p2) {
>  short s1 = p1.getPropertyNumber();
>  short s2 = p2.getPropertyNumber();
>  return Short.compare(s1, s2);
>  }
> -} );
> +});
>  }
>
>  /**
>
> Modified: poi/trunk/src/java/org/apache/poi/ddf/EscherDggRecord.java
> URL:
> http://svn.apache.org/viewvc/poi/trunk/src/java/org/apache/poi/ddf/EscherDggRecord.java?rev=1812097=1812096=1812097=diff
>
> ==
> --- 

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

[Greg Woolsey]

+1 works-for-me

On Sat, Sep 9, 2017, 07:46 Dominik Stadler  wrote:

> Hi,
>
> Package content looks good!
>
> +1
>
> Dominik.
>
>
> On Sat, Sep 9, 2017 at 10:47 AM, 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: [VOTE] Apache POI 3.17 release (RC2)

[Greg Woolsey]

Wouldn't shock me to find out it is at the XML level - Word saving the same
text in two different ways under the same parent would be completely within
my jaded expectations.

On Thu, Aug 31, 2017 at 11:37 AM Allison, Timothy B. 
wrote:

> I ran the regression tests against docx, and I'm finding no problematic
> new exceptions. We are extracting some new text in the phonetic/ruby runs
> (great!).  However, I am finding some duplication of content within
> textboxes(? may be other sources ?).  I need to figure out if this is at
> the POI level or the Tika level.
>
> Reports are here:
> http://162.242.228.174/reports/poi-3.17-rc2-docx.tar.gz
>
> -Original Message-
> From: Allison, Timothy B. [mailto:talli...@mitre.org]
> Sent: Wednesday, August 30, 2017 8:05 PM
> To: POI Developers List 
> Subject: RE: [VOTE] Apache POI 3.17 release (RC2)
>
> I’ll run regression tests at least against our .docx tonight to make sure
> I didn’t wreck anything with 61470.
>
>
>

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

[Greg Woolsey]

I'd like to see something like the array formula support run through the
regression suite and common-crawl before we put it out there, as I suspect
there are a lot of variations to the syntax, some of which may cause things
like NPEs or other unexpected behavior.  Rather than push a big change and
see what happens, I'd like to see if we can pick up some additional unit
tests from existing files first.

I'd also prefer it not cause a delay in 3.17 to do those things and handle
any additional cases that pop up out of that testing.

That said, I'm excited to see that additional support, but think it would
be best to do that in 4.0 or a theoretical 3.18, where there is time for
test builds, more testing, and comments before baking it in.

On Wed, Aug 30, 2017 at 1:01 PM Andreas Beeker <kiwiwi...@apache.org> wrote:

> sorry, I know this is a fair bit of work
>
> The plain release candidate creation is 3 lines of shell commands.
>
> The common-crawl tests are, as far as I understood Dominik, also quite
> automated.
>
> I would object, if we would commit something big like #61469 just before
> release.
>
> So +1 for having #61468 in 3.17.
>
> If no-one minds, I would create RC3 tomorrow evening.
>
> Andi
>
>
> On 8/30/17 7:44 PM, 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 <kiwiwi...@apache.org> 
> <kiwiwi...@apache.org> 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/> 
> <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: [VOTE] Apache POI 3.17 release (RC2)

[Greg Woolsey]

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/ 
> 
>
> 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: [Bug 61469] [PATCH] Support Array Formulas and Matrix Functions

[Greg Woolsey]

This looks incredibly promising.  Worth considering for a re-opened 3.17,
or a short-cycle 3.18?  I know we get requests for array formula support on
a regular basis, and maybe it's my childhood rocket scientist hero-worship
talking, but the facility name attached gives me an initial level of hope
in the completeness and stability of the patch code.

On Tue, Aug 29, 2017 at 8:59 AM  wrote:

> https://bz.apache.org/bugzilla/show_bug.cgi?id=61469
>
> --- Comment #1 from Robert D Hulbert  ---
> Created attachment 35268
>   --> https://bz.apache.org/bugzilla/attachment.cgi?id=35268=edit
> Numeric Array Formulas and Matrix Function Test Cases
>
> --
> 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: [Bug 61468] Regression: evaluateInCell results in incorrect value for some formulas

[Greg Woolsey]

FYI, if this does turn out to be a regression bug I'd like the fix in 3.17,
or my desired Vaadin patch timeline will be delayed by a full release cycle
:(  Looking into it now, as well as what unit test(s) are needed to catch
it.

On Tue, Aug 29, 2017 at 8:57 AM <bugzi...@apache.org> wrote:

> https://bz.apache.org/bugzilla/show_bug.cgi?id=61468
>
> Greg Woolsey <gwool...@apache.org> changed:
>
>What|Removed |Added
>
> 
>Hardware|Macintosh   |All
>
> --- Comment #2 from Greg Woolsey <gwool...@apache.org> ---
> Thank you for this report and test case.  I suspect I broke this while
> adding
> some functionality I needed for my Vaadin Spreadsheet app, so I'll look
> into
> it.
>
> --
> 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: POI 4.0 and Java 8

[Greg Woolsey]

Vaadin is Java 8.

On Mon, Aug 28, 2017, 13:48 Javen O'Neal  wrote:

> 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  Subject: Re: POI 4.0 and Java 8
>
> Hi, folks.
>
> IIRC we moved to jdk7 somewhere around 1.9-1.10. Primary issue was not to
> break downstream libraries and projects of course. Same as before we will
> have to make at least two releases after decision about such a migration
> (to announce java 7 support deprecation in first release and migrate on
> next one).
>
> Since Oracle jdk7 get EOL status in 2015, it seems ok to migrate to jdk8 to
> me. We originally discussed it as a minor goal for 2.x but its release time
> frame isn't clear and, I guess, wouldn't be clear in next several months at
> least.
>
> I'd like to know what other PMCs & devs could say about downstream projects
> and migration. Apache Solr requires 1.8 since 6.0 (Apr 2016), so it
> wouldn't be an issue to them. Maybe someone could shed some light on other
> downstream who isn't on jdk8 yet.
>
> If there's no blockers for that I'm +1 for migrate to java 8.
>
>
> On Wed, Aug 23, 2017 at 1:10 AM Andreas Beeker   dev@poi.apache.org%0bSubject:%20Re:%20POI%204.0%20and%
> 20Java%208%0b%0bHi,%20folks.%0b%0bIIRC%20we%20moved%20to%
> 20jdk7%20somewhere%20around%201.9-1.10.%20Primary%20issue%
> 20was%20not%20to%20break%20downstream%20libraries%20and%20projects%20of%
> 20course.%20Same%20as%20before%20we%20will%20have%20to%20make%20at%20least%
> 20two%20releases%20after%20decision%20about%20such%20a%
> 20migration%20(to%20announce%20java%207%20support%
>
> 20deprecation%20in%20first%20release%20and%20migrate%20on%20next%20one).%0b%
> 0bSince%20Oracle%20jdk7%20get%20EOL%20status%20in%202015,%
> 20it%20seems%20ok%20to%20migrate%20to%20jdk8%20to%20me.%20We%20originally%
> 20discussed%20it%20as%20a%20minor%20goal%20for%202.x%
> 20but%20its%20release%20time%20frame%20isn't%20clear%20and,
> %20I%20guess,%20wouldn't%20be%20clear%20in%20next%20several%
> 20months%20at%20least.%0b%0bI'd%20like%20to%20know%20what%
> 20other%20PMCs%20&%20devs%20could%20say%20about%
> 20downstream%20projects%20and%20migration.%20Apache%20Solr%
> 20requires%201.8%20since%206.0%20(Apr%202016),%20so%20it%
> 20wouldn't%20be%20an%20issue%20to%20them.%20Maybe%20someone%20could%20shed%
> 20some%20light%20on%20other%20downstream%20who%20isn't%
> 20on%20jdk8%20yet.%0b%0bIf%20there's%20no%20blockers%
> 20for%20that%20I'm%20+1%20for%20migrate%20to%20java%208.%0b%
> 0b%0bOn%20Wed,%20Aug%2023,%202017%20at%201:10%20AM%20Andreas%20Beeker%20%
> 3ckiwiwi...@apache.org>> 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
> 

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

[Greg Woolsey]

Once again legacy xmlbeans disappoints.  I would prefer making the old
behavior the default, with a setting/flag/property that can change to the
faster behavior.  Consumers can then test it in their environments.

On Wed, Aug 23, 2017, 13:49 Dominik Stadler  wrote:

> Hi,
>
> regression results are in, unfortunately they don't look too good from a
> quick look.
>
> There are a number of NullPointerException and
> ArrayIndexOutOfBoundsException somewhere deep in XmlBeans code which cannot
> be reproduced when running a single file. I suspect "#61350 - Use
> unsynchronized xmlbeans" to be related. The test runs in two threads at the
> same time, but always handles separate files. This is something that we
> documented as allowed and is used by many downstream projects, only
> handling the same item in multiple threads is not supported.
>
> Do we need to make this synchronization setting configurable instead so you
> can get the additional performance if you do not use more than one thread
> at all?
>
> Additionally a few "IllegalArgumentException: typeface can't be null nor
> empty", probably related to some HSLF changes and a few others with only
> very few occurrences that I cannot match to recent changes easily.
>
> See http://people.apache.org/~centic/poi_regression/reports/ and
> http://people.apache.org/~centic/poi_regression/reportsAll/ for details.
>
> Thanks... Dominik.
>
>
> On Tue, Aug 22, 2017 at 10:49 PM, Dominik Stadler 
> wrote:
>
> > Hi,
> >
> > My regression tests are started and will hopefully finish in the next 2
> > days.
> >
> > Dominik.
> >
> > On Tue, Aug 22, 2017 at 1:06 AM, Andreas Beeker 
> > wrote:
> >
> >> You are right ... I simply wanted to push out that message, to not leave
> >> the trunk changes
> >> unaccompanied for too long.
> >>
> >> As I have to clarify with the Tika devs anyway, what their stance on
> JDK8
> >> is, this will probably
> >> take anyway a bit longer to be announced.
> >>
> >> Andi.
> >>
> >> On 8/22/17 1:00 AM, Javen O'Neal wrote:
> >>
> >> 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"  <
> kiwiwi...@apache.org> 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

[Greg Woolsey]

I'm of two minds regarding 4.0 vs. 3.18.  I know there are big changes in
discussion, that would warrant a major version, but I'm suspicious I'll
find in the next 3 months something else in formula evaluation/conditional
formatting/table styles that requires a POI bug fix, and I'd like for that
to not need to wait until a major API breaking release to get out in a
release.

That sounds like a maintenance branch to me, but I don't generally like
those very much.  So I'm not sure where I stand.

I'm leaning more toward calling a 4.0 release, since we know we want to
make those changes, and my reservations are only about unknowns, nothing
concrete.  I suppose I could get behind a 4.0 next, with the possibility of
taking the lead if needed on a possible 3.18 backport branch for bug fixes
if something significant pops up.

So my voting:

A) 4.0
B) JDK8 (7 is fine but I don't have any use/need for it)
C) yes

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: Help with task:

[Greg Woolsey]

Excellent!  One way to do it would be to submit patches or pull requests
[1] against the project that contain the new files and, if possible,
updates to the documentation web page sources [2] integrating the new
examples.

If you don't mind waiting longer for developers to review and integrate
changes you could just open a Bugzilla ticket [3] and attach examples
there.  That would rely more on a developer doing the work of integrating
the sample files in the project and documentation, which might take a
while, as we're all volunteers with families and day jobs.

I would suggest starting paralleling the existing Java examples [4].  They
can then be linked in parallel on the Examples web page [5] (currently only
spreadsheet examples), and extended to include links to the other examples
not currently referenced by the web site.  Those examples have been
developed over time in response to user questions and new functionality, so
they are a known good cross-section of POI use cases and components.

[1]  http://poi.apache.org/subversion.html
[2]  https://svn.apache.org/repos/asf/poi/site/src/documentation/
[3]  https://bz.apache.org/bugzilla/enter_bug.cgi?product=POI
[4]
https://svn.apache.org/repos/asf/poi/trunk/src/examples/src/org/apache/poi/
[5]  https://poi.apache.org/spreadsheet/examples.html


On Thu, Aug 17, 2017 at 2:19 AM Avinash Anand  wrote:

> I would like to help out with the task listed at
> https://helpwanted.apache.org/task.html?856abd21
>
> Hi Team,
>
>
> I would like to help with writing examples of using Apache poi with JVM
> languages, like kotlin.
>
>
> Regards
>
> Avinash Anand
>
> github - https://github.com/avinash-anand
>

Re: 3.17-beta2 vs. 3.17 final?

[Greg Woolsey]

I have a pull request with Vaadin [1] that is currently an echo chamber - I
think the key developer I've been in contact with is on summer holiday.  I
think I found the last bug in my POI code, and the remaining issues with
their integration tests relate to picking up a POI release with that fix
and one other issue that is entirely Vaadin based, a regression of some
form with my changes that I want their help pinning down.  So I think as
far as I'm concerned 3.17 is ready in that respect.  My next set of
submissions that depend on that PR have to do with Excel data table styles,
another esoteric area of the OOXML spec.  I've got that working and tested
in my project, so I think the POI code there is stable as well.

Replacing the chart API feels like a 4.0 thing to me for sure.  And
deprecating the existing classes/API may need to extend longer than 2
releases, similar to what's been done for the CellType change from int to
Enum, just because it's a major breaking change and there are quite a few
projects that use the chart API one way or another, either for creation or
reading.

I'm ready to vote +1 for a 3.17 release candidate this weekend.  I won't be
checking it until Tuesday, though, since I'm 2 miles from the US solar
eclipse path of totality, and we have guests from the UK arriving...

[1]  https://github.com/vaadin/spreadsheet/pull/595

On Thu, Aug 17, 2017 at 1:42 PM Andreas Beeker  wrote:

> Hi Greg,
>
> when do you know, if your chances are ok for Vaadin?
>
> if that is accepted, I would like to release 3.17 final and then switch to
> 4.0 (jdk7) -
> IIRC we discussed to immediately release 4.0-beta1 - is this correct /
> does it make sense?
>
> Regarding the API changes - I haven't checked the pull requests, but I
> usually don't mind the changes to XSLF.
> And about XSSF, we still can decide to deprecate the existing chart api in
> 4.0.
>
> So if no-one minds, I would prepare a release candidate on Sunday ...
>
> Andi
>
>
>

3.17-beta2 vs. 3.17 final?

[Greg Woolsey]

I could use a new release, don't care what we call it :)

Anyone have pending things they want to get finalized first?  We had
targeted end of summer for 3.17 final, but I don't remember any hard
criteria for what folks wanted included in 3.17.

I know there's been discussion about a new unified charts API, but as
that's new work, and should probably start out as a beta to gather feedback
and leave room for API changes, I don't feel it needs to be in 3.17.

I noticed last night my commit didn't cause any build failures, so it
appears all the work figuring out which build instances aren't stable has
paid off for now.

Re: XDDF implementation shared between XSSFChart and XSLFChart

[Greg Woolsey]

You will also need to trace through the code to find the methods and
properties referenced indirectly, via reflection, unfortunately.  To avoid
code duplication, Vaadin chose to access some properties of chart types via
reflection where the properties are common to all charts, but not defined
in a common interface.  This is part of the legacy of the OOXML design,
since XML schemas don't have inheritance.  Good job finding my code without
my follow-through, and happy Father's Day!

On Sun, Aug 13, 2017 at 7:40 PM Alain FAGOT BÉAREZ 
wrote:

> Hi,
>
> @Greg: It was Brazilian Father’s Day today, so that I did not pick up tech
> lists from bed… but only after my daughter was sleeping.
>
> I cloned and searched through the following code base:
> https://github.com/WoozyG/spreadsheet/tree/ConditionalFormatting
>
> There I found no single reference to any `usermodel.charts.*` classes that
> I am deprecating. This is good news for POI. Bad news for Vaadin people is
> that they rely on some `@Internal` method that is leaking underlying
> `CTChart` element. My feeling is that the public `getCTChart` method had
> been introduced due to some flaws in the original design of the
> `ss.usermodel.charts` API. I removed the need for it, from POI side.
>
> The rest of the Vaadin code that depends on XSSFChart requires access to
> both `@Internal public CTChart getCTChart()` and `@Internal public
> CTChartSpace getCTChartSpace()` due to the lack of `usermodel` API to wrap
> these concepts. Searching through Google, I also found similar dependencies
> on the same methods on XSLFChart in some open source projects. This may be
> work for a distinct branch later on, until we could deprecate these two
> methods.
>
> Best regards,
> Alain
> -
> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
> For additional commands, e-mail: dev-h...@poi.apache.org
>
>

Re: XDDF implementation shared between XSSFChart and XSLFChart

[Greg Woolsey]

Perhaps then it could be a parallel package to start, marked @Beta,
independent of the two existing packages, aside from reusing things like
enums perhaps.  Projects could then explore it and use it as a common
alternative.  Once it is deemed stable enough to leave beat status we could
then mark the existing packages @Deprecated and start planning for
removal.  Sounds like that could be a POI 4 type of move?

If we have it alongside the existing ones to start it may be easier to
gather feedback on the design and find ways to ease consumer code migration
before freezing the API.

I'll point you to the vaadin code on GitHub in my AM, too much work on my
phone in bed.  That's when everyone catches up on tech mailing lists, right?

On Sat, Aug 12, 2017, 22:21 Alain FAGOT BÉAREZ  wrote:

> Hi,
>
> @pjfanning: In the current state, delegating to the XDDF from the legacy
> SS and XSSF implementation would not be feasible. Some constants were
> defined in Enum types and I don’t know how to “redirect” an Enum value to
> the new implementation of it.
>
> @Greg: I don’t know how deep your code goes throughout the CT* side. For
> the user model, I tried to put as much as possible of the common code in
> the abstract XDDFChartData, XDDFChartData.Series and XDDFChartAxis, with
> concrete implementations in the subclasses. If you could point me to some
> repository where I could take a look at your current uses of chart related
> CT* internals, I could focus on preparing a user model API for these uses.
>
> @Andi: I did not put any @Removal on the @Deprecated elements. Maybe all
> the classes in the XDDF package should be marked as @Beta as well.
>
> Best regards,
> Alain
> -
> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
> For additional commands, e-mail: dev-h...@poi.apache.org
>
>

Re: XDDF implementation shared between XSSFChart and XSLFChart

[Greg Woolsey]

Vaadin7 requires Java 7, Vaadin 8 requires Java 8, so they are OK there.
POI 3.17 already has breaking changes, so they have to put off
incorporating my work until a larger release anyway, due to possible
customer dependencies.  Their next release will at least be using 3.16, so
users like me can drop in a POI version up through 3.17 before more
referenced deprecated APIs are removed.

As I diagram it more on my end, and work through the details, I suppose
putting this in 3.17 might be fine on all fronts, as long as the changes
follow the POI guidelines of deprecating but not removing methods and
classes.  It just means a fair amount of rework for me on my dependent
projects and contributions, whenever it happens.  There is a lot of code
around OOXML charts in my project and Vaadin's.

I suppose that means others will have the same issue - if we radically
change things up, it will break a lot of code for a lot of people.
Designing and planning such a move should be done carefully, APIs are about
the hardest thing to do well, and require a lot of up-front design work,
I've found.

I'll start by finding some free time to look at the pull request, and see
how much it breaks things for me.

On Fri, Aug 11, 2017 at 3:03 PM Andreas Beeker  wrote:

> > I would prefer this wait until 3.18, for purely selfish reasons, as we've
> > already released a beta for 3.17.
>
> The postponing is ok for me ... but afterwards you have the breaking
> changes anyways
> and the Vaadin guys (or you?) have to do the chart modifications twice ...
> or Vaadin
> might be stuck on 3.17 ...
>
> On the other hand ... I don't know to what degree POI is part of Vaadin,
> but POI 4.0 would
> lift the Java minimum [1]
>
> Andi
>
> [1]
> https://vaadin.com/vaadin-documentation-portlet/framework/installing/installing-java.html
>
>

Re: XDDF implementation shared between XSSFChart and XSLFChart

[Greg Woolsey]

That might work for me, I'm not sure.  Here's more background.

There is much I want to do with the charts API already, but I haven't had
time to see if this change goes in directions I'm wanting already.  In
particular I am constantly having to do variations on "instanceof" and type
casting and/or use reflection to retrieve elements common to most or all
chart types but defined without a common interface or type hierarchy.  The
current design follows the OOXML definitions, which have much overlap and
duplication but don't lend themselves to identifying common attributes.
I've started doing some of that with a parent class for axes, but there
needs to be more.  This XDDF work could help that, and at worst would
likely only move the work to a different package, not add to it.

Delegating the public API, however, may break the necessary introspection
and accessing of CT* classes done currently by both my own project and
Vaadin-Spreadsheet-Charts.  That would be a serious problem, as I'm having
to walk a very fine line already with them - they don't dedicate a lot of
resources, and I'm having to do all the heavy lifting, but I'm a one-person
operation, in charge of all of development and IT for my employer.  The
project using POI is only supposed to be half my time :)

Without testing it, I don't know yet how extensive the changes would be and
how much backward compatibility would be broken, especially given that some
of that compatibility uses reflection to access fields not necessarily
already made public, because not all chart features are accessible from the
POI API.

On Fri, Aug 11, 2017 at 9:16 AM Javen O'Neal  wrote:

> 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: XDDF implementation shared between XSSFChart and XSLFChart

[Greg Woolsey]

I'm all for standardizing the API between modules, however I have a large
amount of code using the current XSSF API, in conjunction with another
library, Vaadin-Spreadsheet.  I'm in the process of submitting a large
change request to that group , adding my features to their product.  They
already are slow to adopt POI updates when APIs have breaking changes.  I'm
worried a large change to 3.17 will disrupt my work there, now that I've
finally got their attention.

I would prefer this wait until 3.18, for purely selfish reasons, as we've
already released a beta for 3.17.

Greg

On Fri, Aug 11, 2017, 03:14 kiwiwings  wrote:

> Hi Alain,
>
> I have this issue on my todo-/watchlist, but I currently haven't got much
> time for POI.
> So if no-one else jumps in, you can ping me.
>
> We haven't yet started with the preparations for 3.17 final/4.0 - so I
> think, we'll get that one in before.
>
> Best wishes,
> Andi
>
>
>
> --
> View this message in context:
> http://apache-poi.1045710.n5.nabble.com/XDDF-implementation-shared-between-XSSFChart-and-XSLFChart-tp5728473p5728474.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: Build failed in Jenkins: POI-DSL-Maven #289

[Greg Woolsey]

SVN says I'm fully in sync with HEAD, no local differences.  And it passes
for me, but the Jenkins build failed.

On Fri, Jul 28, 2017 at 3:59 PM Andreas Beeker  wrote:

> > The two tests in error pass on my local system (Windows 10).
> > ...
> > Anyone have a clue what is happening?  This is apparently due to some
> other
> > recent change, nothing in my commit would touch this.
> So which files differ from your local installation vs. the trunk?
>
> I've done quite some changes to the HPSF classes, but that's already a few
> weeks ago ...
>
> Andi
>
>
>
>

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

[Greg Woolsey]

The two tests in error pass on my local system (Windows 10).

The test log from the build [1] show the failing workbooks used by this
test on the build servers had different contents than what I'm seeing
locally.

Specifically, locally, I'm seeing it pass because the document contains a
SummaryInformation part, but the failing run only has a
DocumentSummaryInformation part:

java.io.FileNotFoundException: no such entry: " SummaryInformation",
had: [encryption,  DocumentSummaryInformation, Workbook]


Anyone have a clue what is happening?  This is apparently due to some other
recent change, nothing in my commit would touch this.

[1]
https://builds.apache.org/job/POI-DSL-Maven/ws/sonar/main/target/surefire-reports/org.apache.poi.hssf.usermodel.TestPOIFSProperties.txt


On Fri, Jul 28, 2017 at 1:07 PM Apache Jenkins Server <
jenk...@builds.apache.org> wrote:

> See <
> https://builds.apache.org/job/POI-DSL-Maven/289/display/redirect?page=changes
> >
>
> Changes:
>
> [gwoolsey] Deleting a sheet did not delete table parts and relations.
> Deleting a table needs to also delete any queryTable relations and parts.
>
> Previous behavior didn't result in documents Excel complained about, but
> left dead entries in the ZIP structure, which made it bigger and bugged me.
>
> This change does not attempt to delete query connection definitions, as
> those aren't referenced as relations, and don't have a usage counter to
> ensure we only delete them if there are no other references.  In my samples
> I had query tables on multiple sheets using the same connection definition,
> and wanted to delete only one sheet/table but leave others.
>
> --
> [...truncated 122.52 KB...]
> Running org.apache.poi.ss.formula.atp.TestWorkdayFunction
> Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.018 sec
> - in org.apache.poi.ss.formula.atp.TestWorkdayFunction
> Running org.apache.poi.ss.formula.atp.TestIfError
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec - in
> org.apache.poi.ss.formula.atp.TestIfError
> Running org.apache.poi.ss.formula.atp.TestWorkdayCalculator
> Tests run: 17, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.012 sec
> - in org.apache.poi.ss.formula.atp.TestWorkdayCalculator
> Running org.apache.poi.ss.formula.atp.TestYearFracCalculatorFromSpreadsheet
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.043 sec
> - in org.apache.poi.ss.formula.atp.TestYearFracCalculatorFromSpreadsheet
> Running org.apache.poi.ss.formula.atp.TestYearFracCalculator
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec
> - in org.apache.poi.ss.formula.atp.TestYearFracCalculator
> Running org.apache.poi.ss.formula.atp.TestDateParser
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec
> - in org.apache.poi.ss.formula.atp.TestDateParser
> Running org.apache.poi.ss.formula.atp.TestRandBetween
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.014 sec
> - in org.apache.poi.ss.formula.atp.TestRandBetween
> Running org.apache.poi.ss.formula.TestPlainCellCache
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.532 sec
> - in org.apache.poi.ss.formula.TestPlainCellCache
> Running org.apache.poi.ss.formula.constant.TestConstantValueParser
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec - in
> org.apache.poi.ss.formula.constant.TestConstantValueParser
> Running org.apache.poi.ss.formula.udf.TestDefaultUDFFinder
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec - in
> org.apache.poi.ss.formula.udf.TestDefaultUDFFinder
> Running org.apache.poi.ss.formula.udf.TestAggregatingUDFFinder
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec - in
> org.apache.poi.ss.formula.udf.TestAggregatingUDFFinder
> Running org.apache.poi.ss.formula.TestFormulaShifter
> Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec -
> in org.apache.poi.ss.formula.TestFormulaShifter
> Running org.apache.poi.ss.formula.TestMissingWorkbook
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.005 sec
> - in org.apache.poi.ss.formula.TestMissingWorkbook
> Running org.apache.poi.ss.formula.TestWorkbookEvaluator
> Tests run: 22, Failures: 0, Errors: 0, Skipped: 4, Time elapsed: 0.046 sec
> - in org.apache.poi.ss.formula.TestWorkbookEvaluator
> Running org.apache.poi.ss.formula.TestEvaluationCache
> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 11.173 sec
> - in org.apache.poi.ss.formula.TestEvaluationCache
> Running org.apache.poi.ss.formula.ptg.TestArrayPtg
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec
> - in org.apache.poi.ss.formula.ptg.TestArrayPtg
> Running org.apache.poi.ss.formula.ptg.TestIntersectionPtg
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
> - in org.apache.poi.ss.formula.ptg.TestIntersectionPtg
> Running 

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

[Greg Woolsey]

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: Unsynchronize xmlbean calls

[Greg Woolsey]

+1, and good find by the SO user.

On Tue, Jul 25, 2017, 15:31 Andreas Beeker  wrote:

> Hi,
>
> does anyone mind, if we unsynchronize the xmlbean calls? [1]
>
> Andi
>
> [1] https://stackoverflow.com/questions/45082014/
>
>

Re: [Bug 61182] Invalid signature created for streamed xlsx file

[Greg Woolsey]

Unless there is some use case I'm missing, unit tests would be the only
place a newly written file hash would need to match a precalculated value,
meaning c) should be fine by me.  I don't think anyone should expect POI to
read a file and have the saved result be binarily equal to the input. The
only guarantee should be semantic equivalence.

On Tue, Jul 25, 2017, 03:53  wrote:

> https://bz.apache.org/bugzilla/show_bug.cgi?id=61182
>
> --- Comment #6 from Andreas Beeker  ---
> The windows/linux files differ in their line-endings, due to
> org.apache.xmlbeans.impl.store.Saver._newLine being system dependent.
>
> As the xml canonicalization handles the newlines as-is, this leads to
> different
> hashes.
>
> Currently I think about 3 options:
> a) change the _newLine static final via reflection
> b) normalize the xmls to unix linebreaks on signing
> c) add a switch in the junit test to check for windows/mac/linux hashes
>
> As the files signed by a linux system worked in Libre/MS Office, I probably
> just go with c)
>
> --
> 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: svn commit: r1800341 - in /poi/trunk/src/ooxml/java/org/apache/poi/xssf/usermodel/charts: XSSFCategoryAxis.java XSSFChartAxis.java XSSFDateAxis.java XSSFValueAxis.java

[Greg Woolsey]

Good point.  I rushed it.  There were already some like it in that class,
but they should all get that treatment.  It exists largely to provide
common access to axis elements common to the 3 kinds of axis objects.

On Thu, Jun 29, 2017, 21:00 Javen O'Neal  wrote:

> 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 

Re: [Bug 60422] DataFormatter.formatCellValue returns incorrect value for German 'Buchhaltung' format

[Greg Woolsey]

I'm suspicious Excel is doing extra work to translate formats for display
to match the OS locale display settings even though the underlying storage
always uses English standards.

On Wed, Jun 28, 2017, 11:24  wrote:

> https://bz.apache.org/bugzilla/show_bug.cgi?id=60422
>
> --- Comment #16 from PJ Fanning  ---
> Looking at wet_test.xls, the 4.33 cell has this format.
>
>  CELL_RECORD_TYPE
> .formatindex = aa
>
> This cell format is added as a custom format in FormatTrackingHSSFListener.
> The Format String is:
> _-* #,##0.00\ "€"_-;\-* #,##0.00\ "€"_-;_-* "-"??\ "€"_-;_-@_-
>
> This is not what Excel run in Germany locale on My Mac shows - it shows
> this
> for Accounting/Buchhaltung:
> _-* #.##0,00 €_-;-* #.##0,00 €_-;_-* "-"?? €_-;_-@_-
>
> Note that the decimal and grouping separators do match up.
>
> I don't know much about xls data format so I saved the file as an xlsx and
> checked the xl/styles.xml and the format string seems to match up to the
> #,##0.00 format as opposed to #.##0,00.
>
> Does anyone have any insight on this?
>
> --
> 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: Moving to Git

[Greg Woolsey]

I'd be all for that. Not particularly proficient, but I can Google like
everyone else.

On Wed, Jun 28, 2017, 01:35 Javen O'Neal  wrote:

> 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: Table Formula Manipulation and Matrix Function Implementation in HSSF/XSSF

[Greg Woolsey]

I implemented the current table formula handling, based on a patch I found
languishing in the bug database.  It's been a year or so, but here's what I
remember:

Data Table syntax works in most cases, but there is definitely room for
more test cases looking for bugs in less common scenarios - Unicode in
table header names, characters requiring quoting, references to the current
or external workbooks are some I can think of off the top.

There are exceptions and JavaDoc notes in many places stating array
formulas are not supported, and some open bugs about functions that work
only partially or incorrectly because of incomplete array formula support.
For example you can set array formulas for a sheet, but POI doesn't
evaluate them when calculating.

I don't think there is much support at all currently for anything matrix
related.  Parsing array syntax will be a tricky challenge, but if done
would likely allow a good portion of array/matrix function implementations
without much further fuss.

Table formula syntax is not allowed by Excel in places like chart
definitions.  If someone wanted to work on functionality similar to that in
Excel that can attempt to infer table/chart relationships, and thus offer
some support for automatically adjusting chart definitions based on table
additions/deletions, that would be an amazingly helpful feature to many
users, I suspect (and myself for sure! :)  )

Somewhere on one of the mailing lists was a good collection of links to
pages and videos related to implementing functions in POI, but I'm failing
to find them right now.

On Tue, Jun 27, 2017 at 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)

[Greg Woolsey]

+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: Is it time for POI 3.17-beta1?

[Greg Woolsey]

The example file with AlternateContent wrappers for table element styles is
handled correctly now by r1799733 and added as a unit test.  Existing tests
still pass for me, plus my own downstream integrations.

On Fri, Jun 23, 2017 at 1:07 PM Greg Woolsey <greg.wool...@gmail.com> wrote:

> I checked in the units merge this morning.  I'll dig more into what
> drawing does for alternate content.
>
> On Fri, Jun 23, 2017, 12:57 Andreas Beeker <kiwiwi...@apache.org> wrote:
>
>> AlternateContent is also used in XSLF and XmlBeans provides either a
>> XPath or a Cursor API,
>> to access those - just have a look at XSLFDrawing - if you need help, I
>> can support.
>>
>> So I'm waiting for your modifications (+EMUUtils merge), before preparing
>> the release candidate.
>>
>> Andi
>>
>> On 6/23/17 8:44 PM, Greg Woolsey wrote:
>> > In this particular case, the test file defines "mc:AlternateContent" for
>> > some table styles.  I've not played around with those, and the few
>> cases I
>> > see already in POI seem pretty specific to those areas of content.
>> >
>> > Anyone have strong opinions on whether XSSFTableStyle should do anything
>> > with these?  If so, anyone have experience with XMLBeans in the context
>> of
>> > finding and parsing sub-elements into CT* beans?
>> >
>> > My initial reaction is that this is a lightly used area and specific to
>> 3rd
>> > party implementations of OOXML with custom extensions, so doing nothing
>> > beyond gracefully ignoring these is a viable option for now.
>> >
>> > On Fri, Jun 23, 2017 at 10:02 AM Greg Woolsey <greg.wool...@gmail.com>
>> > wrote:
>> >
>> >> I'll take a look at that exception, I touched XSSFTableStyle.
>>
>>
>>

Re: Is it time for POI 3.17-beta1?

[Greg Woolsey]

I checked in the units merge this morning.  I'll dig more into what drawing
does for alternate content.

On Fri, Jun 23, 2017, 12:57 Andreas Beeker <kiwiwi...@apache.org> wrote:

> AlternateContent is also used in XSLF and XmlBeans provides either a XPath
> or a Cursor API,
> to access those - just have a look at XSLFDrawing - if you need help, I
> can support.
>
> So I'm waiting for your modifications (+EMUUtils merge), before preparing
> the release candidate.
>
> Andi
>
> On 6/23/17 8:44 PM, Greg Woolsey wrote:
> > In this particular case, the test file defines "mc:AlternateContent" for
> > some table styles.  I've not played around with those, and the few cases
> I
> > see already in POI seem pretty specific to those areas of content.
> >
> > Anyone have strong opinions on whether XSSFTableStyle should do anything
> > with these?  If so, anyone have experience with XMLBeans in the context
> of
> > finding and parsing sub-elements into CT* beans?
> >
> > My initial reaction is that this is a lightly used area and specific to
> 3rd
> > party implementations of OOXML with custom extensions, so doing nothing
> > beyond gracefully ignoring these is a viable option for now.
> >
> > On Fri, Jun 23, 2017 at 10:02 AM Greg Woolsey <greg.wool...@gmail.com>
> > wrote:
> >
> >> I'll take a look at that exception, I touched XSSFTableStyle.
>
>
>

Re: Is it time for POI 3.17-beta1?

[Greg Woolsey]

In this particular case, the test file defines "mc:AlternateContent" for
some table styles.  I've not played around with those, and the few cases I
see already in POI seem pretty specific to those areas of content.

Anyone have strong opinions on whether XSSFTableStyle should do anything
with these?  If so, anyone have experience with XMLBeans in the context of
finding and parsing sub-elements into CT* beans?

My initial reaction is that this is a lightly used area and specific to 3rd
party implementations of OOXML with custom extensions, so doing nothing
beyond gracefully ignoring these is a viable option for now.

On Fri, Jun 23, 2017 at 10:02 AM Greg Woolsey <greg.wool...@gmail.com>
wrote:

> I'll take a look at that exception, I touched XSSFTableStyle.
>
> On Fri, Jun 23, 2017, 09:14 Allison, Timothy B. <talli...@mitre.org>
> wrote:
>
>> My run just finished as well.
>>
>> http://162.242.228.174/reports/reports_poi-3.17-beta1.zip
>>
>> +1 to roll
>>
>> I get only one new exception (below) in an xlsx file (there are 7 new
>> zlib/gzip in embedded files) and roughly 200 fixed exceptions (mostly wmf)
>> (see: exceptions/new_exceptions_in_B_by_mime.xlsx,
>> exceptions/fixed_exceptions_in_B_by_mime.xlsx)
>>
>> There appear to be pretty sizable improvements in the common tokens
>> metric...I saw with caveats...
>> ("content/common_token_comparisons_by_mime.xlsx")
>>
>> I don't see any major red flags in the content diffs
>> ("content/content_diffs_ignore_exceptions.xlsx")
>>
>> The one new exception in xlsx:
>>
>> http://162.242.228.174/docs/commoncrawl2_extras/xlsx/NL/NLBOF7IUZGMNKT3KJSXSQIQYPXOSH3TO
>>
>> ArrayIndexOutOfBounds
>> at
>> org.openxmlformats.schemas.spreadsheetml.x2006.main.impl.CTDxfsImpl.getDxfArray(Unknown
>> Source)
>> at
>> org.apache.poi.xssf.usermodel.XSSFTableStyle.(XSSFTableStyle.java
>> at
>> org.apache.poi.xssf.model.StylesTable.readFrom(StylesTable.java:247)
>> at
>> org.apache.poi.xssf.model.StylesTable.(StylesTable.java:141)
>> at
>> org.apache.poi.xssf.eventusermodel.XSSFReader.getStylesTable(XSSFReader.java:127)
>> at
>> o.a.t.parser.microsoft.ooxml.XSSFExcelExtractorDecorator.buildXHTML(XSSFExcelExtractorDecorator.java:130)
>>
>> -Original Message-
>> From: Dominik Stadler [mailto:dominik.stad...@gmx.at]
>> Sent: Friday, June 23, 2017 6:02 AM
>> To: POI Developers List <dev@poi.apache.org>
>> Subject: Re: Is it time for POI 3.17-beta1?
>>
>> Hi,
>>
>> The 6 errors about password are actually something that I should handle
>> differently in the test-framework and is easily fixed there, so only the
>> one single failure in drawing slides remains, very nice indeed!
>>
>> Dominik.
>>
>> On Fri, Jun 23, 2017 at 11:05 AM, Dominik Stadler <dominik.stad...@gmx.at
>> >
>> wrote:
>>
>> > Hi,
>> >
>> > Mass testing results are in and look quite good. Out of 1066412
>> > documents,
>> > 136777 are detected as invalid, 76768 cause an error, error rate is
>> > 7.2% compared to 7.17% in 3.16 and 7.13% in 3.15, however we do much
>> > more checks over time, which hopefully explains the slight increase.
>> >
>> > Compared to 3.16 only 7 new errors were seen, 6 of those are related
>> > to invalid password being set (probably due to more testing now) and 1
>> > related to drawing slides.
>> >
>> > o.a.p.EncryptedDocumentException: o.a.p.EncryptedDocumentException:
>> Invalid password specified - use
>> Biff8EncryptionKey.setCurrentUserPassword() before calling extractor
>> >   at
>> o.a.p.extractor.ExtractorFactory.createEncyptedOOXMLExtractor(ExtractorFactory.java:429)
>> >   at
>> o.a.p.extractor.ExtractorFactory.createExtractor(ExtractorFactory.java:135)
>> >   at
>> o.a.p.stress.AbstractFileHandler.handleExtractingInternal(AbstractFileHandler.java:88)
>> >   at
>> > o.a.p.stress.AbstractFileHandler.handleExtracting(AbstractFileHandler.
>> > java:63) Caused by: o.a.p.EncryptedDocumentException: Invalid password
>> > specified - use Biff8EncryptionKey.setCurrentUserPassword() before
>> calling extractor
>> >   at
>> o.a.p.extractor.ExtractorFactory.createEncyptedOOXMLExtractor(ExtractorFactory.java:422)
>> >   ... 10 more
>> >
>> > java.lang.IllegalArgumentException: Start point cannot equalendpoint
>> >   at java.awt.LinearGradientPaint.(LinearGradie

Re: Is it time for POI 3.17-beta1?

[Greg Woolsey]

I'll take a look at that exception, I touched XSSFTableStyle.

On Fri, Jun 23, 2017, 09:14 Allison, Timothy B.  wrote:

> My run just finished as well.
>
> http://162.242.228.174/reports/reports_poi-3.17-beta1.zip
>
> +1 to roll
>
> I get only one new exception (below) in an xlsx file (there are 7 new
> zlib/gzip in embedded files) and roughly 200 fixed exceptions (mostly wmf)
> (see: exceptions/new_exceptions_in_B_by_mime.xlsx,
> exceptions/fixed_exceptions_in_B_by_mime.xlsx)
>
> There appear to be pretty sizable improvements in the common tokens
> metric...I saw with caveats...
> ("content/common_token_comparisons_by_mime.xlsx")
>
> I don't see any major red flags in the content diffs
> ("content/content_diffs_ignore_exceptions.xlsx")
>
> The one new exception in xlsx:
>
> http://162.242.228.174/docs/commoncrawl2_extras/xlsx/NL/NLBOF7IUZGMNKT3KJSXSQIQYPXOSH3TO
>
> ArrayIndexOutOfBounds
> at
> org.openxmlformats.schemas.spreadsheetml.x2006.main.impl.CTDxfsImpl.getDxfArray(Unknown
> Source)
> at
> org.apache.poi.xssf.usermodel.XSSFTableStyle.(XSSFTableStyle.java
> at
> org.apache.poi.xssf.model.StylesTable.readFrom(StylesTable.java:247)
> at
> org.apache.poi.xssf.model.StylesTable.(StylesTable.java:141)
> at
> org.apache.poi.xssf.eventusermodel.XSSFReader.getStylesTable(XSSFReader.java:127)
> at
> o.a.t.parser.microsoft.ooxml.XSSFExcelExtractorDecorator.buildXHTML(XSSFExcelExtractorDecorator.java:130)
>
> -Original Message-
> From: Dominik Stadler [mailto:dominik.stad...@gmx.at]
> Sent: Friday, June 23, 2017 6:02 AM
> To: POI Developers List 
> Subject: Re: Is it time for POI 3.17-beta1?
>
> Hi,
>
> The 6 errors about password are actually something that I should handle
> differently in the test-framework and is easily fixed there, so only the
> one single failure in drawing slides remains, very nice indeed!
>
> Dominik.
>
> On Fri, Jun 23, 2017 at 11:05 AM, Dominik Stadler 
> wrote:
>
> > Hi,
> >
> > Mass testing results are in and look quite good. Out of 1066412
> > documents,
> > 136777 are detected as invalid, 76768 cause an error, error rate is
> > 7.2% compared to 7.17% in 3.16 and 7.13% in 3.15, however we do much
> > more checks over time, which hopefully explains the slight increase.
> >
> > Compared to 3.16 only 7 new errors were seen, 6 of those are related
> > to invalid password being set (probably due to more testing now) and 1
> > related to drawing slides.
> >
> > o.a.p.EncryptedDocumentException: o.a.p.EncryptedDocumentException:
> Invalid password specified - use
> Biff8EncryptionKey.setCurrentUserPassword() before calling extractor
> >   at
> o.a.p.extractor.ExtractorFactory.createEncyptedOOXMLExtractor(ExtractorFactory.java:429)
> >   at
> o.a.p.extractor.ExtractorFactory.createExtractor(ExtractorFactory.java:135)
> >   at
> o.a.p.stress.AbstractFileHandler.handleExtractingInternal(AbstractFileHandler.java:88)
> >   at
> > o.a.p.stress.AbstractFileHandler.handleExtracting(AbstractFileHandler.
> > java:63) Caused by: o.a.p.EncryptedDocumentException: Invalid password
> > specified - use Biff8EncryptionKey.setCurrentUserPassword() before
> calling extractor
> >   at
> o.a.p.extractor.ExtractorFactory.createEncyptedOOXMLExtractor(ExtractorFactory.java:422)
> >   ... 10 more
> >
> > java.lang.IllegalArgumentException: Start point cannot equalendpoint
> >   at java.awt.LinearGradientPaint.(LinearGradientPaint.java:295)
> >   at
> o.a.p.sl.draw.PathGradientPaint$PathGradientContext.(PathGradientPaint.java:104)
> >   at
> o.a.p.sl.draw.PathGradientPaint.createContext(PathGradientPaint.java:61)
> >   at
> sun.java2d.pipe.AlphaPaintPipe.startSequence(AlphaPaintPipe.java:84)
> >   at sun.java2d.pipe.AAShapePipe.renderTiles(AAShapePipe.java:168)
> >   at sun.java2d.pipe.AAShapePipe.renderPath(AAShapePipe.java:159)
> >   at sun.java2d.pipe.AAShapePipe.fill(AAShapePipe.java:68)
> >   at
> sun.java2d.pipe.PixelToParallelogramConverter.fill(PixelToParallelogramConverter.java:164)
> >   at sun.java2d.pipe.ValidatePipe.fill(ValidatePipe.java:160)
> >   at sun.java2d.SunGraphics2D.fill(SunGraphics2D.java:2527)
> >   at o.a.p.sl.draw.DrawSimpleShape.draw(DrawSimpleShape.java:89)
> >   at o.a.p.sl.draw.DrawGroupShape.draw(DrawGroupShape.java:60)
> >   at o.a.p.sl.draw.DrawSheet.draw(DrawSheet.java:71)
> >   at o.a.p.sl.draw.DrawSlide.draw(DrawSlide.java:41)
> >   at o.a.p.hslf.usermodel.HSLFSlide.draw(HSLFSlide.java:489)
> >   at
> o.a.p.stress.SlideShowHandler.renderSlides(SlideShowHandler.java:120)
> >   at
> o.a.p.stress.SlideShowHandler.handleSlideShow(SlideShowHandler.java:43)
> >   at o.a.p.stress.HSLFFileHandler.handleFile(HSLFFileHandler.java:47)
> >
> > Full information and download links to sample files are at:
> > report of 3.17-beta1 overall: http://people.apache.org/~
> > 

Re: Is it time for POI 3.17-beta1?

[Greg Woolsey]

+1 from me.  Nothing pending atm, table/workbook style/theme changes in and
tested.

On Tue, Jun 20, 2017 at 12:23 PM Allison, Timothy B. 
wrote:

> +1 -- my few small changes are in.  I'll kick off my regression tests
> tonight or tomorrow.
>
> -Original Message-
> From: Dominik Stadler [mailto:dominik.stad...@gmx.at]
> Sent: Tuesday, June 20, 2017 10:00 AM
> To: POI Developers List 
> Subject: Re: Is it time for POI 3.17-beta1?
>
> Ok with me, I will try to kick off a test-run later today, typically runs
> for > 24h...
>
> Dominik.
>
> On Mon, Jun 19, 2017 at 7:20 PM, Javen O'Neal  wrote:
>
> > +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: Developing POI with an IDE

[Greg Woolsey]

MyEclipse here, because it's familiar, cheap, and simpler to install than
stock Eclipse.  Haven't bothered learning Gradle yet but it's on my list
eventually.  Notably I can't run all the unit tests directly from Eclipse,
I have to use the Ant tasks.  Haven't uncovered why yet.

On Tue, Jun 20, 2017 at 10:32 AM Javen O'Neal  wrote:

> 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: Extracting images from pptx using xslf discarding charts.

[Greg Woolsey]

I'm not familiar with the XSLF code at all, but charts are common between
Excel and PowerPoint files - the same XML elements in both, I think, so a
common codebase for rendering as an image would likely be appropriate.
Others may have more/better ideas on how best to organize it.

On Fri, Jun 16, 2017 at 7:12 AM Anil pawar <mr.anilpa...@gmail.com> wrote:

>
>
> On 2017-06-16 21:48 (+0530), Greg Woolsey <greg.wool...@gmail.com> wrote:
> > Charts are stored as a definition, not an image, and poi doesn't
> currently
> > have support for rendering them.
> >
> > On Fri, Jun 16, 2017, 05:10 Anil pawar <mr.anilpa...@gmail.com> wrote:
> >
> > > I am using xslf to convert pptx to images but unable to convert slides
> > > which contain charts.
> > > After conversion i can see taht all charts are discarded.
> > > I had added a question on https://stackoverflow.com/ also.
> > > please help.
> > >
> > > link:
> > >
> > >
> https://stackoverflow.com/questions/44152261/extracting-images-from-pptx-with-apache-poi-discarding-charts
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
> > > For additional commands, e-mail: dev-h...@poi.apache.org
> > >
> > >
> > So if i want to add this feature then where should i concentrate in code.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
> For additional commands, e-mail: dev-h...@poi.apache.org
>
>