Seems useful to do a 4.0.1 soon but I think we should wait a few weeks. There
have been a few issues reported and they continue to come in at reasonable
steady pace.
None of the issues so far seem to be blockers though.
--
Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html
I'm not sure why you need to load poi differently from xmlbeans. The xmlbeans
is correct but your poi dependencies are nothing like anything I've ever
seen.
Could you use the standard pom settings?
org.apache.poi
poi-ooxml
4.0.0
--
Sent from
Somehow you've disabled the standard transitive dependency loading mechanisms
in your maven build.
Try adding:
org.apache.poi
poi
4.0.0
But without transitive dependency loading, you're going to have to
explicitly add lots of dependencies
There were some bugs in the maven pom dependencies that we published.
We were missing commons-math3 dependency and some dependencies were listed
with old version numbers.
--
Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html
Should we do an XMLBeans 3.0.2 release?
https://issues.apache.org/jira/browse/XMLBEANS-520?jql=project%20%3D%20XMLBEANS%20AND%20fixVersion%20%3D%20%22Version%203.0.2%22
--
Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html
-
I have pushed xmlbeans 3.0.2 release candidate to:
https://repository.apache.org/content/repositories/staging/org/apache/xmlbeans/xmlbeans/3.0.2/
https://dist.apache.org/repos/dist/dev/poi/xmlbeans/
--
Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html
I would like to complete an xmlbeans 3.0.2 release this week.
Can I call a vote?
The changes are listed in
https://issues.apache.org/jira/browse/XMLBEANS-520?jql=project%20%3D%20XMLBEANS%20AND%20fixVersion%20%3D%20%22Version%203.0.2%22
Here's my +1.
--
Sent from: http://apache-poi.1045710.n5.n
I've been using the Oracle 8 JDK as my default for a while but thought that
for building XMLBeans it would be better to use an older JDK since we
support JDK 6 and above. JDK 6 is not easily installed on Macs so I thought
JDK 7 was a better bet.
--
Sent from: http://apache-poi.1045710.n5.nabble.
No external parties have reported bugs.
I did notify a few external projects about the release of 3.0.0 and some
upgraded to it.
If people have issues, there is enough documentation on the web that I would
expect them to be able to find the POI mailing list or the XMLBeans JIRA.
1 non-POI person
I've created a basic build job at
https://builds.apache.org/view/P/view/POI/job/POI-XMLBeans-DSL-1.6
I downloaded the zip/tgz/jar files from the build (built using JDK 1.6).
I replaced the artifacts in the staging repos:
https://repository.apache.org/content/repositories/staging/org/apache/xmlbe
Does anyone know how to delete the Jenkins job
https://builds.apache.org/job/XMLBeans-DSL-1.6/ ?
I created a new job called POI-XMLBeans-DSL-1.6 because it's easier to find
it if it's grouped with the other POI jobs.
https://builds.apache.org/view/P/view/POI/
--
Sent from: http://apache-poi.104
Thanks Andi
--
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
Could you try using DataFormatter after using the FormulaEvaluator?
https://stackoverflow.com/questions/21538481/xssf-how-to-get-anything-as-string/21550258#21550258
--
Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html
XMLBeans 3 has similar XML parser factory code to POI and with the reported
issues and fixes we've done for POI 4.0.1, I was hoping to release similar
fixes for XMLBeans 3.0.2.
Would it be feasible to get XMLBeans 3.0.2 reviewed?
--
Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f23
LGTM.
2 minor typos:
conjuction
uneccessary
--
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.apa
I've uploaded new artifacts with a couple of extra changes.
Still built using the apache jenkins jdk 1.6 build.
https://issues.apache.org/jira/issues/?jql=project%20%3D%20XMLBEANS%20AND%20fixVersion%20%3D%20%22Version%203.0.2%22
https://repository.apache.org/content/repositories/staging/org/apach
Thanks everyone. There have been 4 +1s (including me). I will proceed with
the release in the coming days if there are no objections.
--
Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html
-
To unsubscribe,
Is it time for us to look at doing a POI 4.0.1 release?
Are there any issues we would like to see completed before we proceed?
--
Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html
-
To unsubscribe, e-mai
The condition is `next != -1` but the value of next appears to -1 so that
this condition is false.
Maybe the condition should `next == -1`
--
Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html
-
To unsubs
I found a few missing classes in poi-ooxml-schemas.jar.
We have some gaps in the XDDF testing and this leads to us not adding all
the necessary OOXML classes for XDDF to the poi-ooxml-schemas.jar.
https://github.com/apache/poi/commit/df83dab1a49900d85d9a20c0ee6d5a7a31f0eb9c
--
Sent from: http:/
I'm +1 -- the fix can wait till 4.0.2 and there is the workaround to use full
schema jar.
--
Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html
-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For
Tim - would you be able to provide some sample files and we can add some
regression tests?
--
Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html
-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For
https://bz.apache.org/bugzilla/show_bug.cgi?id=62943 fix was to bring back a
try catch block around the code that had been removed in 4.0.0.
The 4.0.0 issue seems to affect users that have very old parsers - typically
part of Application Servers that have their own non-standard parsers.
I'm happy t
The real fix is https://bz.apache.org/bugzilla/show_bug.cgi?id=62692 -
XMLBeans-519 fixes a similar issue in XMLBeans (the SAXHelper code in
XMLBeans is basically a copy/paste of POI equivalent).
--
Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html
---
+1
Thanks for all the hard work getting this over the line.
--
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:
Thanks for your contributions.
Feel free to use Mockito in any of the submodules you need to use it in.
--
Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html
-
To unsubscribe, e-mail: dev-unsubscr...@poi.
For me, this kind of optimisation needs to be configurable. Most users would
not need this performance optimisation and would be better off to get the
full stack trace.
I would pitch that something like XmlOptions in the XMLBeans project is a
useful model. This allows users to choose to override t
The directoryEntry that is causing in the NullPointerException is set in the
HSSFWorkbook constructor.
Could you be passing a null into this constructor?
--
Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html
The META-INF/services files appear in xmlbeans-xpath-2.6.0.jar.
50 07-23-2012 15:42
META-INF/services/org.apache.xmlbeans.impl.store.PathDelegate.SelectPathInterface
52 07-23-2012 15:42
META-INF/services/org.apache.xmlbeans.impl.store.QueryDelegate.QueryInterface
Since that ja
We unit test our POI 4.0 code base with java 11.
if you are seeing issues, could you provide a lot more detail?
--
Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html
-
To unsubscribe, e-mail: dev-unsubscr
Thanks for the report. Could you raise an issue in
https://bz.apache.org/bugzilla/ ?
--
Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html
-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For addit
For reading large documents use
https://github.com/monitorjbl/excel-streaming-reader or
https://github.com/apache/poi/blob/trunk/src/examples/src/org/apache/poi/xssf/eventusermodel/XLSX2CSV.java
If you run into issues with shared strings table being too large, you might
also want https://github.co
Hi Andi,
I just added
https://issues.apache.org/jira/browse/XMLBEANS-526?jql=project%20%3D%20XMLBEANS%20AND%20fixVersion%20%3D%20%22Version%203.0.3%22
--
Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html
---
Should we release xmlbeans 3.0.3?
https://issues.apache.org/jira/browse/XMLBEANS-532?jql=project%20%3D%20XMLBEANS%20AND%20fixVersion%20%3D%20%22Version%203.0.3%22
--
Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html
---
Noone that I know of is actively working on a streaming API for docx or pptx.
Contributions to POI in these areas would be welcome.
One low level approach is to read docx/pptx files as zip files. If they are
password protected, you can use POI to first create a copy of the file with
the password p
The code that is failing is not POI code, it is from the java runtime.
It appears the test is trying to read a png file and convert it to a jpeg in
preparation for the POI part of the test.
Maybe we should just find a jpeg file for the test instead of doing this
conversion.
--
Sent from: http:
I've dropped the xmlbeans staging jars.
--
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.o
For xmlbeans, I would recommend getting the release jars and zips from
https://builds.apache.org/view/P/view/POI/job/POI-XMLBeans-DSL-1.6/lastSuccessfulBuild/artifact/build/
This guarantees the jars were built with Java 6.
For the nexus release, I follow this guide:
https://central.sonatype.org/p
Yes, to release the jars, you just need to run the release option in the
repository.apache.org UI.
I would suggest that we leave the jars in staging for a few days, just in
case someone spots any issues.
I've changed the POI build to use the xmlbeans 3.0.3 jars from staging and
the build seems fi
Calling the next release 3.1.0 seems sensible to me. +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
+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
What version are you upgrading from? That org.apache.poi.hpsf.Util class no
longer exists.
I went back nearly 2 years in code history and find no sign of such a class.
--
Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html
---
In the ant build, we can download different versions of bouncycastle into
different directories. The openpgp task can use the old bouncycastle jar and
the dsig can use the new one. Bouncycastle has lots of security fixes and it
seems bad to completely switch back to a very old version.
These were
Thanks Greg.
In my testing, I had to make a couple of small code changes to get things
working again but nothing big and this is an intermediate version upgrade so
that's expected.
+1
--
Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html
--
https://github.com/apache/poi/pull/143
The notifications for github PRs seem not to happen any more.
I don't know a lot about the H**F foramts. Would someone be able to review
github-143?
--
Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html
-
I'm not very familiar with the OLE specification that POIFS implements.
Right now, we have the size parameter implemented as an int which means that
we are limited to a file size of approx 2G.
I had a look at changing the int to a long but this has a knock-on effect
for lots of classes.
Is there a
We've already released some JDK 6 friendly XMLBeans releases.
With https://issues.apache.org/jira/projects/XMLBEANS/issues/XMLBEANS-541
and just to make life easier for future development, could we move to just
building with Java 8 (and newer versions)?
Here's my +1 for the change.
--
Sent fro
We have 4 +1s.
I will proceed with the build changes over the coming days. Ping me if there
are any objections.
--
Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html
-
To unsubscribe, e-mail: dev-unsubscr
My personal opinion is that I'd prefer not to add this to the POI core. It is
quite possible to have a community where people have side projects that use
the core code. The core POI code is already very large and we only have a
small number of volunteers to maintain it.
If we were to add this code
I didn't want to complicate the last release but I discovered that POI
signing does not work with the latest xmlsec jar.
(https://bz.apache.org/bugzilla/show_bug.cgi?id=63712)
This signing code base is not something I am very familiar with - but it
would be nice not to stuck on the old jar.
--
That class is generated from a schema.
It is a big task to regenerate those classes based on a newer version of the
schema - and fix issues and uptake extra features - so we only do this
upgrade every few years.
http://www.ecma-international.org/publications/standards/Ecma-376.htm
--
Sent fro
OPCPackage.open(file) is more efficient memory wise than
OPCPackage.open(inputStream)
/**
* Open a package.
*
* Note - uses quite a bit more memory than {@link #open(String)}, which
* doesn't need to hold the whole zip file in memory, and can take
advant
I see a similar test issue when I build on my laptop
--
View this message in context:
http://apache-poi.1045710.n5.nabble.com/Build-failed-in-Jenkins-POI-DSL-1-6-367-tp5727976p5727978.html
Sent from the POI - Dev mailing list archive at Nabble.com.
-
I favour more regular non-beta releases generally and like the idea of a 4.0
release.
I'm pretty neutral on the JRE version support. My employers mandate JRE 1.8
usage and I think, for security reasons, this is the right approach.
My 2 cents is that we could continue to support a 3.x branch and bac
Hi,
The new test, TestFonts, is failing on my laptop.
https://svn.apache.org/viewvc?view=revision&revision=1801329
I have a Mac and the font size seems to be 399 instead of the 312 expected
in the test.
java.lang.AssertionError: expected:<399.0> but was:<312.0>
at org.junit.Assert.fail(As
I'm temporarily commented out the assertion that was failing.
https://svn.apache.org/viewvc?view=revision&revision=1801395
--
View this message in context:
http://apache-poi.1045710.n5.nabble.com/TestFonts-failing-on-my-laptop-tp5728134p5728135.html
Sent from the POI - Dev mailing list archive
I thought that the writeAttribute made the code a bit easier to read.
Also, concatenating strings before writing them to the Writer does add
overhead.
I did some similar work (with others) on a similar writer implementation in
February and removing the string concats and using additional write call
Would it be feasible to keep the existing classes and APIs and have them
delegate to the XDDF impl?
We could immediately deprecate any of these legacy APIs.
--
View this message in context:
http://apache-poi.1045710.n5.nabble.com/XDDF-implementation-shared-between-XSSFChart-and-XSLFChart-tp5728
Thanks Avinash. Would you be able to create a sample or samples using Kotlin?
Apache POI does support quite a lot of Microsoft document formats but maybe
xlsx is a good place to start. The XSSF API for reading and/or writing xlsx
files might be a good one to demonstrate.
Feel free to suggest someth
+1 to a 3.17 final release
--
View this message in context:
http://apache-poi.1045710.n5.nabble.com/3-17-beta2-vs-3-17-final-tp5728538p5728543.html
Sent from the POI - Dev mailing list archive at Nabble.com.
-
To unsubscribe,
My votes are:
a) 4.0
b) JDK8 (if Tika team agrees to upgrade)
c) yes
d) semver
--
View this message in context:
http://apache-poi.1045710.n5.nabble.com/Discussions-on-POI-4-0-Java7-8-voting-tp5728560p5728566.html
Sent from the POI - Dev mailing list archive at Nabble.com.
---
+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
I agree with Andi about using 4.0.0-SNAPSHOT as the release number.
I'd like to make regular 4.0.x releases and to have 4.y release on a similar
cadence to the existing 3.z releases (2 or so a year).
--
Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html
---
We could just call it 3.18.
--
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
I'm happy to work on e) if we do need committers.
My view is that we can move away from xmlbeans over time but that it is
useful to maintain it in the interim.
I don't know if we've formed an opinion on whether to continue with the
research into using JAXB but my gut feeling is that we will proba
Thanks for the reminder, Javen. I've now updated status.xml.
--
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:
I just added some code that iterates code points. It looks like there will be
a lot of other code that needs to be modified but this is just an initial
toe in the water.
--
Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html
-
I switched this code to use Locale.ROOT for now.
The current POI code base uses this in more places than the
LocaleUtil.getUserLocale().
--
Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html
-
To unsubscri
https://support.office.com/en-us/article/Excel-specifications-and-limits-1672b34d-7043-467e-8e27-269d656771c3#ID0EBABAAA=2016,_2013
- 32,767 is the limit in Excel.
To support LibreOffice as a special case and apply different limits is
feasible but non-trivial.
Could you raise a bugzilla issue to t
If you're stuck, you could subclass SXSSFCell in your application and have
the logic in your subclass skip the cell size check.
--
Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html
-
To unsubscribe, e-mai
I use IntelliJ and it handles the poi repo well, in my experience.
I allow IntelliJ to use the gradle build and use a Zulu 8 JDK as the SDK.
--
Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html
-
To unsub
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.
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.
If the major objection to the com.github.pjfanning:xmlbeans dependency is
that my name is in the groupId, I can request a new groupId from OSS
Sonatype. They require that y
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
anyth
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&revision=1822253
where c
I could make h2 a `provided` dependency in our poi-ooxml pom.
The use of h2 is opt-in in the new code in my PR but I'll need to refactor
the code to allow our code not to throw ClassNotFoundException if the h2
classes are not on the runtime classpath. This is do-able but my concern is
that this is
Is it ok to delete this and just have Eclipse users create the Eclipse
workspace using `gradle eclipse`?
Just makes for fewer places where we need to manage the jar version numbers.
--
Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html
-
Hi,
I don't know much about the gump tests. They are failing due to the mockito
code. The gump environment seems to be set up with a CLASSPATH environment
variable and this doesn't include mockito or its dependencies (byte-buddy
and objenesis).
Can anyone give me pointers?
http://vmgump-vm3.apache
+1 to remove jump tests
--
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
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
-
Who would be in a position to follow up with Apache Foundation (or XMLBeans
PMC) about taking XMLBeans out of the attic?
Nick summarised the requirements, as follows:
* Vote to take it on
* Wait for attic PMC to confirm
* Get infra to unlock svn for xmlbeans
* Merge in fixes
* Test,
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
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.
http://mail-archives.apache.org/mod_mbox/attic-general/201802.mbox/%3C1519744891.257410.1285160920.6801732D%40webmail.messagingengine.com%3E
Looks like we're not going to make much progress on resurrecting Apache
XMLBeans.
I've already put the modified xmlbeans code in poi svn.
Can we just use th
1. For users whose only dependency on xmlbeans is from poi then, we can
choose to override the dependency to point to any maven artifact we like:
http://central.maven.org/maven2/org/apache/poi/poi-ooxml-schemas/3.17/poi-ooxml-schemas-3.17.pom
2. For users, who use xmlbeans but not poi, they can ch
+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
Could we consider keeping all the jars but ensure that no package spans jars?
--
Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html
-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional c
I had a quick look at it looks like we'd have to move a lot of classes to new
packages.
Maybe, the poi-all jar is the path of least resistance.
--
Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html
-
To un
http://mail-archives.apache.org/mod_mbox/attic-general/201803.mbox/browser
I think we could spend a lot of time on the attic approach.
--
Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html
-
To unsubscri
One potential approach would be to use commons-compress zip support instead
of the built-in java support. This might help us work around the fact that
the core java implementation can change in ways that cause us issues.
With commons-compress, it might even be best for us to see if they'll take
the
I'm also wondering if maybe we could abandon the reflection approach and just
have ThresholdInputStream wrap the entry's InputStream and count the bytes
that are read, and blow up when the thresholds are breeched. We might lose
out on some cases but the code would be easier to maintain.
--
Sent
Thanks Dave. I think it would be good to get the XMLBeans JIRA project
reopened if and when we get the XMLBeans project into the Apache Incubator.
Some of the issues we want to fix are already tracked as XMLBeans JIRAs.
--
Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html
My attempt at a short description of why we want to be able to patch
xmlbeans.
Apache Poi has a significant dependency on XmlBeans. There would need to be
a lot of work done to switch to an alternative (and this might happen at a
later date). We have identified a few issues in XmlBeans that we wou
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 t
+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
Anyone know who to contact about https://github.com/apache/poi being out of
sync with svn?
--
Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html
-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For
ssary features directly.
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile)
on project fr.opensagres.poi.xwpf.converter.core: Compilation failure:
Compilation failure:
[ERROR]
/Users/pj.fanning/code/xdocreport/thirdparties-exte
The current trunk is intended for a 4.0.0 release. We have significant
changes in there, including making Java 8 the lowest supported runtime.
If we want to release 3.18, we would need to branch from 3.17 release point
and cherry pick the most useful bug fixes.
4.0.0 is awaiting a few things before
+1 4.0.0 is a good place to make changes like this - otherwise, we'd need to
make them in a 5.0.0 release later.
--
Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html
-
To unsubscribe, e-mail: dev-unsubscr
I would suggest converting the xlsx sheets to CSV and importing into Spark
using its built-in CSV data source.
--
Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html
-
To unsubscribe, e-mail: dev-unsubscr..
1 - 100 of 154 matches
Mail list logo