RE: Upgrade OOXML schema to 3rd edition?

[Murphy, Mark]

If we can shift to 3rd edition without major rewrites, then that is fine. I 
looked at bug #56205, and it appears that 3rd edition should be ok. Most of the 
changes are in Word anyway, and that is not really a stable API yet.

-Original Message-
From: Alain FAGOT BÉAREZ [mailto:abea...@for-scala.it] 
Sent: Friday, August 17, 2018 8:57 AM
To: POI Developers List 
Subject: RE: Upgrade OOXML schema to 3rd edition?

As far as I understand, this will only generate the CT* and ST* classes for the 
complete OOXML jar. But the ooxml-lite will not be affected until we write 
tests that use the new classes.

I can only see one benefit for those who like Greg depend on some features not 
yet wrapped in org.apache.poi API: where they have access to the CT* object 
from the higher level API, they can start with low level tweaking. 

I still miss the down side of the upgrade. 

Best regards, 
Alain 


⁣Gesendet mit BlueMail ​


 Originale Nachricht 
Von: "Murphy, Mark" 
Gesendet: Fri Aug 17 09:13:33 GMT-03:00 2018
An: 'POI Developers List' 
Betreff: RE: Upgrade OOXML schema to 3rd edition?

This is fine for reading documents which conform to the newer standards, but we 
should always make sure that on write we conform to the least common standard 
so that older versions of Office can read them. That is if we write in 2010 
format, 2003 application will ignore bits that they don't recognize such as the 
string percent value being discussed in the user list.

-Original Message-
From: Andreas Beeker [mailto:kiwiwi...@apache.org] 
Sent: Thursday, August 16, 2018 6:04 PM
To: POI Developers List 
Subject: Upgrade OOXML schema to 3rd edition?

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: Upgrade OOXML schema to 3rd edition?

[Murphy, Mark]

This is fine for reading documents which conform to the newer standards, but we 
should always make sure that on write we conform to the least common standard 
so that older versions of Office can read them. That is if we write in 2010 
format, 2003 application will ignore bits that they don't recognize such as the 
string percent value being discussed in the user list.

-Original Message-
From: Andreas Beeker [mailto:kiwiwi...@apache.org] 
Sent: Thursday, August 16, 2018 6:04 PM
To: POI Developers List 
Subject: Upgrade OOXML schema to 3rd edition?

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: reordering xssf rows

[Murphy, Mark]

I'm thinking that you should be able to reorder things using an XMLBeans 
cursor, and maybe a quicksort.

-Original Message-
From: pj.fanning [mailto:fannin...@yahoo.com] 
Sent: Tuesday, July 10, 2018 3:40 PM
To: dev@poi.apache.org
Subject: reordering xssf rows

I've been looking at
https://github.com/apache/poi/blob/trunk/src/ooxml/testcases/org/apache/poi/xssf/usermodel/TestUnfixedBugs.java#L344

The test fails with: java.lang.AssertionError: Row 3 (1-based) is not in 
ascending order; previously saw 5

After shifting the xssf rows as part of the test, the underlying CTRows are not 
reordered.

wb.getSheetAt(0).getCTWorksheet().getSheetData().getRowList()

When the workbook is output, the rows in the output are out of order.

XMLBeans doesn't seem to make it easy to fix this.
I've tried to empty the rows on SheetData and to recreate them but this orphans 
the existing CTRows and leads to errors if I try to read off the data from the 
old rows when trying to create new ones.

org.apache.xmlbeans.impl.values.XmlValueDisconnectedException
at
org.apache.xmlbeans.impl.values.XmlObjectBase.check_orphaned(XmlObjectBase.java:1258)
at
org.openxmlformats.schemas.spreadsheetml.x2006.main.impl.CTRowImpl.getR(Unknown
Source)

It seems like the best solution to completely recreate the sheet by adding a 
new sheet, copying on all the items related to the initial sheet (with the rows 
shifted) and then removing the old sheet before then renaming the new sheet and 
putting in the right sheet order.

This does seem like a lot of work and there are risks that even this approach 
won't work.

Anyone have any thoughts on alternative solutions?



--
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: [RESULT][VOTE] Re: XMLBeans 3.0.0 release vote

[Murphy, Mark]

It was my understanding that we now own XMLBeans, and no board discussion is 
necessary to release under http://www.apache.org/dist/xmlbeans/release

I think it was just some of the attic PMC that was bringing up the issue, not 
the board. In fact, I believe the board's response was JFDI.

So we own the distribution channel, the web site, Jira, and everything else 
associated with XMLBeans. So we should just keep things simple and continue 
distributing, and updating as if we were the XMLBeans PMC (which we are).

-Original Message-
From: Andreas Beeker [mailto:kiwiwi...@apache.org] 
Sent: Monday, July 02, 2018 7:07 PM
To: dev@poi.apache.org
Subject: Re: [RESULT][VOTE] Re: XMLBeans 3.0.0 release vote

> Would it make sense to change the links ... ?

Yes, that makes sense - please change it.

I had to install Forrest 0.8 and needed to start the site build via 
//bin/forrest site plus adding the permissions to download 
forrest plugins.
I.e. committing xmlbeans/build/site will publish to the website directly

I didn't want to push the announcement before the website and release directory 
is on a current state.

There are still some (2.4.0...) leftovers on the XMLBeans website which I need 
to deal with tomorrow ...
but feel free to make any changes earlier - it would be good if all (POI) PMCs 
have a look at the old/new/modified XMLBeans website, so we don't relaunch with 
too many old links

I've put the release artifacts now under 
http://www.apache.org/dist/poi/xmlbeans/release/
as I currently don't want to go the full way of discussing further XMLBeans 
community steps (including a separate release directory under the dist root) 
with the board.

Andi

RE: XMLBeans 3.0.0 votes

[Murphy, Mark]

A. +1
B. 1.6
C. +1

-Original Message-
From: pj.fanning [mailto:fannin...@yahoo.com] 
Sent: Thursday, June 14, 2018 4:51 AM
To: dev@poi.apache.org
Subject: XMLBeans 3.0.0 votes

Can I get votes on the following?

A. Stop supporting Java 1.4
B. If we stop supporting Java 1.4, do set Java 1.6 or Java 1.8 as the minimum?
C. Do we call the next release 3.0.0?

It's inconvenient to keep supporting Java 1.4 builds.
We don't need to use Java APIs that have been introduced after Java 1.6 and 
users can run with the latest JRE if they want the latest security fixes.
If we upgrade Java min version, then we should probably do a major release.

My votes are:
A. +1
B. Java 1.6 (but happy to go to Java 1.8) C. +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


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

RE: publishing poi xmlbeans jars

[Murphy, Mark]

Since JAXB is being dropped from Java SE (deprecated in Java 9, removed in Java 
11), I don't think that this will be a problem. There may be other marshallers 
out there, but the more immediate problem is that we need to remove all JAXB 
code from POI because we can no longer rely on the JVM implementation, and the 
JAXB project is GPL code.

-Original Message-
From: Javen O'Neal [mailto:one...@apache.org] 
Sent: Thursday, March 08, 2018 9:24 PM
To: POI Developers List 
Subject: Re: publishing poi xmlbeans jars

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

+0.9 as a subproject of POI.

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

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

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

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

> +1
>
> On Wed, Mar 7, 2018 at 11:20 PM, pj.fanning  wrote:
>
> > +1
> >
> >
> >
> > --
> > Sent from: 
> > http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html
> >
> > 
> > - To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For 
> > additional commands, e-mail: dev-h...@poi.apache.org
> >
> >
>

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

RE: publishing poi xmlbeans jars

[Murphy, Mark]

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: Single Java 9 module jar?

[Murphy, Mark]

Yet another reason to consider package reorganization.

-Original Message-
From: Nick Burch [mailto:n...@apache.org] 
Sent: Friday, March 02, 2018 6:15 AM
To: dev@poi.apache.org
Subject: Single Java 9 module jar?

Hi All

>From my understanding of Java 9 modules, you basically can't have one package 
>split across multiple jars. This is an issue for us, as we do split things 
>betwen core, scratchpad and ooxml, to permit people to minimise their jar 
>sizes by excluding components they don't want.

Longer term, we could maybe look at having per-component jars. In the short 
term... I think if we just bundled the 3 jars together and dropped in a module 
info file, that'd fix things for Java 9 module users at the expense of them 
having to get all of POI (no exclusions).

Build wise, it'd be really simple - just generate an extra jar with the 
contents of the 3 base jars included, along with the module info file, and call 
it something like poi-all-java9.

What do people think of this idea? Any downsides? Comments? Suggestions?

Also, would David North like to share his Java 9 module slides from his talk a 
few weeks back? :)

Cheers
Nick

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


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

RE: Fwd: Challenge on automatic generation of documentation

[Murphy, Mark]

+1

-Original Message-
From: Alain FAGOT BÉAREZ [mailto:abea...@for-scala.it] 
Sent: Thursday, March 01, 2018 2:31 PM
To: POI Developers List 
Cc: marco.ger...@nau.edu
Subject: Re: Fwd: Challenge on automatic generation of documentation

+1

⁣


 Originale Nachricht 
Von: Dominik Stadler 
Gesendet: Thu Mar 01 16:20:40 GMT-03:00 2018
An: POI Developers List , marco.ger...@nau.edu
Betreff: Fwd: Challenge on automatic generation of documentation

Hi,

Sorry for being unresponsive, I have to forward your request to the dev-mailing 
list as I have only little time to spend on Apache POI currently and the 
resulting questions/updates would be handled by the active developers as a 
whole, so it's the whole group that will be able to decide if we want to 
participate, usually this is done via a short vote.

@devs: I think it would be useful to have POI be used in this research, so I 
vote +1 to go ahead. If anybody is interested and wants to be involved more, 
let Marco know!

Dominik.

-- Forwarded message --
From: Marco Gerosa 
Date: Mon, Feb 26, 2018 at 6:15 PM
Subject: Re: Challenge on automatic generation of documentation
To: cen...@apache.org


Dear Dominik,

Just a follow-up on the previous message. Please, let me know if you received 
it and if you have any timeline to evaluate the proposal so that I can update 
my co-organizers.

Thank you very much for your time.

Cordially,

Marco Gerosa


On Thu, Feb 22, 2018 at 8:24 AM Marco Gerosa  wrote:

> Dear Dominik,
>
> I am writing on behalf of a group of researchers from multiple 
> universities interested in software documentation. We plan to organize 
> a workshop that will include a tool challenge for automatically 
> creating Javadoc-like document and we are identifying a project on 
> which the participants will apply their tools to generate 
> documentation. The POI project would be a perfect subject for the 
> challenge. We expect that the challenge will increase the visibility 
> of the project, and hopefully produce some useful documentation for it.
>
> Do you have any objection if we use POI as a subject for the 
> challenge?  The only potential side effect that we foresee is that the 
> challenge participants may try to contact the POI developers with 
> requests for information.
>
> Assuming you have no objections, we would be very happy if you or 
> someone else from the project would get involved. There are multiple 
> ways you could be involved, such as: being an invited judge at the 
> workshop, answering questions from the organizing team, answering 
> questions from the challenge participants, or giving feedback on the 
> material we will provide to the participants.
>
> We plan to run the workshop at the end of September 2018, in Madrid, Spain.
>
>
> Sincerely,
>
>
> Marco Aurelio Gerosa
>
> Northern Arizona University
>
>
> --
> Marco A. Gerosa (http://www.marcoagerosa.com) Associate Professor 
> Northern Arizona University (http://nau.edu/siccs/)
>
--
Marco A. Gerosa (http://www.marcoagerosa.com) Associate Professor Northern 
Arizona University (http://nau.edu/siccs/)

RE: publishing poi xmlbeans jars

[Murphy, Mark]

Shortly after that thread, I found a discussion started by Dominik with the 
following options:

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

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

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

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

Dave Fisher added:
e) take XMLBeans out of the attic. Fix the bugs and make maintenance releases as
2.7, 2.8, etc. This would be an official version. Probably needs a board
resolution.

Andreas stated a preference for c) with a long tern eye for d).

Javen, Nick, and PJ responded favorable to e).

No vote taken, but from this I think we might be able to restart the 
discussion, and maybe start the process with the Attic PMC.


-Original Message-----
From: Murphy, Mark [mailto:murphym...@metalexmfg.com] 
Sent: Tuesday, February 20, 2018 11:14 AM
To: 'POI Developers List' <dev@poi.apache.org>
Subject: RE: publishing poi xmlbeans jars

Here is the specific note I found from Upayavira on 7 Nov 2017.  It is part of 
a thread named Non-maintainer upload of bugfixes for the XMLBeans library in 
the Attic:

Could POI take on XMLbeans as a second product? If they intend to maintain it, 
and can provide 3+ PMC members who will vote on releases, then presumably the 
POI project could make releases of the Apache XMLBeans product?

Then there's no naming issues, everyone benefits from public releases.
At such a point as there is enough interest, it can fork back into its own 
community. POI committers would gain commit rights on an XMLBeans repo.

Upayavira



We left it at the end of that thread indicating that we would discuss and get 
back with them. But that was really the end of organized discussion. Are there 
three people who can put their name in the hat? PJ, I am guessing you would be 
willing as you have made the fork. Just need two more. 

Are there any real objections to POI taking on XMLBeans as a second product?

-Original Message-----
From: Murphy, Mark [mailto:murphym...@metalexmfg.com]
Sent: Tuesday, February 20, 2018 10:44 AM
To: 'POI Developers List' <dev@poi.apache.org>
Subject: RE: publishing poi xmlbeans jars

I believe that we have already been offered that option, we just need a 
sufficient number of folks (I think the number was 3) to form a PMC and make a 
formal request. I don't think it is politically complicated. I don't even think 
we need a huge amount of effort as XMLBeans is largely complete and stable. It 
just needs someone to keep it up to date with new technologies.

-Original Message-
From: pj.fanning [mailto:fannin...@yahoo.com]
Sent: Tuesday, February 20, 2018 8:26 AM
To: dev@poi.apache.org
Subject: RE: publishing poi xmlbeans jars

I have a small preference from getting xmlbeans out of the attic but I don't 
know who to talk to about that.
Would someone be able to point us in then right direction?

If the attic approach is politcally complicated, then proceeding with 
publishing an org.apache.poi:xmlbeans shouldn't be hard.



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


-
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: publishing poi xmlbeans jars

[Murphy, Mark]

Here is the specific note I found from Upayavira on 7 Nov 2017.  It is part of 
a thread named Non-maintainer upload of bugfixes for the XMLBeans library in 
the Attic:

Could POI take on XMLbeans as a second product? If they intend to
maintain it, and can provide 3+ PMC members who will vote on releases,
then presumably the POI project could make releases of the Apache
XMLBeans product?

Then there's no naming issues, everyone benefits from public releases.
At such a point as there is enough interest, it can fork back into its
own community. POI committers would gain commit rights on an XMLBeans
repo.

Upayavira



We left it at the end of that thread indicating that we would discuss and get 
back with them. But that was really the end of organized discussion. Are there 
three people who can put their name in the hat? PJ, I am guessing you would be 
willing as you have made the fork. Just need two more. 

Are there any real objections to POI taking on XMLBeans as a second product?

-Original Message-
From: Murphy, Mark [mailto:murphym...@metalexmfg.com] 
Sent: Tuesday, February 20, 2018 10:44 AM
To: 'POI Developers List' <dev@poi.apache.org>
Subject: RE: publishing poi xmlbeans jars

I believe that we have already been offered that option, we just need a 
sufficient number of folks (I think the number was 3) to form a PMC and make a 
formal request. I don't think it is politically complicated. I don't even think 
we need a huge amount of effort as XMLBeans is largely complete and stable. It 
just needs someone to keep it up to date with new technologies.

-Original Message-
From: pj.fanning [mailto:fannin...@yahoo.com]
Sent: Tuesday, February 20, 2018 8:26 AM
To: dev@poi.apache.org
Subject: RE: publishing poi xmlbeans jars

I have a small preference from getting xmlbeans out of the attic but I don't 
know who to talk to about that.
Would someone be able to point us in then right direction?

If the attic approach is politcally complicated, then proceeding with 
publishing an org.apache.poi:xmlbeans shouldn't be hard.



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


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

RE: publishing poi xmlbeans jars

[Murphy, Mark]

I believe that we have already been offered that option, we just need a 
sufficient number of folks (I think the number was 3) to form a PMC and make a 
formal request. I don't think it is politically complicated. I don't even think 
we need a huge amount of effort as XMLBeans is largely complete and stable. It 
just needs someone to keep it up to date with new technologies.

-Original Message-
From: pj.fanning [mailto:fannin...@yahoo.com] 
Sent: Tuesday, February 20, 2018 8:26 AM
To: dev@poi.apache.org
Subject: RE: publishing poi xmlbeans jars

I have a small preference from getting xmlbeans out of the attic but I don't 
know who to talk to about that.
Would someone be able to point us in then right direction?

If the attic approach is politcally complicated, then proceeding with 
publishing an org.apache.poi:xmlbeans shouldn't be hard.



--
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: publishing poi xmlbeans jars

[Murphy, Mark]

I think that if we are going to update XMLBeans, we should get it out of the 
attic rather than create our own version.

-Original Message-
From: pj.fanning [mailto:fannin...@yahoo.com] 
Sent: Monday, February 19, 2018 12:02 PM
To: dev@poi.apache.org
Subject: publishing poi xmlbeans jars

If we were to publish our own xmlbeans jar, say with groupId `org.apache.poi`, 
artifactName `xmlbeans` and version `2.7.0` - how would we go about that?
I use OSS Sonatype for publishing my open source jars - but I presume that 
Apache has its own process for publishing artifacts and granting access to 
individuals to publish them.
OSS process is very straightforward - eg
https://issues.sonatype.org/browse/OSSRH-32801




--
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: Timeline for 4.0.0 release

[Murphy, Mark]

I know we said that 4.0.0 will start using semantic versioning, but we never 
really discussed release schedules. It was mentioned, but no one ever said yea 
or nay. Are we all still trying to digest what semantic versioning means to 
POI? This still has a feeling of flying by the seat of our pants.

As I see it there are a few options:
1. Use semver project wide with a single version number, with minor releases 
whenever we feel it is necessary, and major releases whenever we feel it is 
necessary to break compatibility for something. Break fix support only for 
current release.

2. Use semver project in a scheduled manner with predictable periodic minor and 
major releases. Support for current release only.

3. Same as #2 with additional bug fix support for a predictable long term 
support release.

4. Repackage to CORE, SS, WP, etc with each package having an independent beta 
version number until it is deemed stable (for now I would call CORE and SS 
stable, and everything else beta). Then use option 1, 2, or 3 above.

I personally would prefer #4 with option 1 or 3. Shifting to POI 4.0 will 
signal that we are doing something different, and would be easier to sell, but 
more work to complete. Or maybe 4.0 is the shift to semver, and 5.0 could be 
repackaging if we want to go down that path, but the reason for repackaging in 
this way is to allow for drawing and WP and Visio API's to remain designated as 
beta and thus allow breaking changes until we get to a stable state. It would 
also give us a built in way to add more pieces if desired and not have the user 
confuse a new package as stable because it has a stable version number. The 
reason to repackage now rather than wait till a future major release is that 
some packages would shift from stable to beta version numbers. I see that as 
potentially confusing.

-Original Message-
From: pj.fanning [mailto:fannin...@yahoo.com] 
Sent: Monday, February 12, 2018 2:10 PM
To: dev@poi.apache.org
Subject: Timeline for 4.0.0 release

It's over 5 months since the POI 3.17 release.
I'm wondering if we should be thinking about about releasing 4.0.0.
Is there anything that is in progress that we should consider waiting for?



--
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: adding dependencies on h2 and mockito

[Murphy, Mark]

Could the functionality be written to use H2 if it exists in the classpath, but 
stick with the current process if it does not?

-Original Message-
From: Dominik Stadler [mailto:dominik.stad...@gmx.at] 
Sent: Friday, January 26, 2018 5:10 AM
To: POI Developers List 
Subject: Re: adding dependencies on h2 and mockito

Hi,

Mockito for testing is fine for me, H2 as requirement for everybody sounds a 
bit heavy, would we still keep it optional unless somebody actually uses this 
functionality? I.e. if you have Maven/Gradle dependencies it wouldn't be 
dragged in by default?

Thanks... Dominik.

On Fri, Jan 26, 2018 at 9:03 AM, pj.fanning  wrote:

> Are there any objections to me adding dependencies on h2 jar 
> dependency for
> https://github.com/apache/poi/pull/85 and a test dependency on mockito?
> I think mockito would be useful for allowing us to test edge cases.
> An example is  https://svn.apache.org/viewvc?
> view=revision=1822253
> where creating an XSLFTextRun with a null Font Size is not straightforward.
> With mockito, it is very easy to produce such an instance.
>
>
>
> --
> 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: deprecations under semantic versioning

[Murphy, Mark]

I think with semantic versioning, we can't do anything that breaks 
compatibility except on major version changes, so no removals until 5.0. We can 
add features on minor version changes, and point changes are just for bug 
fixes. I think it would be good to schedule minor and major versions, and add 
point releases as needed for bug fixes in between. I would be good with 6 month 
minor releases, and annual major releases. I am not particularly keen on 
sticking with the two release maximum to removal. Removing deprecated items 
makes for a lot of churn if it is done too rapidly, and that will reduce the 
usefulness of POI to businesses. Which in turn encourages those businesses to 
remain on older releases. Where I am working, we are stuck at 3.14 for just 
that reason. We may make the jump to 4.0 at some point, but it will be a 
gradual migration rather than an over night refactoring simply because there is 
too much other work to go about fixing something that is not broken.

My suggestion is that deprecated methods be removed at the next major release 
as long as there has been at least one intervening minor release. So, for 
example, if we settle on 6 months for minor releases, and annual major 
releases, then anything deprecated at 4.0 would be removed at 5.0, but anything 
deprecated at 4.1 would not be removed until 6.0. Another thing to consider is 
that forcing refactoring on an annual basis will be a reason to avoid 
upgrading, so we should designate long term support releases that do not break 
compatibility. I like the Ubuntu model for this. That way folks who need to be 
on the bleeding edge can have that, but those who need less churn can still 
have bug fixes, and maybe some added features. Is maintaining multiple branches 
as easy in SVN as it is in Git? If not maybe this would be a reason to shift to 
Git as the primary repository.

-Original Message-
From: pj.fanning [mailto:fannin...@yahoo.com] 
Sent: Sunday, January 14, 2018 10:35 AM
To: dev@poi.apache.org
Subject: deprecations under semantic versioning

I haven't thought too much about the version number to put in @Removal 
annotations since we moved to semver for 4.0.0. I've just been routinely adding 
@Removal version 4.2 based on the old deprecation strategy in POI 3.x.
I'm wondering whether we should say that 4.1 is the removal version for 
anything deprecated in 4.0.x.
Or should the removal version be 5.0?

I guess the real question is about how we are going to schedule releases 
generally.
As an example, Apache Spark does a new minor release every 6 months or so (eg 
an upgrade from 2.2.x to 2.3.0). If we follow a similar strategy, then we could 
choose to keep the equivalent 2 minor releases retention so that deprecated 
methods are removed in a reasonably timely way without causing too much 
disruption by removing them too quickly.



--
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: XMLBeans in 4.0.0 release

[Murphy, Mark]

If we are going to take on maintenance of XMLBeans, I would suggest that 
getting it out of the attic would be the most appropriate course of action. 
This would reduce confusion for people trying to find XML Beans as there would 
only be a single project to reference rather than one in the attic and another 
in the POI project.

-Original Message-
From: Nick Burch [mailto:apa...@gagravarr.org] 
Sent: Thursday, January 11, 2018 12:59 AM
To: POI Developers List 
Subject: Re: XMLBeans in 4.0.0 release

On Wed, 10 Jan 2018, pj.fanning wrote:
> I don't fancy trying to merge the xmlbeans and poi ant builds. I've 
> been trying for an hour or more and still getting issues.

There's no need to do this!

We'd keep the two codebases separate, and probably release at different times. 
(XMLBeans hardly ever, except when we find bugs) All that would happen is that 
we'd swap the group ID, add POI to the release names, and update the readme etc 
to refer to POI as the PMC providing the oversight

So, assuming we're releasing it as POI rather than getting it out of the
attic:
  * Copy xmlbeans trunk in svn to
https://svn.apache.org/repos/asf/poi/xmlbeans/trunk
  * Merge in the fixes
  * Update the bin/src packages to have poi in them, eg
xmlbeans-poi-2.6.5-bin.zip
  * Update the poms to be under org.apache.poi rather than xmlbeans
  * Test, vote, release!

Or, if we want to take xmlbeans out of the attic, we'd do:
  * Vote to take it on
  * Wait for attic PMC to confirm
  * Get infra to unlock svn for xmlbeans
  * Merge in fixes
  * Test, vote, release!

Nick

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


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

RE: XMLBeans in 4.0.0 release

[Murphy, Mark]

Let me say first that I am generally not in favor of a rip and replace 
strategy. It tends to be change for the sake of change, and if we can avoid it, 
that would be better. I know that we have issues with XMLBeans, but since we 
have been offered the opportunity to patch XMLBeans, maybe that would be the 
appropriate choice rather than replacement.

On the other hand:

The current dependency is XMLBeans 2.3.0, but we could potentially bump that up 
to 2.6.0. I agree that it will take a lot of work to replace XMLBeans, and 
given we haven't identified a viable replacement, that work should be focused 
toward architecting a scheme to make its replacement easier. In the meantime, I 
don't think we can really afford to delay 4.0.0 until we have identified the 
replacement and completed the rearchitecting, and built the new scheme. Maybe 
we say that 5.0.0 will have a new plugin architecture that will decouple the 
XML marshaller from the API, and 6.0.0 would add new plugins for one or more 
additional marshallers. That is a lot of work, and would require rethinking how 
the whole POI project views reading and writing XML formats.

There are other things to consider as well. Right now we handle the XML, and 
for binary formats, the binary records in line so that we can easily retain 
unknown parts/records/XML. But do we have to do it this way. If we used a 
reader/writer strategy and maintained the document in POJOs, then maybe in each 
POJO we could have a place to store unexpected data for writing back to the 
document. Maybe that would allow us to use less memory. A reader/writer 
strategy could make it easier to keep all access using XMLBeans or whatever XML 
marshaller we decide to use in the readers and writers. And we could 
potentially have readers for various file formats, and writers for various 
formats, and therefore be able to read in CSV for example, and write back out 
in XLSX.

This decoupling would make it impossible to just go into the XML to add an 
additional feature, but that is currently true of the HxxF formats (not 
technically, but effectively due to the complexity of the HxxF formats). But it 
would make conversions to HTML and PDF much easier as we wouldn't have to write 
a converter for each format we can read, but rather a single writer for each 
format we wish to write. We could also conceivably support the OASIS Open 
Document Format this way by just adding a reader and writer for each document 
type.

This probably goes way beyond what anyone was thinking.

Anyway, I vote #1, but make sure #2 continues to work.

-Original Message-
From: pj.fanning [mailto:fannin...@yahoo.com] 
Sent: Monday, January 08, 2018 7:52 AM
To: dev@poi.apache.org
Subject: XMLBeans in 4.0.0 release

Relating to https://bz.apache.org/bugzilla/show_bug.cgi?id=59268 : would it be 
possible to have a vote on what the XMLBeans solution should be for the
4.0.0 release?
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.

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




--
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: Test document Tika-792

[Murphy, Mark]

I thought about that, but then how does the user know when deleted text or a 
Ruby exists. As it is, getText retrieves Ruby text. Or if we just retrieve 
Deleted text, how does the user know where it came from? My thought  concerning 
getText(includeDeleted) is that all the text including deleted text would be 
returned, of course you wouldn't know which text is deleted in that case.

-Original Message-
From: Allison, Timothy B. [mailto:talli...@mitre.org] 
Sent: Tuesday, December 05, 2017 8:37 AM
To: POI Developers List <dev@poi.apache.org>
Subject: RE: Test document Tika-792

getText(includeDeleted) is on the right track, I think.  Given that a run can 
have ruby text and/or be a formula and/or be any one of the many things on 
4139-4140, should we be more specific?  getDeletedText(), getRuby(), etc...

-Original Message-
From: Murphy, Mark [mailto:murphym...@metalexmfg.com]
Sent: Monday, December 4, 2017 1:10 PM
To: 'POI Developers List' <dev@poi.apache.org>
Subject: RE: Test document Tika-792

My other thought was to add a method with a signature like getText(boolean 
includeDeleted). Calling without the boolean would simply make the call to the 
new method passing false. That would change behavior for existing code to omit 
deleted text, but in my mind, the typical use case would only want active text. 
There is the Tika test, and another test that checks return of deleted text 
which would need to be adjusted. I would want to determine how HWPF works with 
deleted text.

-Original Message-
From: Allison, Timothy B. [mailto:talli...@mitre.org]
Sent: Monday, December 04, 2017 10:43 AM
To: POI Developers List <dev@poi.apache.org>
Subject: RE: Test document Tika-792

I'd prefer to avoid ThreadLocal if possible.

Could we add an enum for type of run?  Perhaps use p. 4139-4140 of Ecma ooxml 
part 1 as the types available?

In Tika, we process at the run level; we do not use paragraph's getText(), so I 
don't think we have any input on deleted text in Paragraph's getText().

-Original Message-
From: Andreas Beeker [mailto:kiwiwi...@apache.org]
Sent: Sunday, December 3, 2017 4:15 PM
To: dev@poi.apache.org
Subject: Re: Test document Tika-792

There's also a third (and probably more ...) option:
You could set an option/enum/boolean as a ThreadLocal to decide how to output 
the data.
The default might be not to return deleted text and Tika could change it when 
calling the extractor.

As the library would fill up with ThreadLocals, I wonder if we could have a 
central configuration ThreadLocal (or similar) instance?

Andi

On 12/3/17 1:34 AM, Mark Murphy wrote:
> I am working on Bug 61787 where documents containing rsidDel=00 
> are not extracting the correct text. The issue is that rsidxxx 
> attributes are just there to indicate which revision a particular 
> change belongs to, but does not necessarily indicate that a particular 
> revision actually occurred. Bug
> 58067 corrected an issue where deleted text was being returned by the
> XWPFParagraph.getText() method. Unfortunately the patch for 58067 was 
> keying on the rsidDel attribute rather than the delText tag which 
> specifically means that this is the deleted text.
>
> So I corrected this in XWPFParagraph and XWPFRun. Now a test on 
> document
> Tika-792 is failing because it is expecting getText to return deleted text.
> So what do you want to do?
>
> The options as I see them are
>
>1. To allow getText() to return all text, even deleted text, than add
>another method to only return undeleted text.
>2. Change getText() to return undeleted text, and add another method to
>retrieve all text.
>
> I prefer the second option, and I suspect that the Tika test is not 
> particularly valid as it's comment is that it's purpose is to include 
> CTBookmark classes in ooxmlLite. Tim, do you have a preference here as 
> my change will likely affect you the most.
>


B CB  [  
X  ܚX KK[XZ[  ] ][  X  ܚX P K \X K ܙ B  ܈Y][ۘ[  [X[  K[XZ[  
] Z[ K \X K ܙ B B B 
CB  [  X  
ܚX KK[XZ[  ] ][  X  ܚX P K \X K ܙ B  ܈Y][ۘ[  [X[  K[XZ[  ] 
Z[ K \X K ܙ B B

RE: Test document Tika-792

[Murphy, Mark]

My other thought was to add a method with a signature like getText(boolean 
includeDeleted). Calling without the boolean would simply make the call to the 
new method passing false. That would change behavior for existing code to omit 
deleted text, but in my mind, the typical use case would only want active text. 
There is the Tika test, and another test that checks return of deleted text 
which would need to be adjusted. I would want to determine how HWPF works with 
deleted text.

-Original Message-
From: Allison, Timothy B. [mailto:talli...@mitre.org] 
Sent: Monday, December 04, 2017 10:43 AM
To: POI Developers List 
Subject: RE: Test document Tika-792

I'd prefer to avoid ThreadLocal if possible.

Could we add an enum for type of run?  Perhaps use p. 4139-4140 of Ecma ooxml 
part 1 as the types available?

In Tika, we process at the run level; we do not use paragraph's getText(), so I 
don't think we have any input on deleted text in Paragraph's getText().

-Original Message-
From: Andreas Beeker [mailto:kiwiwi...@apache.org]
Sent: Sunday, December 3, 2017 4:15 PM
To: dev@poi.apache.org
Subject: Re: Test document Tika-792

There's also a third (and probably more ...) option:
You could set an option/enum/boolean as a ThreadLocal to decide how to output 
the data.
The default might be not to return deleted text and Tika could change it when 
calling the extractor.

As the library would fill up with ThreadLocals, I wonder if we could have a 
central configuration ThreadLocal (or similar) instance?

Andi

On 12/3/17 1:34 AM, Mark Murphy wrote:
> I am working on Bug 61787 where documents containing rsidDel=00 
> are not extracting the correct text. The issue is that rsidxxx 
> attributes are just there to indicate which revision a particular 
> change belongs to, but does not necessarily indicate that a particular 
> revision actually occurred. Bug
> 58067 corrected an issue where deleted text was being returned by the
> XWPFParagraph.getText() method. Unfortunately the patch for 58067 was 
> keying on the rsidDel attribute rather than the delText tag which 
> specifically means that this is the deleted text.
>
> So I corrected this in XWPFParagraph and XWPFRun. Now a test on 
> document
> Tika-792 is failing because it is expecting getText to return deleted text.
> So what do you want to do?
>
> The options as I see them are
>
>1. To allow getText() to return all text, even deleted text, than add
>another method to only return undeleted text.
>2. Change getText() to return undeleted text, and add another method to
>retrieve all text.
>
> I prefer the second option, and I suspect that the Tika test is not 
> particularly valid as it's comment is that it's purpose is to include 
> CTBookmark classes in ooxmlLite. Tim, do you have a preference here as 
> my change will likely affect you the most.
>


B CB  [  
X  ܚX KK[XZ[
 ] ][  X  ܚX P K \X K ܙ B  ܈Y][ۘ[  [X[  K[XZ[
 ] Z[ K \X K ܙ B B

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

[Murphy, Mark]

This actually seems to be an optimal solution as we wouldn't need to worry 
about refactoring in a new XML binding scheme, and as Java and technology moves 
forward, other users of XMLBeans are likely to be affected by the same bugs 
that we are having issues with.

-Original Message-
From: Upayavira [mailto:u...@odoko.co.uk] 
Sent: Tuesday, November 07, 2017 12:16 PM
To: Javen O'Neal ; POI Developers List 
Cc: gene...@attic.apache.org; d...@xmlbeans.apache.org
Subject: Suspected Spam:Re: Non-maintainer upload of bugfixes for the XMLBeans 
library in the Attic

Could POI take on XMLbeans as a second product? If they intend to maintain it, 
and can provide 3+ PMC members who will vote on releases, then presumably the 
POI project could make releases of the Apache XMLBeans product?

Then there's no naming issues, everyone benefits from public releases.
At such a point as there is enough interest, it can fork back into its own 
community. POI committers would gain commit rights on an XMLBeans repo.

Upayavira

On Tue, 7 Nov 2017, at 04:59 PM, Javen O'Neal wrote:
> Any other project using XMLBeans on Android would likely be affected 
> by the same issue. Making the XMLBeans update within the POI source 
> code or POI maven coordinates would make it more difficult for others 
> to find this update.
> 
> If we had to change the Java package name to 
> org.apache.poi.internal.xmlbeans, it would take a bit of trickery to 
> allow users to continue using the official releases, XMLBeans 2.3.0 or 
> 2.6.0 if the bug doesn't affect them.
> 
> On Nov 7, 2017 03:41, "sebb"  wrote:
> 
> On 7 November 2017 at 07:20, jan iversen  wrote:
> >
> >
> > Sent from my iPad
> >
> >> On 6 Nov 2017, at 21:47, Dominik Stadler  wrote:
> >>
> >> Hi,
> >>
> >> The Apache XMLBeans library was moved to the Attic a few years ago 
> >> (05/2014), however Apache POI still uses the library as it's core 
> >> XML binding framework.
> >>
> >> While the Apache POI PMC and the development community is already 
> >> discussing possible replacements for some time, use of XMLBeans is 
> >> still deeply rooted and thus hard to replace quickly.
> >>
> >> Over time, we discovered a few grave bugs in XMLBeans which lead to 
> >> bug-reports that we cannot fix ourselves.
> >>
> >> Therefore we would like to start discussion about an NMU of 
> >> XMLBeans to
> get
> >> a fix for the most pressing issues.
> >>
> >> See https://bz.apache.org/bugzilla/show_bug.cgi?id=59268 for the 
> >> full discussion,and https://github.com/pjfanning/xmlbeans for a 
> >> fork with initial bugfixes.
> >>
> >> Among others, we would like to fix the following, changes for these 
> >> are already applied and verified in the github fork:
> >> * the official XMLBeans-JAR contains duplicate classes, making it 
> >> impossible to use it on Android as the Android build fails due to 
> >> this
> >> * cannot use Unicode surogates, thus affecting use of Apache POI in 
> >> non-latin-script areas
> >> * Remove W3C and JAVAX classes which are not needed any more since 
> >> Java 6 (current Apache POI development is on Java 8)
> >>
> >>
> >> So is there a precedent for something like this? What steps do we 
> >> need to make to get an updated version of XMLBeans published?
> >
> > Others might have examples of how it was done in the past. Making a 
> > fork
> on e.g. github with a new non-apache name is the simplest way.
> >
> > However if I understand it correct your intention is only to 
> > maintain
> XMLbeans for the benefit of POI. That gives you (as I see it) another 
> option, you can include the source code in your project and do the 
> patches as part of your project.
> 
> I think it would need to be in a different package to avoid possible 
> confusion with the original.
> And it should be obvious that it is not intended for external use.
> 
> e.g. org.apache.poi.internal.xmlbeans
> 
> > rgds
> > jan i
> >>
> >>
> >> Thanks... Dominik
> >>
> >> On behalf of the Apache POI PMC
> >>
> >>
> >> About Apache POI
> >> ---
> >>
> >> Apache POI is well-known in the Java field as a library for reading 
> >> and writing Microsoft Office file formats, such as Excel, 
> >> PowerPoint, Word, Visio, Publisher and Outlook. It supports both 
> >> the older (OLE2) and new (OOXML - Office Open XML) formats.
> >>
> >> See https://poi.apache.org/ for more details
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional 
> commands, e-mail: dev-h...@poi.apache.org

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

RE: Apache POI 4.0/Java 8 - new packages?

[Murphy, Mark]

The thing that I see that most caused code duplication is that we read and 
process individual formats HSSF, XSSF, HWPF, XWPF, as is rather than having a 
reader that converts the format to POJOs, and a writer to convert the POJOs to 
the desired format. This causes the user code to be fairly tightly coupled to 
the format, and makes it hard to implement new formats. Note that we are still 
using the first edition OOXML spec because upgrading to the most recent edition 
is too disruptive.

-Original Message-
From: Allison, Timothy B. [mailto:talli...@mitre.org] 
Sent: Friday, September 15, 2017 9:04 AM
To: POI Developers List <dev@poi.apache.org>
Subject: RE: Apache POI 4.0/Java 8 - new packages?

Speaking of new packages...  It looks like there's some interest in moving 
Tika's mostly bean free/pure-SAX extractors for pptx/docx to POI.  What would 
people think of having an entirely bean-free ooxml extraction-only module; this 
could allow for a very lightweight module.  Downside is potential duplication 
of code, with current codebase, of course...

How would this play with: the newer XMLBeans version in 
https://github.com/pjfanning/xmlbeans/releases/tag/2.6.2 ?

-Original Message-
From: Murphy, Mark [mailto:murphym...@metalexmfg.com]
Sent: Friday, September 15, 2017 8:12 AM
To: 'POI Developers List' <dev@poi.apache.org>
Subject: RE: Apache POI 4.0/Java 8

Here is a somewhat radical idea, and maybe too hard to implement, but maybe we 
should package this a bit differently like poi-core, poi-ss, poi-wp, poi-misc. 
And then apply semantic versioning to each package separately so poi-core and 
poi-ss would be at 4.0.0 and poi-wp and poi-misc might still be at 0.4.0 as 
they are still experimental. I know that the binary formats are ahead of the 
xml formats in the wp world, so maybe this would still need to be thought out. 
I wouldn't want too many packages.

-Original Message-
From: Allison, Timothy B. [mailto:talli...@mitre.org]
Sent: Friday, September 15, 2017 7:07 AM
To: POI Developers List <dev@poi.apache.org>
Subject: RE: Apache POI 4.0/Java 8

Thank you, Dominik!!!

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

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

Hi,

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

Just FYI so we don't duplicate efforts here.

Dominik.
B CB  [  
X  ܚX KK[XZ[
 ] ][  X  ܚX P K \X K ܙ B  ܈Y][ۘ[  [X[  K[XZ[
 ] Z[ K \X K ܙ B B

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

[Murphy, Mark]

Here is a somewhat radical idea, and maybe too hard to implement, but maybe we 
should package this a bit differently like poi-core, poi-ss, poi-wp, poi-misc. 
And then apply semantic versioning to each package separately so poi-core and 
poi-ss would be at 4.0.0 and poi-wp and poi-misc might still be at 0.4.0 as 
they are still experimental. I know that the binary formats are ahead of the 
xml formats in the wp world, so maybe this would still need to be thought out. 
I wouldn't want too many packages.

-Original Message-
From: Allison, Timothy B. [mailto:talli...@mitre.org] 
Sent: Friday, September 15, 2017 7:07 AM
To: POI Developers List 
Subject: RE: Apache POI 4.0/Java 8

Thank you, Dominik!!!

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

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

Hi,

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

Just FYI so we don't duplicate efforts here.

Dominik.
B�CB��[��X��ܚX�KK[XZ[
�]�][��X��ܚX�P�K�\X�K�ܙ�B��܈Y][ۘ[��[X[��K[XZ[
�]�Z[�K�\X�K�ܙ�B�B

RE: Apache POI 4.0/Java 8

[Murphy, Mark]

I think that would be a good idea.

-Original Message-
From: Allison, Timothy B. [mailto:talli...@mitre.org] 
Sent: Friday, September 15, 2017 7:07 AM
To: POI Developers List 
Subject: RE: Apache POI 4.0/Java 8

Thank you, Dominik!!!

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

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

Hi,

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

Just FYI so we don't duplicate efforts here.

Dominik.
B�CB��[��X��ܚX�KK[XZ[
�]�][��X��ܚX�P�K�\X�K�ܙ�B��܈Y][ۘ[��[X[��K[XZ[
�]�Z[�K�\X�K�ܙ�B�B

RE: Developing POI with an IDE

[Murphy, Mark]

I'm using Eclipse, and really appreciate how easy it is to set up a new project.

-Original Message-
From: Dominik Stadler [mailto:dominik.stad...@gmx.at] 
Sent: Tuesday, June 20, 2017 3:27 PM
To: POI Developers List 
Subject: Re: Developing POI with an IDE

Previously Eclipse, nowadays IntelliJ here, although not in a shareable state.

Ideally we would use the Gradle build to generate the ide files (just open the 
gradle file as project) to not have to maintain separate configs, although not 
sure how far you get with that currently.

Dominik

On Jun 20, 2017 19:32, "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: Getting and setting cell value

[Murphy, Mark]

All Object getCellValue() does is change the location of the switch though 
right? User code still has to do it, either before the get, or after, and doing 
this with the setter vs. using overridden methods as we do right now seems to 
be a little anti-OO to me. I'm not real sure what annoying code would be 
avoided by using setCellValue(Object value), and the argument could be made 
that it is unnecessary code bloat as we already have setCellValue() for several 
object types. Maybe I don't understand what problem you are trying to solve.

-Original Message-
From: Greg Woolsey [mailto:greg.wool...@gmail.com] 
Sent: Friday, March 10, 2017 10:54 PM
To: POI Developers List 
Subject: Re: Getting and setting cell value

I especially would like the setter, to avoid annoying code, and the getter 
would be nice in many cases where the value type doesn't matter or is better 
handled further downstream.

On Fri, Mar 10, 2017, 19:04 Javen O'Neal  wrote:

> Would it be a good idea to add the following two methods to the cell 
> interface so that the switch(cell.getCellType()) code can be taken 
> care of in POI?
>
> interface org.apache.poi.ss.usermodel.Cell {
> Object getCellValue();
> void setCellValue(Object value);
> }
>
> We would have to decide how to handle formulas, but otherwise the code 
> is straightforward. I think this would go a long way to making the POI 
> API easier to use.
>
> Any objections?
>

RE: xlsb Streaming Reader?

[Murphy, Mark]

Are we trying to support OOXML schemas other than the 1st edition?

-Original Message-
From: Javen O'Neal [mailto:javenon...@gmail.com] 
Sent: Monday, March 06, 2017 12:24 PM
To: POI Developers List 
Subject: Re: xlsb Streaming Reader?

+1!

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

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

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

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

RE: [Bug 60741] NPOIFS move from read-only flag to 3-state enum

[Murphy, Mark]

+1

-Original Message-
From: bugzi...@apache.org [mailto:bugzi...@apache.org] 
Sent: Friday, February 17, 2017 12:43 PM
To: dev@poi.apache.org
Subject: [Bug 60741] NPOIFS move from read-only flag to 3-state enum

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

--- Comment #2 from Greg Woolsey  --- (In reply to Nick 
Burch from comment #1)
> Help needed with naming the enum and the enum values...

Perhaps

public enum WriteState {
READ_ONLY,
IN_PLACE,
BUFFERED,
;
}

with appropriate JavaDocs indicating restrictions, performance implications, 
and example use cases.  The Enum and API method JavaDocs would note that this 
only applies to paths that read from files, not streams.

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


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

RE: NPOIFS, files and the read-only flag

[Murphy, Mark]

I guess I don't understand this that well, so please bear with me. With a File 
loaded read-write how are changes stored such that writing to a different 
OutputStream is not feasible? I don't think they are written back to the 
original File until a write operation is performed. Or is that incorrect?

-Original Message-
From: Nick Burch [mailto:n...@apache.org] 
Sent: Friday, February 10, 2017 1:42 PM
To: POI Developers List 
Subject: NPOIFS, files and the read-only flag

Hi All

Currently, in NPOIFS (NPOIFSFileSystem + POIFSFileSystem, but not 
OPOIFSFileSystem), you can either load from a File or from a Stream. 
With a Stream, everything gets buffered into memory

When loading from a File, you can load read-write or read-only. In read-write 
mode, we use NIO to mmap the file so we can quickly + low memory read + write.

The other case, File + read-only, isn't so ideal. We need to support both 
people doing true read-only cases, eg reading or text extraction, plus people 
doing read-template + write or read-change-saveas cases. To support that, we 
buffer into memory.

Taking another look at the NIO stuff for bug #60670, I was wondering about 
splitting those two cases out. For true read-only cases, we could then mmap in 
read-only mode. For cases where you're loading a file and want to change + save 
elsewhere with the original unchanged, I think we could mmap in "private" mode, 
which looks to be copy-on-write, so only changes would be buffered in memory.

Any thoughts? Is it worth making the change? Can anyone spot any downsides to 
the change? Anyone think of any good enum names for the different modes if we 
replace the read-only boolean with a 3-way enum?

(Changing all file-based access to mmap, rather than a mix of mmap + in-memory 
buffers, should make it easier to tweak the logic to mmap bigger chunks)

Cheers
Nick

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


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

Saving modified Workbook in place

[Murphy, Mark]

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

So how can I update an existing spreadsheet without creating a secondary file? 
I am guessing that if I use an InputStream to open the initial file, I can 
write the updated workbook to an OutputStream without the original being 
updated?

RE: Using Apache Commons IO

[Murphy, Mark]

I believe that one of the reasons people get stuck on really old versions of 
POI is that inevitably there are breaking changes in nearly every release. So 
folks pick a version, and it remains the one they use. If we were to shift to a 
semantic versioning scheme where we only introduced breaking fixes for major 
releases, we would probably have a better upgrade record, and we could say 
something like "We only support the last two major releases. You are going to 
have to upgrade." As it is, we have had two releases in the last year that 
contained breaking fixes. It would take some discipline on our part to do that, 
and we could specify which API's were subject to the Semantic versioning rules. 
For example HSSF and XSSF, but not those API's that we deem are still subject 
to change (everything else). Once an API is ready to be called stable, it ould 
fall under the semantic versioning rules. I think this would help the user 
community, and even projects with dependencies to POI.

-Original Message-
From: Nick Burch [mailto:apa...@gagravarr.org] 
Sent: Tuesday, January 17, 2017 3:35 PM
To: POI Developers List 
Subject: Re: Using Apache Commons IO

On Tue, 17 Jan 2017, Javen O'Neal wrote:
> In the spirit of "the best code is no code", how would you feel about 
> replacing our endian classes and IOUtils with Apache Commons IO?
>
> The downside is that it adds a dependency.
> https://poi.apache.org/overview.html#components

How many classes do we need? Do those classes include all the methods we need, 
or are there gaps?

(Having dealt with yet another StackOverflow question today from someone stuck 
on a really old POI version, and knowing that the ones who make it to 
StackOverflow are actually the better ones, I'd rather inline a few classes / 
do nothing instead of adding a dependency that people can get
wrong)

Nick

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


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

RE: [Bug 60504] Add to public API POIXMLDocumentPart.removeRelation(POIXMLDocumentPart part)

[Murphy, Mark]

This is a great point Greg. Though drawings are part of the DrawingML spec, all 
documents currently handle it separately as we don't have a DrawingML package. 
We would probably benefit from having separate packages for shared components 
of the spec like DrawingML, and Charts.

-Original Message-
From: bugzi...@apache.org [mailto:bugzi...@apache.org] 
Sent: Wednesday, December 21, 2016 2:00 PM
To: dev@poi.apache.org
Subject: [Bug 60504] Add to public API 
POIXMLDocumentPart.removeRelation(POIXMLDocumentPart part)

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

Greg Woolsey  changed:

   What|Removed |Added

 OS||All

--- Comment #1 from Greg Woolsey  --- While we could 
make it public, that would also open the door to lots of ways to completely 
break a workbook.  I'd prefer to see a higher level API for replacing one image 
with another that would handle these details internally in a consistent manner, 
with lots of unit tests.

Patches are always welcome, as waiting for a volunteer to have the time and 
inclination to add a specific feature can take some time :)  Short of a patch, 
a robust discussion of what exactly an API improvement might look like, 
including test vectors, is still helpful.

For example, it may be that different document types need to handle image 
replacement differently.  I haven't dug in to how the different formats do it, 
but cell vs. slide vs. paragraph anchor references seem like one area that may 
be different.  Ideally there should be some consistency between document types 
for image replacement, and perhaps some checks as well if there are constraints 
or decisions needed when images differ in size, for example.

(In reply to Aurélien from comment #0)
> Currently the method 
> POIXMLDocumentPart.removeRelation(POIXMLDocumentPart
> part) is protected.
> Would it be possible to change the visibility of this method to public?
>

--
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: got docx?

[Murphy, Mark]

Lol, just from looking through the code, and standard, there are a number of 
things that I know are not handled or not handled properly in XWPF. A quick 
subset from the top of my head includes:
* Pictures that are not inlined in the main document, header, or footer parts.
* Sections
* SDT content
* Alternate content
* Many of the shared portions of the spec
* Tables have problems
* Versions - This is a tag that gets added to every node telling which save 
(version) it was created for.
* Revisions - This is the stuff that tells what was changed and how. Which 
nodes were inserted, or changed, or deleted, or moved, and when, and by whom.

There are thousands of hours left just to get it to version1 of the spec.

But yes, thanks Dominik for providing this batch of test documents. It should 
help prioritize fixes.

-Original Message-
From: Allison, Timothy B. [mailto:talli...@mitre.org] 
Sent: Monday, December 12, 2016 9:58 AM
To: POI Developers List 
Cc: d...@tika.apache.org
Subject: RE: got docx?

To close the loop and share my gratitude publicly...

Thank you, Dominik, for transferring 41k, 5GB of docx/dotx to our regression 
corpus!

I’ve already found a number of “areas for improvement” in Tika's experimental 
docx SAX parser, and a few areas for improvement in POI's XWPFDocument/DOM 
parser…all thanks to your documents and your common crawl code.  

Thank you!


Cheers,

Tim

B�CB��[��X��ܚX�KK[XZ[
�]�][��X��ܚX�P�K�\X�K�ܙ�B��܈Y][ۘ[��[X[��K[XZ[
�]�Z[�K�\X�K�ܙ�B�B

Interesting question on SO

[Murphy, Mark]

http://stackoverflow.com/questions/40723370/was-opensagres-allowed-to-use-apache-poi-like-packages

Does ASF defend its package names, or do we just ignore these kinds of things 
and folks use them at their own peril?

RE: Functionality injection technique for XWPF

[Murphy, Mark]

No, I did nothing to XMLBeans, or the generated schemas to make this happen.

-Original Message-
From: Dominik Stadler [mailto:dominik.stad...@gmx.at] 
Sent: Thursday, October 27, 2016 2:42 PM
To: POI Developers List <dev@poi.apache.org>
Subject: Re: Functionality injection technique for XWPF

Hi,

This looks very promising on the usages side, is there anything needed on the 
XmlBeans code-generation side?

Thanks... Dominik.

On Tue, Oct 25, 2016 at 10:48 PM, Mark Murphy <jmarkmur...@gmail.com> wrote:

> Check this commit out on github, I created a way to generically create 
> a paragraph in a common class and attach it to the delegator. This 
> should allow me to consolidate common code into a few classes for XWPF 
> without having to change our generated schema or resorting to reflection.
> https://github.com/JMarkMurphy/poi/commit/bf36bb08edb00d471b69bb70579a
> 96
> 2c22039bac
>
> On Tue, Oct 25, 2016 at 7:34 AM, Murphy, Mark 
> <murphym...@metalexmfg.com>
> wrote:
>
> > I have an even better solution now. It involves using the XmlBeans 
> > cursor to insert bits into the structure. I have a working prototype 
> > that I will post to GitHub tonight when I get home. This is very 
> > promising, particularly as it seems to be the way that issue #56854 
> > alludes to as being the best way to update the XML vs. Lists and 
> > Arrays. It also should provide a way to reorder XML which was the 
> > cause of an issue I came
> across
> > in XLSX earlier. An issue with shift rows leaving rows out of order 
> > in
> the
> > spreadsheet #59581 and #57423. The beauty of this solution is that 
> > we
> don't
> > have to monkey with the generated interfaces. XMLBeans gives us a 
> > way to accomplish our goal in a schema agnostic way.
> >
> > -Original Message-
> > From: Mark Murphy [mailto:jmarkmur...@gmail.com]
> > Sent: Saturday, October 22, 2016 6:37 PM
> > To: POI Developers List <dev@poi.apache.org>
> > Subject: Re: Functionality injection technique for XWPF
> >
> > I was looking at the WML schema, we could use the groups (EG_) to 
> > define interfaces. These are contained in other groups, and also in 
> > complex
> types
> > (CT_). We could use that to build an inheritance structure of 
> > interfaces where an EG_ contains another EG_, and also an interface 
> > structure for
> the
> > CT_ classes that contain EG_. There is only one EG_ that contains 
> > more
> than
> > one other EG_ which would break inheritance. The second EG_ is a 
> > grouping for math objects which could be dropped from the 
> > inheritance and created
> as
> > an independent interface which would be included for anything that 
> > implements the associated interface or its children.
> >
> > This would likely require another generator to be run after the 
> > XMLBeans compiler, and it would have to be able to process the 
> > generated XMLBeans sources as well as the schemas.
> >
> > On Sat, Oct 22, 2016 at 8:41 AM, Andreas Beeker 
> > <kiwiwi...@apache.org>
> > wrote:
> >
> > > > 3. Use XmlBeans to "Weave-in" some additional interfaces into 
> > > > the
> > CT_...
> > > > classes to handle this
> > > Most of the time, I thought about this, I didn't want constant 
> > > changes in the schema jar.
> > > But now we have a common type loader, and we could put a bit extra 
> > > magic
> > > in:
> > >
> > > Not sure if this works, but the POIXMLTypeLoader provides the 
> > > classloader to the xmlbeans schema type loader. We could extend 
> > > the xmlbeans implementation classes and inherit from a common interface.
> > > If the classloader determines there's a custom implementation 
> > > class, e.g. by some package/classname convention, it could 
> > > instantiate this instead of the original class. The problem is, 
> > > the original class has to be instantiated too, so I don't know how 
> > > that recursion would be handled sanely yet without checking the caller 
> > > stack ...
> > >
> > > If you think about how it would be done with Jaxb ... you probably 
> > > would add the interfaces to the generation config and create a new 
> > > schema jar. I think this should be not too difficult with xmlbeans 
> > > too ... (and we had already a discussion about that ... but I 
> > > can't find it :( )...
> > > So if you don't mind having more often updated schema jars, I 
> > > would prefer this way.
> > >
> > > Andi
> > >
> > > --
> > > --- To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For 
> > > additional commands, e-mail: dev-h...@poi.apache.org
> > >
> > >
> >
> > 
> > - To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For 
> > additional commands, e-mail: dev-h...@poi.apache.org
> >
> >
>

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

FW: POI-3.15: Commons-Collections-4 vs. Jasper Reports' dependency on Commons-Collections-3

[Murphy, Mark]

This should have gone to dev, but I was replying to a user thread, so I have 
moved it over to the dev list.

-Original Message-
From: Murphy, Mark [mailto:murphym...@metalexmfg.com] 
Sent: Wednesday, October 26, 2016 7:29 AM
To: 'POI Users List' <u...@poi.apache.org>
Subject: RE: POI-3.15: Commons-Collections-4 vs. Jasper Reports' dependency on 
Commons-Collections-3

This issue seems to have worked out well for Andreas, but I am wondering, if 
Jasper Reports depends on POI, can a user upgrade POI without breaking 
dependencies such as Jasper Reports? Can a user run with two versions of POI in 
their classpath? I don’t think so. While it is good to remove deprecations, I 
believe we need to do so in an orderly manner. I have brought this up before, 
but semantic versioning could help solve that problem by putting some rules 
around when breaking changes happen.

Semantic version numbers look something like POI 3.15.1 Major version is 3 – 
This changes when breaking changes or major functional changes are made Minor 
version is 15 – This changes when features are added, but no breaking changes 
are allowed Patch version is 1 – This changes for bug fixes that do not involve 
breaking changes

If we were to adopt semantic versioning, we could also put the major version in 
the namespace so that incompatible versions of POI could remain in the 
classpath together. It would also let us apply a bug fix to an older version 
while still developing a newer version. That improves stability of the project 
for everyone using it. Folks don’t have to refactor their code just to get bug 
fixes. On the other side, we would be able to deliver bug fixes to a branch 
other than the current production branch. As it stands now, users are stuck 
with upgrading to the latest-greatest, maybe breaking version if they want any 
bug fix. And we are quick on the draw at removing deprecated features.

A lot of projects are moving to semantic versioning for just these reasons. 
Maybe it is time for us to do so as well. Even tools like Maven provide a 
richer experience for packages that use semantic versioning by letting you 
specify a Major version, or Major and Minor version, and then retrieving the 
latest minor or patch version. With our current scheme of versioning, the user 
has to specify the specific version they want to use, and there are no patches 
forthcoming without the pain of breaking changes.

From: Andreas Reichel [mailto:andr...@manticore-projects.com]
Sent: Wednesday, October 26, 2016 5:13 AM
To: u...@poi.apache.org
Subject: Re: POI-3.15: Commons-Collections-4 vs. Jasper Reports' dependency on 
Commons-Collections-3


On Wed, 2016-10-26 at 01:40 -0700, Javen O'Neal wrote:
The Commons collection project has namespaced their library so that
collections3 and collections4 can run side by side.[1]

Javen, thank you a lot. This saved my day!
We put both libraries commons-collections-3.2.1.jar and 
commons-collections4-4.1.jar into the classpath and were able to build a Jasper 
Report, but also to export data into an Excel File.

Thank you again for kind support, cheers.

RE: Functionality injection technique for XWPF

[Murphy, Mark]

I have an even better solution now. It involves using the XmlBeans cursor to 
insert bits into the structure. I have a working prototype that I will post to 
GitHub tonight when I get home. This is very promising, particularly as it 
seems to be the way that issue #56854 alludes to as being the best way to 
update the XML vs. Lists and Arrays. It also should provide a way to reorder 
XML which was the cause of an issue I came across in XLSX earlier. An issue 
with shift rows leaving rows out of order in the spreadsheet #59581 and #57423. 
The beauty of this solution is that we don't have to monkey with the generated 
interfaces. XMLBeans gives us a way to accomplish our goal in a schema agnostic 
way.

-Original Message-
From: Mark Murphy [mailto:jmarkmur...@gmail.com] 
Sent: Saturday, October 22, 2016 6:37 PM
To: POI Developers List 
Subject: Re: Functionality injection technique for XWPF

I was looking at the WML schema, we could use the groups (EG_) to define 
interfaces. These are contained in other groups, and also in complex types 
(CT_). We could use that to build an inheritance structure of interfaces where 
an EG_ contains another EG_, and also an interface structure for the CT_ 
classes that contain EG_. There is only one EG_ that contains more than one 
other EG_ which would break inheritance. The second EG_ is a grouping for math 
objects which could be dropped from the inheritance and created as an 
independent interface which would be included for anything that implements the 
associated interface or its children.

This would likely require another generator to be run after the XMLBeans 
compiler, and it would have to be able to process the generated XMLBeans 
sources as well as the schemas.

On Sat, Oct 22, 2016 at 8:41 AM, Andreas Beeker 
wrote:

> > 3. Use XmlBeans to "Weave-in" some additional interfaces into the CT_...
> > classes to handle this
> Most of the time, I thought about this, I didn't want constant changes 
> in the schema jar.
> But now we have a common type loader, and we could put a bit extra 
> magic
> in:
>
> Not sure if this works, but the POIXMLTypeLoader provides the 
> classloader to the xmlbeans schema type loader. We could extend the 
> xmlbeans implementation classes and inherit from a common interface. 
> If the classloader determines there's a custom implementation class, 
> e.g. by some package/classname convention, it could instantiate this 
> instead of the original class. The problem is, the original class has 
> to be instantiated too, so I don't know how that recursion would be 
> handled sanely yet without checking the caller stack ...
>
> If you think about how it would be done with Jaxb ... you probably 
> would add the interfaces to the generation config and create a new 
> schema jar. I think this should be not too difficult with xmlbeans too 
> ... (and we had already a discussion about that ... but I can't find 
> it :( )...
> So if you don't mind having more often updated schema jars, I would 
> prefer this way.
>
> Andi
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional 
> commands, e-mail: dev-h...@poi.apache.org
>
>

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

RE: Functionality injection technique for XWPF

[Murphy, Mark]

Take a look at this commit, it shows what I am talking about. There is still a 
lot more to do, but I don't want to go too far down a path that will be 
incorrect. The classes XMLContent and XMLMarkup are delegates that provide 
common functionality to XWPFDocument, and XWPFHeaderFooter, XWPFTableCell, 
XWPFComment, XWPFFootnotes, etc. There is still a little overlap between 
XWPFDocument and XMLContent since I haven't fully added all the necessary parts 
to XMLContent yet, but eventually, the paragraphs, tables, and bodyElements 
properties in XWPFDocuments would be migrated fully to XMLContent, and the only 
methods implemented in XWPFDocument would be code that is specific to the 
Document part, for example Section code, though I think that might end up with 
its own class as well.

I have run this through the unit tests, and there are some bugs in it which I 
am in the process of correcting locally, but this gives a decent overview of 
what I am thinking of. Once this is complete, we would be able to fix bugs in 
paragraph, or Table code in a single location.

I still am unsure about what to do with the Exceptions that this throws. I 
think they should be handled as close to the source as possible, but what 
logging exists to handle this, and how would you notify the user that an issue 
exists.

Here is a link to the commit in my GitHub repository. 

https://github.com/apache/poi/commit/3bc9cf77fd690132257f9524ebc95db3ec7bde03

-Original Message-
From: Nick Burch [mailto:apa...@gagravarr.org] 
Sent: Monday, October 17, 2016 2:51 AM
To: POI Developers List 
Subject: Re: Functionality injection technique for XWPF

On Mon, 17 Oct 2016, Mark Murphy wrote:
> I found I should be able to do it using reflection to avoid long 
> strings of instanceof conditions which is really the same as 
> duplicating the code, but all inside one class. Any issue with using 
> Reflection?

If you post some of the code you're working on, with some ideas, we can 
hopefully all take a look and see if we can help improve things

Feel free to post to a github gist, a branch on your own github, a branch in 
svn, patch to jira etc!

(Quite a bit of XWPF has come from user contributions, so may well be missing 
some overall architecture improvements that piece-meal fixes didn't require)

Nick

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


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

RE: Build failed in Jenkins: POI-OpenJDK #235

[Murphy, Mark]

I've got this one. It is a license text issue. I can fix it when I get home 
from work.

-Original Message-
From: Apache Jenkins Server [mailto:jenk...@builds.apache.org] 
Sent: Thursday, October 13, 2016 9:09 AM
To: dev@poi.apache.org
Subject: Build failed in Jenkins: POI-OpenJDK #235

See 

Changes:

[jmarkmurphy] 53009: Problem creating header and footer 

Task-Url: https://bz.apache.org/bugzilla/show_bug.cgi?id=53009

--
[...truncated 4018 lines...]
  [javadoc] Loading source files for package org.apache.poi.hdgf.pointers...
  [javadoc] Loading source files for package org.apache.poi.hdgf.streams...
  [javadoc] Loading source files for package org.apache.poi.hmef...
  [javadoc] Loading source files for package org.apache.poi.hmef.attribute...
  [javadoc] Loading source files for package org.apache.poi.hmef.dev...
  [javadoc] Loading source files for package org.apache.poi.hmef.extractor...
  [javadoc] Loading source files for package org.apache.poi.hpbf...
  [javadoc] Loading source files for package org.apache.poi.hpbf.dev...
  [javadoc] Loading source files for package org.apache.poi.hpbf.extractor...
  [javadoc] Loading source files for package org.apache.poi.hpbf.model...
  [javadoc] Loading source files for package org.apache.poi.hpbf.model.qcbits...
  [javadoc] Loading source files for package org.apache.poi.hslf.blip...
  [javadoc] Loading source files for package org.apache.poi.hslf.dev...
  [javadoc] Loading source files for package org.apache.poi.hslf.exceptions...
  [javadoc] Loading source files for package org.apache.poi.hslf.extractor...
  [javadoc] Loading source files for package org.apache.poi.hslf.model...
  [javadoc] Loading source files for package 
org.apache.poi.hslf.model.textproperties...
  [javadoc] Loading source files for package org.apache.poi.hslf.record...
  [javadoc] Loading source files for package org.apache.poi.hslf.usermodel...
  [javadoc] Loading source files for package org.apache.poi.hslf.util...
  [javadoc] Loading source files for package org.apache.poi.hsmf...
  [javadoc] Loading source files for package org.apache.poi.hsmf.datatypes...
  [javadoc] Loading source files for package org.apache.poi.hsmf.dev...
  [javadoc] Loading source files for package org.apache.poi.hsmf.exceptions...
  [javadoc] Loading source files for package org.apache.poi.hsmf.extractor...
  [javadoc] Loading source files for package org.apache.poi.hsmf.parsers...
  [javadoc] Loading source files for package org.apache.poi.hssf.converter...
  [javadoc] Loading source files for package org.apache.poi.hwmf.draw...
  [javadoc] Loading source files for package org.apache.poi.hwmf.record...
  [javadoc] Loading source files for package org.apache.poi.hwmf.usermodel...
  [javadoc] Loading source files for package org.apache.poi.hwpf...
  [javadoc] Loading source files for package org.apache.poi.hwpf.converter...
  [javadoc] Loading source files for package org.apache.poi.hwpf.dev...
  [javadoc] Loading source files for package org.apache.poi.hwpf.extractor...
  [javadoc] Loading source files for package org.apache.poi.hwpf.model...
  [javadoc] Loading source files for package org.apache.poi.hwpf.model.io...
  [javadoc] Loading source files for package org.apache.poi.hwpf.model.types...
  [javadoc] Loading source files for package org.apache.poi.hwpf.sprm...
  [javadoc] Loading source files for package org.apache.poi.hwpf.usermodel...
  [javadoc] Loading source files for package 
org.apache.poi.openxml4j.exceptions...
  [javadoc] Loading source files for package org.apache.poi.openxml4j.opc...
  [javadoc] Loading source files for package 
org.apache.poi.openxml4j.opc.internal...
  [javadoc] Loading source files for package 
org.apache.poi.openxml4j.opc.internal.marshallers...
  [javadoc] Loading source files for package 
org.apache.poi.openxml4j.opc.internal.unmarshallers...
  [javadoc] Loading source files for package org.apache.poi.openxml4j.util...
  [javadoc] Loading source files for package org.apache.poi.poifs.crypt.agile...
  [javadoc] Loading source files for package org.apache.poi.poifs.crypt.dsig...
  [javadoc] Loading source files for package 
org.apache.poi.poifs.crypt.dsig.facets...
  [javadoc] Loading source files for package 
org.apache.poi.poifs.crypt.dsig.services...
  [javadoc] Loading source files for package org.apache.poi.xdgf.exceptions...
  [javadoc] Loading source files for package org.apache.poi.xdgf.extractor...
  [javadoc] Loading source files for package org.apache.poi.xdgf.geom...
  [javadoc] Loading source files for package org.apache.poi.xdgf.usermodel...
  [javadoc] Loading source files for package 
org.apache.poi.xdgf.usermodel.section...
  [javadoc] Loading source files for package 
org.apache.poi.xdgf.usermodel.section.geometry...
  [javadoc] Loading source files for package 
org.apache.poi.xdgf.usermodel.shape...
  [javadoc] Loading source files for package 

RE: DrawingML

[Murphy, Mark]

My reading of the specs tells me that there are three common "parts" handled by 
DrawingML. Those are Charts, Diagrams, and Themes. The only real difference 
between the three project areas (Spreadsheet, document, presentation) vs. 
DrawingML is the way the part in question is referenced in the package. This 
could be handled in the createChart, createDiagram, or createTheme methods the 
specific package.

-Original Message-
From: Nick Burch [mailto:apa...@gagravarr.org] 
Sent: Friday, July 08, 2016 8:09 AM
To: POI Developers List <dev@poi.apache.org>
Subject: Re: DrawingML

On Fri, 8 Jul 2016, Murphy, Mark wrote:
> Much of the Chart code and other things are common parts between 
> Spreadsheets, Documents, and Presentations. At least for the XML side 
> of things. I propose that the DrawingML portions of these three 
> projects be consolidated into a separate package or group of packages 
> to deal with things like charts and themes. If it is done correctly, 
> this code should be able to be shared among all areas of POI (XML 
> format anyway). I haven't checked into the older binary formats, but I 
> suspect that there could be a similar relationship.

For the binary formats, we have the "DDF" package which contains the common 
drawing records and classes. Sounds like we might be able to create a XDDF 
package for the common DrawingML drawing xml stuff too!

Nick


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


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

DrawingML

[Murphy, Mark]

Much of the Chart code and other things are common parts between Spreadsheets, 
Documents, and Presentations. At least for the XML side of things. I propose 
that the DrawingML portions of these three projects be consolidated into a 
separate package or group of packages to deal with things like charts and 
themes. If it is done correctly, this code should be able to be shared among 
all areas of POI (XML format anyway). I haven't checked into the older binary 
formats, but I suspect that there could be a similar relationship.

How do those of you who use Git produce patches

[Murphy, Mark]

I have a small change to xwpf that I am working on in a local Git repository, 
but I need to know how to create a patch. The documentation on the How to 
contribute page isn't particularly helpful.

RE: Strange behavior in XWPF

[Murphy, Mark]

Doesn't matter though since XWPF also doesn't handle templates properly.

-Original Message-
From: Murphy, Mark [mailto:murphym...@metalexmfg.com] 
Sent: Thursday, June 02, 2016 3:16 PM
To: 'POI Developers List'
Subject: RE: Strange behavior in XWPF

Read Only doesn't work in XWPF, it won't let me write to any file. Plenty of 
bugs to go around.

-Original Message-
From: Nick Burch [mailto:apa...@gagravarr.org]
Sent: Thursday, June 02, 2016 3:09 PM
To: POI Developers List
Subject: RE: Strange behavior in XWPF

On Thu, 2 Jun 2016, Murphy, Mark wrote:
> Does that not cause a memory leak in Closeable objects?

We need to fix the underlying bug really! For now, you can open the package 
Read Only to avoid it, or wait for GC to clear out the closable object a bit 
later

Nick

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


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


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

RE: Strange behavior in XWPF

[Murphy, Mark]

Read Only doesn't work in XWPF, it won't let me write to any file. Plenty of 
bugs to go around.

-Original Message-
From: Nick Burch [mailto:apa...@gagravarr.org] 
Sent: Thursday, June 02, 2016 3:09 PM
To: POI Developers List
Subject: RE: Strange behavior in XWPF

On Thu, 2 Jun 2016, Murphy, Mark wrote:
> Does that not cause a memory leak in Closeable objects?

We need to fix the underlying bug really! For now, you can open the package 
Read Only to avoid it, or wait for GC to clear out the closable object a bit 
later

Nick

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


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

RE: Strange behavior in XWPF

[Murphy, Mark]

Does that not cause a memory leak in Closeable objects?

-Original Message-
From: Nick Burch [mailto:apa...@gagravarr.org] 
Sent: Wednesday, June 01, 2016 6:04 PM
To: POI Developers List
Subject: Re: Strange behavior in XWPF

On Wed, 1 Jun 2016, Murphy, Mark wrote:
> Then write to a different file:
>
> FileOutputStream out = new FileOutputStream(new File(
>   "createdocument.docx"));
> document.write(out);
> out.close();
> document.close();

There's an issue with close and things opened from files with X??F, I'd suggest 
not doing that...

Nick

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


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

Strange behavior in XWPF

[Murphy, Mark]

If I open a document template:

XWPFDocument document = new 
XWPFDocument(POIXMLDocument.openPackage("Normal.dotm"));

Add some text:

XWPFParagraph paragraph = document.createParagraph();
XWPFRun run = paragraph.createRun();
run.setText("At tutorialspoint.com, we strive hard to "
+ "provide quality tutorials for self-learning "
+ "purpose in the domains of Academics, Information "
+ "Technology, Management and Computer Programming Languages.");

Then write to a different file:

FileOutputStream out = new FileOutputStream(new File(
"createdocument.docx"));
document.write(out);
out.close();
document.close();
System.out.println("createdocument.docx written successully");


The new file is created, but the template is updated as well!!

Any ideas of where to look?

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

RE: Musings on POI Architecture

[Murphy, Mark]

Do you use the stuff in the wp package, or was that simply experimentation?


-Original Message-
From: Javen O'Neal [mailto:javenon...@gmail.com] 
Sent: Wednesday, June 01, 2016 10:13 AM
To: POI Developers List
Subject: Re: Musings on POI Architecture

> create a branch and start experimenting! :)
Forking the Git mirror might be the easiest way to manage these contributions.
On Jun 1, 2016 06:35, "Nick Burch" <apa...@gagravarr.org> wrote:

> On Wed, 1 Jun 2016, Murphy, Mark wrote:
>
>> At work I have been using the SS side of POI, and have become fairly 
>> comfortable with it. I realize that there are some things still that 
>> need to be done, and some issues with XML Beans that have been 
>> discussed, but it seems fairly well organized. Recently I have also 
>> been working with the WP side as well, and it is obviously still a work in 
>> progress.
>>
>
> There's not a lot of link between HWPF and XWPF. I tried to put one 
> in, but the formats have a surprising number of differences in 
> concepts and approaches, more-so than HSSF/XSSF. Coupled with less 
> XWPF contributions, and HWPF needing lots of love after the loss of 
> the main developer, and that's how we end up in the situation today...
>
> I have found that XWPF does not yet have a clear separation between 
> the
>> model and the usermodel.
>>
>
> For anything done by POI committers, it should do. However, we've 
> taken a lot of community contributions, and many of those steer more 
> towards "get it done" than "build a full solution perfectly". That's 
> why you see a lot of "leakages" of the low-level XML stuff. It'd be 
> great to wrap all of that stuff up! And required for dropping xmlbeans 
> - we need to get everyone off the CT classes if we want to be able to 
> replace them
>
> I would like to propose a change to the POI architecture with respect 
> to
>> SS, as it already has a well-defined architecture. This change would 
>> allow us to more easily move away from XML Beans, and potentially 
>> reduce memory consumption in the XML format space. It seems to me 
>> that one of the reasons we use XML Beans is that it allows us to update XML 
>> documents in place.
>>
>
> On the whole, you can buy/beg/rent more memory, or faster machines. 
> The resource we really lack in POI is contributors writing code or 
> documentation or tests. xmlbeans makes development of the X??F stuff 
> quicker, and that's what we tend to optimise for!
>
> Unfortunately, XML is a highly inefficient format, and maybe it would 
> be
>> better, with respect to memory use, to model documents internally in 
>> a more efficient format, and at save time convert the document to its 
>> binary or XML format as necessary.
>>
>
> The binary and XML formats have more differences than you'd ideally 
> expect or like, which in part is why we don't have more shared stuff between 
> them.
> Not saying that this plan wouldn't work, just that it might not be as 
> clean as you'd like especially for more fiddly stuff like formatting, 
> colours or the like
>
> The WP side is a perfect place to try this out since it does not 
> really
>> have a well-defined separation between model and usermodel. If I go 
>> on any more, this thought will totally fall apart, so I will leave 
>> this open for discussion, and I hope that no one feels that I am 
>> stepping on toes. That is not my intention.
>>
>
> As long as it doesn't make new contributions to POI harder or slower 
> (we need more contributions!), and as long as you want to do the work, 
> create a branch and start experimenting! :)
>
> Nick
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional 
> commands, e-mail: dev-h...@poi.apache.org
>
>

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

RE: Musings on POI Architecture

[Murphy, Mark]

Is there a main developer for XWPF?

-Original Message-
From: Nick Burch [mailto:apa...@gagravarr.org] 
Sent: Wednesday, June 01, 2016 9:35 AM
To: POI Developers List
Subject: Re: Musings on POI Architecture

On Wed, 1 Jun 2016, Murphy, Mark wrote:
> At work I have been using the SS side of POI, and have become fairly 
> comfortable with it. I realize that there are some things still that 
> need to be done, and some issues with XML Beans that have been 
> discussed, but it seems fairly well organized. Recently I have also 
> been working with the WP side as well, and it is obviously still a 
> work in progress.

There's not a lot of link between HWPF and XWPF. I tried to put one in, but the 
formats have a surprising number of differences in concepts and approaches, 
more-so than HSSF/XSSF. Coupled with less XWPF contributions, and HWPF needing 
lots of love after the loss of the main developer, and that's how we end up in 
the situation today...

> I have found that XWPF does not yet have a clear separation between 
> the model and the usermodel.

For anything done by POI committers, it should do. However, we've taken a lot 
of community contributions, and many of those steer more towards "get it done" 
than "build a full solution perfectly". That's why you see a lot of "leakages" 
of the low-level XML stuff. It'd be great to wrap all of that stuff up! And 
required for dropping xmlbeans - we need to get everyone off the CT classes if 
we want to be able to replace them

> I would like to propose a change to the POI architecture with respect 
> to SS, as it already has a well-defined architecture. This change 
> would allow us to more easily move away from XML Beans, and 
> potentially reduce memory consumption in the XML format space. It 
> seems to me that one of the reasons we use XML Beans is that it allows 
> us to update XML documents in place.

On the whole, you can buy/beg/rent more memory, or faster machines. The 
resource we really lack in POI is contributors writing code or documentation or 
tests. xmlbeans makes development of the X??F stuff quicker, and that's what we 
tend to optimise for!

> Unfortunately, XML is a highly inefficient format, and maybe it would 
> be better, with respect to memory use, to model documents internally 
> in a more efficient format, and at save time convert the document to 
> its binary or XML format as necessary.

The binary and XML formats have more differences than you'd ideally expect or 
like, which in part is why we don't have more shared stuff between them. Not 
saying that this plan wouldn't work, just that it might not be as clean as 
you'd like especially for more fiddly stuff like formatting, colours or the like

> The WP side is a perfect place to try this out since it does not 
> really have a well-defined separation between model and usermodel. If 
> I go on any more, this thought will totally fall apart, so I will 
> leave this open for discussion, and I hope that no one feels that I am 
> stepping on toes. That is not my intention.

As long as it doesn't make new contributions to POI harder or slower (we need 
more contributions!), and as long as you want to do the work, create a branch 
and start experimenting! :)

Nick

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


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

Musings on POI Architecture

[Murphy, Mark]

I want to apologize in advance on this Stream of Consciousness post. I hope it 
makes sense to someone.

At work I have been using the SS side of POI, and have become fairly 
comfortable with it. I realize that there are some things still that need to be 
done, and some issues with XML Beans that have been discussed, but it seems 
fairly well organized. Recently I have also been working with the WP side as 
well, and it is obviously still a work in progress. Likely there are fewer 
developers contributing there. But as I sat here considering the best way to 
get the things done that I need, I thought about the need to have a common POI 
architecture between the pieces of the project. This may exist, I just haven't 
found it yet. I have found that XWPF does not yet have a clear separation 
between the model and the usermodel. For example, to build headers and footers, 
the user must drip into the model to get a key object that has not yet been 
exposed in the usermodel. And, significant parts still require use of CT and ST 
classes. This is likely due to the early level of development of the WP portion 
of POI, but I feel that this is a great place to start if we intend to replace 
XML Beans.

I would like to propose a change to the POI architecture with respect to SS, as 
it already has a well-defined architecture. This change would allow us to more 
easily move away from XML Beans, and potentially reduce memory consumption in 
the XML format space. It seems to me that one of the reasons we use XML Beans 
is that it allows us to update XML documents in place. Unfortunately, XML is a 
highly inefficient format, and maybe it would be better, with respect to memory 
use, to model documents internally in a more efficient format, and at save time 
convert the document to its binary or XML format as necessary. In this case, 
the model would be the internal representation of the document, and the 
usermodel would be the API we expose to users of the library. In this manner we 
could have a single model and user model for each document type: spreadsheet, 
word processor, diagram, etc. Then on write we would convert to the binary or 
XML format as requested. In addition to the potential memory savings, this 
would enable a few things: We could more easily support additional formats 
(such as .ods and .csv) because we would not have to manipulate those formats 
internally. We could move XML Beans or its replacement to the periphery making 
it easier to swap out that piece. We would not run into issues such as the one 
we currently have with the swapRows() method in XSSF where the file data is 
hard to sort because of the tight coupling with XML Beans.

The WP side is a perfect place to try this out since it does not really have a 
well-defined separation between model and usermodel. If I go on any more, this 
thought will totally fall apart, so I will leave this open for discussion, and 
I hope that no one feels that I am stepping on toes. That is not my intention.

Mark Murphy

RE: [Bug 59634] XSSFWorkbook#close() violates contract from Workbook#close()

[Murphy, Mark]

This seems a little counterintuitive to me. I would expect that once a Workbook 
is closed, it cannot be used. Closing should be the last thing you do with a 
Workbook. I would be more inclined to fix the documentation than to allow 
differing behavior between Workbooks read from the file system, and newly 
created workbooks.

-Original Message-
From: bugzi...@apache.org [mailto:bugzi...@apache.org] 
Sent: Thursday, May 26, 2016 2:41 AM
To: dev@poi.apache.org
Subject: [Bug 59634] XSSFWorkbook#close() violates contract from 
Workbook#close()

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

--- Comment #1 from Michael  --- In addition 
it's not possible to read from the workbook after it has been closed. A NPE 
will be thrown.

--
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: Beta time yet?

[Murphy, Mark]

If you have any questions or comments, I would love to hear your feedback. I am 
an experienced programmer (> 25 years) just not with Java. If I am doing 
something questionable, I would like to discuss it. That helps me learn new 
things. If there is something I could/should have done a different way, I would 
like to know what it is, and the reasoning for it.

-Original Message-
From: Javen O'Neal [mailto:javenon...@gmail.com] 
Sent: Thursday, March 31, 2016 12:12 PM
To: POI Developers List
Subject: RE: Beta time yet?

I've been slowly reviewing 58787. It's a larger patch, so takes a little more 
time to review. I'll try my best to squeeze it in, but no promises.
On Mar 31, 2016 04:01, "Murphy, Mark" <murphym...@metalexmfg.com> wrote:

> Can we get bug 58787 into the Beta?
>
> -Original Message-
> From: Nick Burch [mailto:n...@apache.org]
> Sent: Wednesday, March 30, 2016 5:50 PM
> To: POI Developers List
> Subject: RE: Beta time yet?
>
> On Wed, 30 Mar 2016, Allison, Timothy B. wrote:
> > I added a new report "mime_diffs_A_to_B_details.xlsx", which I'll 
> > send to you privately shortly.  I can share this if anyone wants it, 
> > and it will be included in all future report dumps.
>
> Checking a few from there, I think the detection as only ooxml is due to:
>
> java.lang.IllegalArgumentException: created  : Date not well formated 
> at
>
> org.apache.poi.openxml4j.opc.internal.PackagePropertiesPart.setCreated
> Property(PackagePropertiesPart.java:393)
>
> When I run with a POI nightly build + Tika CLI, they're back to being 
> detected as 
> application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
>
> Nick
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional 
> commands, e-mail: dev-h...@poi.apache.org
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional 
> commands, e-mail: dev-h...@poi.apache.org
>
>

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

RE: Beta time yet?

[Murphy, Mark]

Can we get bug 58787 into the Beta?

-Original Message-
From: Nick Burch [mailto:n...@apache.org] 
Sent: Wednesday, March 30, 2016 5:50 PM
To: POI Developers List
Subject: RE: Beta time yet?

On Wed, 30 Mar 2016, Allison, Timothy B. wrote:
> I added a new report "mime_diffs_A_to_B_details.xlsx", which I'll send 
> to you privately shortly.  I can share this if anyone wants it, and it 
> will be included in all future report dumps.

Checking a few from there, I think the detection as only ooxml is due to:

java.lang.IllegalArgumentException: created  : Date not well formated at
org.apache.poi.openxml4j.opc.internal.PackagePropertiesPart.setCreatedProperty(PackagePropertiesPart.java:393)

When I run with a POI nightly build + Tika CLI, they're back to being detected 
as application/vnd.openxmlformats-officedocument.spreadsheetml.sheet

Nick

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


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

Procedural question

[Murphy, Mark]

I have a patch out there (58633) that I created so that I could make a border 
drawing utility that would not be a performance hog. Now I am closing in on the 
border utility being complete, but 58633 is not yet checked in. I expect that I 
should make the new patch dependent on 58633, but when I create a diff, it will 
include the changes I made for 58633. Should I exclude those changes somehow, 
or not when creating a new patch in Bugzilla? Or should I include the new 
functionality in my existing bug (58633), I am thinking I should keep them 
separate, but not sure how to proceed.