XDDF implementation shared between XSSFChart and XSLFChart

[Alain FAGOT BÉAREZ]

Dear all,

Since June, this is the third pull request I open about the same theme.

After the first review, mentioning a conversation I had missed 
(https://lists.apache.org/thread.html/ff5470bc413d298188f8c5d3d250ee15d36bd655227696869ed21aab@%3Cdev.poi.apache.org%3E),
 I reworked my initial submission to refactor my code into some sharable XDDF 
package for the common DrawingML subset about charts.

After I had opened the second pull request, I wanted to solve some personal 
situation which my initial XDDF implementation did not allow me to get done, 
not even with ugly code. So I decided to go for some more steps, learning from 
the XSSF charts implementation, and migrating the existing XSSF charts and 
tests to use the new XDDF code, which evolved a lot.

This is why we now have pull request #68 (https://github.com/apache/poi/pull/68 
) and pull requests #61 and #67 have 
been closed.

Personally, I was scratching my own itch which was bug #57835 
(https://bz.apache.org/bugzilla/show_bug.cgi?id=57835), at least the Charts 
part of the bug report. Maybe the Notes part could be solved following some 
strategy similar to what I implemented for Charts. It did not enter my scope 
yet. Anyway, it would be worth its own pull request, since this one is already 
touching 97 files…

I hope this contribution does not fall in the middle of some important release 
preparation.

Best regards,
Alain

Re: XDDF implementation shared between XSSFChart and XSLFChart

[Alain FAGOT BÉAREZ]

Hi,

@pjfanning: In the current state, delegating to the XDDF from the legacy SS and 
XSSF implementation would not be feasible. Some constants were defined in Enum 
types and I don’t know how to “redirect” an Enum value to the new 
implementation of it.

@Greg: I don’t know how deep your code goes throughout the CT* side. For the 
user model, I tried to put as much as possible of the common code in the 
abstract XDDFChartData, XDDFChartData.Series and XDDFChartAxis, with concrete 
implementations in the subclasses. If you could point me to some repository 
where I could take a look at your current uses of chart related CT* internals, 
I could focus on preparing a user model API for these uses.

@Andi: I did not put any @Removal on the @Deprecated elements. Maybe all the 
classes in the XDDF package should be marked as @Beta as well.

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

Re: XDDF implementation shared between XSSFChart and XSLFChart

[Alain FAGOT BÉAREZ]

Hi,

@Greg: It was Brazilian Father’s Day today, so that I did not pick up tech 
lists from bed… but only after my daughter was sleeping.

I cloned and searched through the following code base:
https://github.com/WoozyG/spreadsheet/tree/ConditionalFormatting

There I found no single reference to any `usermodel.charts.*` classes that I am 
deprecating. This is good news for POI. Bad news for Vaadin people is that they 
rely on some `@Internal` method that is leaking underlying `CTChart` element. 
My feeling is that the public `getCTChart` method had been introduced due to 
some flaws in the original design of the `ss.usermodel.charts` API. I removed 
the need for it, from POI side. 

The rest of the Vaadin code that depends on XSSFChart requires access to both 
`@Internal public CTChart getCTChart()` and `@Internal public CTChartSpace 
getCTChartSpace()` due to the lack of `usermodel` API to wrap these concepts. 
Searching through Google, I also found similar dependencies on the same methods 
on XSLFChart in some open source projects. This may be work for a distinct 
branch later on, until we could deprecate these two methods.

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

Re: svn commit: r1816500 [1/23] - in /poi/site: publish/apidocs/ publish/apidocs/org/apache/poi/class-use/ publish/apidocs/org/apache/poi/common/usermodel/fonts/ publish/apidocs/org/apache/poi/common/

[Alain FAGOT BÉAREZ]

Hi,

I was using that one:
:poi abearez$ java -version
java version "1.8.0_131"
Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)

Could it be considered as compatible enough if I use this one:
:poi abearez$ java -version
openjdk version "1.8.0_152"
OpenJDK Runtime Environment (Zulu 8.25.0.1-macosx) (build 1.8.0_152-b16)
OpenJDK 64-Bit Server VM (Zulu 8.25.0.1-macosx) (build 25.152-b16, mixed mode)


Best regards,
Alain FAGOT BÉAREZ

> On 27 Nov 2017, at 21:26, Nick Burch <apa...@gagravarr.org> wrote:
> 
> On Mon, 27 Nov 2017, abea...@apache.org wrote:
>> URL: http://svn.apache.org/viewvc?rev=1816500=rev
>> Log:
>> update status and javadocs for closed github-68
> 
> What jdk did you use to generate the javadocs? Generally we try to use 
> (oldest POI supported + openjdk), so currently openjdk 8. Everyone using the 
> same one tends to stop javadoc changing everything for no good reason, then 
> creating huge diffs!
> 
> Nick
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
> For additional commands, e-mail: dev-h...@poi.apache.org

Re: Review #62355

[Alain FAGOT BÉAREZ]

Hi,

If it is breaking, then it already is `4.0.0`. If you need to release before 
the load of other breaking changes, then they will be `5.0.0`.

Alain

⁣Gesendet mit BlueMail ​


 Originale Nachricht 
Von: Andreas Beeker 
Gesendet: Sun May 13 12:37:56 GMT-03:00 2018
An: POI Developers List 
Betreff: Review #62355

Hi,

I'd like to apply the patches in #62355 before 4.0.0, but this contains 
breaking changes especially for the POIXML* classes, i.e. their package moved.

At least for this, I'd like to have a thumbs up/down.

Andi

Re: XMLBeans 3.0.0 votes

[Alain FAGOT BÉAREZ]

A. +1
B. 1.6
C. -0

⁣Gesendet mit BlueMail ​


 Originale Nachricht 
Von: "pj.fanning" 
Gesendet: Thu Jun 14 05:51:22 GMT-03:00 2018
An: dev@poi.apache.org
Betreff: 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

Re: poi .classpath file

[Alain FAGOT BÉAREZ]

In other projects, it is recommended NOT to version control IDE configurations.

For this reason, I use the Git global ignore configuration in order not to 
accidentally commit my changes.

+1



 Originale Nachricht 
Von: "pj.fanning" 
Gesendet: Fri Jan 26 09:49:08 GMT-03:00 2018
An: dev@poi.apache.org
Betreff: poi .classpath file

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

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

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

[Alain FAGOT BÉAREZ]

You might have heard of Hypersonic SQL, some 10 years ago. H2 is the second 
version thereof.

⁣Gesendet mit BlueMail ​


 Originale Nachricht 
Von: Greg Woolsey 
Gesendet: Fri Jan 26 16:42:44 GMT-03:00 2018
An: POI Developers List 
Betreff: Re: ***UNCHECKED*** RE: adding dependencies on h2 and mockito

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

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

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

> I could make h2 a `provided` dependency in our poi-ooxml pom.
> The use of h2 is opt-in in the new code in my PR but I'll need to refactor
> the code to allow our code not to throw ClassNotFoundException if the h2
> classes are not on the runtime classpath. This is do-able but my concern is
> that this is difficult to automate tests for (checking the code works when
> the h2 jar is available and when it is not).
>
> https://mvnrepository.com/artifact/com.h2database/h2 is very common
> dependency, so my preference would be to have the explicit dependency from
> poi-ooxml on h2 - but I'll go with whatever the consensus is.
>
>
>
> --
> Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
> For additional commands, e-mail: dev-h...@poi.apache.org
>
>

Re: Failing gump tests

[Alain FAGOT BÉAREZ]

+1 to leave the Gump biosphere

⁣Gesendet mit BlueMail ​


 Originale Nachricht 
Von: "pj.fanning" 
Gesendet: Sun Feb 04 13:24:07 GMT-03:00 2018
An: dev@poi.apache.org
Betreff: Re: Failing gump tests

+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

Re: Timeline for 4.0.0 release

[Alain FAGOT BÉAREZ]

Hi all,

There is one branch that I would like to finish before release 4.0.0 since it 
would make the implementation of XDDF more sound. But as these are on the @Beta 
side, I can understand it is no blocker.

https://github.com/cuali/poi/branches

Best regards,
Alain FAGOT BÉAREZ 

⁣


 Originale Nachricht 
Von: "pj.fanning" <fannin...@yahoo.com>
Gesendet: Mon Feb 12 16:09:51 GMT-03:00 2018
An: dev@poi.apache.org
Betreff: 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

Re: baffling save behavior

[Alain FAGOT BÉAREZ]

Hi,

It might have been the same symptoms which have led Sandeep Tiwari to make a 
code change that I was reluctant to accept in the branch about charts in XWPF. 
His explanations were in the line of yours. But I couldn't not accept the idea 
that such a fundamental feature had been broken.

I hope to have some time this weekend to dive into the commits history to point 
out any change done recently that might affect that.

Best regards,
Alain FAGOT BÉAREZ

⁣

Von: Greg Woolsey
Gesendet: Fri Feb 23 03:53:08 GMT-03:00 2018
An: POI Developers List
Betreff: baffling save behavior

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

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

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

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

Anyone know how I could have done that?

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

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

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

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

Greg


 Originale Nachricht 
Von: Greg Woolsey <greg.wool...@gmail.com>
Gesendet: Fri Feb 23 03:53:08 GMT-03:00 2018
An: POI Developers List <dev@poi.apache.org>
Betreff: baffling save behavior

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

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

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

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

Anyone know how I could have done that?

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

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

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

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

Greg

rebased GitHub pull request #72

[Alain FAGOT BÉAREZ]

Hi,

I rebased the xddf-shape-properties branch on the latest trunk, making a more 
linear history for it and improved the code, as well as provided an example to 
use the new shape properties to change the color of a bar chart series.

https://github.com/apache/poi/pull/72 <https://github.com/apache/poi/pull/72> 
is ready for code review.

Best regards,
Alain FAGOT BÉAREZ

Re: Remove OPOIFSFileSystem for 4.0.0?

[Alain FAGOT BÉAREZ]

+1 for removal before 4.0.0

⁣Gesendet mit BlueMail ​


 Originale Nachricht 
Von: "pj.fanning" 
Gesendet: Mon Aug 13 17:54:14 GMT-03:00 2018
An: dev@poi.apache.org
Betreff: Re: Remove OPOIFSFileSystem for 4.0.0?

+1 for 4.0.0 change



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

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

RE: Upgrade OOXML schema to 3rd edition?

[Alain FAGOT BÉAREZ]

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

package org.apache.poi.xddf.usermodel.text implementing most of drawingml.CTText*

[Alain FAGOT BÉAREZ]

Hi all,

PR#109 is now ready for code review and later merging into trunk.
https://github.com/apache/poi/pull/109 <https://github.com/apache/poi/pull/109>

I would have liked to change the title of it, but since it already exists I 
have no rights on the PR, not even to open a new one for the same branch.

My current implementation exists as an alternative implementation to the 
partial and redundant implementations in XSLF and XSSF. At a later stage, we 
would need to make XSLFTextParagraph and XSSFTextParagraph extend from 
XDDFTextParagraph (as well as XSLFTextRun and XSSFTextRun from XDDFTextRun) in 
order to reduce the duplicated code in both existing local implementations of 
that part of DrawingML.

I will probably not reach the same replacement as was done with XDDFChart, but 
the ideal is very similar.

Best regards,
Alain FAGOT BÉAREZ

PS: I did execute the retest-ooxml target, but is it enough to make sure all 
required CT* and ST* classes are in ooxml-lite?

Re: Copying chart

[Alain FAGOT BÉAREZ]

Hi FD,

Did you base your patch on 3.17 sources or on current GitHub mirror?

Cloning a Chart in XSLF was not only a matter of cloning some XML hierarchy. 
Some magic was involved at the relationships level. Maybe with the introduction 
of the XDDF package some parts of the magic have been made available.

I must confess I had the same motivation as yourself, but with Charts in 
slides. However I didn't have time and a project to explore the best way to do 
it also for Charts in XSSF and XWPF.

Your code is welcome! Even better if you could open a pull request on 
https://github.com/apache/poi as it is easier for us to review and bring it to 
our machines and run local tests.

Thanks for your collaboration!

Best regards,
Alain FAGOT BÉAREZ



⁣Gesendet mit BlueMail ​


 Originale Nachricht 
Von: "monnomiznog...@gmail.com" 
Gesendet: Thu Aug 23 18:29:09 GMT-03:00 2018
An: dev@poi.apache.org
Betreff: Copying chart

Guys,

You cannot ask even from advanced developers to create a chart from scratch 
with java code or any other code type.

Copying a chart from an existing model Excel file is needed in any real life 
reporting project.

I've tinkered with the code and found a simple way to do it. I just needed 
access to 2 private variables in XSSFChart class.

If I paste the test code could you implement the copy chart method somewhere in 
the library ?

Re
FD

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

Re: Remove OPOIFSFileSystem for 4.0.0?

[Alain FAGOT BÉAREZ]

+1 for full refactoring to POIFS*

⁣Gesendet mit BlueMail ​


 Originale Nachricht 
Von: Andreas Beeker 
Gesendet: Sun Aug 26 19:06:02 GMT-03:00 2018
An: dev@poi.apache.org
Betreff: Re: Remove OPOIFSFileSystem for 4.0.0?

After OPOIFS* is now removed, should I rename/normalize/refactor NPOIFS* to 
POIFS*?

Andi

Re: [VOTE] Apache XMLBeans 3.0.1 release (RC1)

[Alain FAGOT BÉAREZ]

+1 for release

⁣Gesendet mit BlueMail ​


 Originale Nachricht 
Von: "pj.fanning" 
Gesendet: Mon Aug 20 07:12:54 GMT-03:00 2018
An: dev@poi.apache.org
Betreff: Re: [VOTE] Apache XMLBeans 3.0.1 release (RC1)

I've updated the staged artifacts for xmlbeans 3.0.1.

https://repository.apache.org/content/repositories/staging/org/apache/xmlbeans/xmlbeans/3.0.1/
and https://dist.apache.org/repos/dist/dev/poi/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

Re: Remove Spanish translation?

[Alain FAGOT BÉAREZ]

+1 for removal of unmaintained docs

⁣Gesendet mit BlueMail ​


 Originale Nachricht 
Von: "pj.fanning" 
Gesendet: Sun Jul 15 13:38:20 GMT-03:00 2018
An: dev@poi.apache.org
Betreff: Re: Remove Spanish translation?

+1 for removal of unmaintained docs



--
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: Copying chart

[Alain FAGOT BÉAREZ]

Hi FD,

The code has been merged by r1840076. It might appear in release 4.0.0 or 4.0.1 
(we are currently busy with 4.0.0 RC1).

Best regards,
Alain

> On 4 Sep 2018, at 00:27, Alain FAGOT BÉAREZ  wrote:
> 
> Hi FD,
> 
> I think all you need is the following method on XSSFDrawing:
> 
> ```
>/**
> * Imports the chart from the srcChart into this drawing.
> *
> * @param srcChart
> *the source chart to be cloned into this drawing.
> * @return the newly created chart.
> * @throws XmlException
> * @throws IOException
> */
>public XSSFChart importChart(XSSFChart srcChart) throws IOException, 
> XmlException {
>CTTwoCellAnchor anchor = ((XSSFDrawing) 
> srcChart.getParent()).getCTDrawing().getTwoCellAnchorArray(0);
>CTMarker from = (CTMarker) anchor.getFrom().copy();
>CTMarker to = (CTMarker) anchor.getTo().copy();
>XSSFClientAnchor destAnchor = new XSSFClientAnchor(from, to);
>destAnchor.setAnchorType(AnchorType.MOVE_AND_RESIZE);
>XSSFChart destChart = createChart(destAnchor);
>destChart.getCTChartSpace().set(srcChart.getCTChartSpace().copy());
>destChart.getCTChart().set(srcChart.getCTChart().copy());
>return destChart;
>}
> ```
> 
> I feel that retrieving the source chart and creating the new destination 
> drawing are better handled outside.
> 
> I will open a PR for code review.
> 
> Best regards,
> Alain
> 
> 
>> On 24 Aug 2018, at 10:50, monnomiznog...@gmail.com wrote:
>> 
>> Hi Alain,
>> 
>> I'll paste some test code here. In my work we have a lot of restrictions 
>> when it comes to websites.
>> 
>> Sorry I don't know how to format this code.
>> 
>> Important: the chartModel.xlsx should contain a chart, preferably with no 
>> relations. After all you need the model to be copied to your report but then 
>> you must at least implement the data source for the chart, maybe also the 
>> title, the series names, etc. But the heavy customization of the chart is 
>> already done in the model.
>> 
>>   //Open chart model file
>>  //My use experience: one chart par xlsx model file, in one sheet. Could 
>> be otherwise of course.
>>  FileInputStream in = new FileInputStream("c:/temp/chartModel.xlsx");
>>   XSSFWorkbook srcWB = new XSSFWorkbook(in);
>>   XSSFWorkbook destWB = new XSSFWorkbook();
>>   XSSFSheet destSH = destWB.createSheet();
>>   XSSFDrawing destDR = destSH.createDrawingPatriarch();
>>   int sheetNum = 0; 
>>   XSSFSheet srcSH = srcWB.getSheetAt(sheetNum);
>> 
>>   List srcRels = 
>> srcSH.createDrawingPatriarch().getRelations();
>>   for (POIXMLDocumentPart srcRel : srcRels)
>>   {
>> if (srcRel instanceof XSSFChart)
>> {
>>   XSSFChart srcChart = (XSSFChart) srcRel;
>>  
>>  //Create chartSpace and chart by parsing source chart
>>  CTChartSpace chartSpace = 
>> ChartSpaceDocument.Factory.parse(srcChart.getPackagePart().getInputStream(), 
>> POIXMLTypeLoader.DEFAULT_XML_OPTIONS).getChartSpace(); 
>>  CTChart ctc = chartSpace.getChart();
>> 
>>   //XSSFClientAnchor origAnch = chart.getGraphicFrame().getAnchor();
>>  //Frame is null ! I tried to get anchor using the following:
>>   CTMarker from = ((XSSFDrawing) 
>> srcChart.getParent()).getCTDrawing().getTwoCellAnchorArray(0).getFrom();
>>   CTMarker to = ((XSSFDrawing) 
>> srcChart.getParent()).getCTDrawing().getTwoCellAnchorArray(0).getTo();
>>   XSSFClientAnchor anchor = new XSSFClientAnchor((int) from.getColOff(), 
>> (int) from.getRowOff(), (int) to.getColOff(), (int) to.getRowOff(), 
>> from.getCol(), from.getRow(), to.getCol(), to.getRow());
>>   anchor.setAnchorType(AnchorType.MOVE_AND_RESIZE);
>>  //Create chart in the destination workbook
>>   XSSFChart destChart = destDR.createChart(anchor);
>>  
>>  //A new XSSFChart constructor is needed maybe. The following 2 
>> lines use reflection in order to force values for these 2 private variables 
>> of XSSFChart
>>   Utilities.setVariable(destChart, "chartSpace", chartSpace, true);
>>   Utilities.setVariable(destChart, "chart", ctc, true);
>>}
>>  }
>>  
>>  //Write the new workbook (could also be one you already have opened for 
>> edition)
>>   FileOutputStream out = new FileOutputStream("c:/temp/test.xlsx");
>>   destWB.write(out);
>>   out.flush();
>>   out.close();
>>   in.close();
>>   srcWB.close();
>>   destWB.close();
>>  
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
>> For additional commands, e-mail: dev-h...@poi.apache.org
> 

Re: Provide alpha releases via Apache repo

[Alain FAGOT BÉAREZ]

> On 7 Sep 2018, at 19:04, Nick Burch  wrote:
> 
> On Fri, 7 Sep 2018, Dave Fisher wrote:
>> Alternatively are we using GitBox so that the repos is on GitHub? If so then 
>> they can fork on GitHub to test.
> 
> We don't use the read/write gitbox, but we do have a github mirror, and IIRC 
> some docs on the website about forking it there, opening pull requests etc

This was also the way I started to contribute, first testing my changes against 
my pet project by local publishing Maven artifacts to my .m2 for a first try.

However, there had been a steep step until I managed to gather all necessary 
info and… the will to solve an issue that was already several years on BugZilla.

i don’t remember clearly how all this started… But clearly we could have a 
one-stop page with enough details about how to clone from the mirror and run a 
local install for fast experimentation of newest features.

My ¢2,
Alain FAGOT BÉAREZ


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

Re: Provide alpha releases via Apache repo

[Alain FAGOT BÉAREZ]

One issue is only about a better documentation: the one about the need to 
provide commons-math3 to use some specific functions for spreadsheet. #62690

The other ones, well… Snapshots might be an opportunity.


> On 7 Sep 2018, at 16:25, pj.fanning  wrote:
> 
> I would like to see our CI build publish regular snapshots to Apache Nexus.
> 
> 
> 
> --
> 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: [VOTE] new POI logo

[Alain FAGOT BÉAREZ]

V2 / C0 / POLL: 0


> On 7 Sep 2018, at 21:57, Andreas Beeker  wrote:
> 
> Hi *,
> 
> Daniel (humbedooh) created a new logo for us and I don't want this issue left 
> undecided/unanswered.
> 
> So please vote for the logos and its properties:
> 
> V0) keep current version:
> https://svn.apache.org/repos/asf/poi/site/src/documentation/resources/images/project-header.svg
> V1) use Daniels first version:
> https://www.apache.org/logos/comdev-test/res/poi/poi-proposed.svg
> V2) use Daniels second version:
> http://www.apache.org/logos/comdev-test/res/poi/poi-proposed2.svg
> V3) suggest a different style - your favorite apache project logo?
> 
> C0) keep the gradient "POI" label
> C1) use the black "POI" label
> C2) suggest a different coloring style (foreground / background / frame / 
> font ...)
> 
> POLL) although we probably have more important things to do,
> we could have another logo contest
> 
> In the meantime I've really got used to the (modified) old style, therefore I 
> vote:   V0 / C0 / POLL: 0
> 
> (... but a small poll with my better half seems to be balanced ... :| )
> 
> If you want some inspiration, you can look through the other project logos at
> https://svn.apache.org/repos/asf/comdev/project-logos/originals
> 
> Thank you,
> 
> Andi
> 


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

Re: Use forrest 0.9?

[Alain FAGOT BÉAREZ]

+1

⁣Gesendet mit BlueMail ​


 Originale Nachricht 
Von: Andreas Beeker 
Gesendet: Sat Jul 07 13:32:47 MESZ 2018
An: POI Developers List 
Betreff: Use forrest 0.9?

Hi *,

I'll soon commit the xmlbeans site, which I've upgraded to forrest 0.9 and used 
the default white color theme, which matches better with the logos.

Does anyone mind if I also try to upgrade POIs site to forrest 0.9?

I would go also with the default white color theme and need to check for 
compatibility issues with POIs current theme.

Andi

Re: starting poi 4.0.0 release process?

[Alain FAGOT BÉAREZ]

There are quite a few annoying failures reported by the regression tests 
published a few days ago.

I understand they are in the @Beta classes of XSLF but yet I don't feel 
comfortable with their release as is.

Alain FAGOT BÉAREZ


⁣Gesendet mit BlueMail ​


 Originale Nachricht 
Von: Andreas Beeker 
Gesendet: Mon Jul 09 16:45:15 MESZ 2018
An: dev@poi.apache.org
Betreff: Re: starting poi 4.0.0 release process?

I'm fine with starting the release soon, as I'm working on the EMF processing 
for the next release after 4.0.0 and won't push any H/XSLF related changes in.
The only thing which might be worth fixing is #59287. But in regards to 
semantic versioning, this might be not an API break when fixed and so can be 
introduced a bit later.

Andi

Re: publishing poi xmlbeans jars

[Alain FAGOT BÉAREZ]

Yet another dead code generator, used in Apache ODF kit, is MSV.

It seems like code generation from XSD schemas has not much to be changed 
anymore
⁣


 Originale Nachricht 
Von: Mark Murphy 
Gesendet: Thu Mar 15 14:01:51 GMT-03:00 2018
An: POI Developers List 
Betreff: Re: publishing poi xmlbeans jars

forget JiBX, it looks deader than XMLBeans


On Thu, Mar 15, 2018 at 9:46 AM, Mark Murphy  wrote:

> Anyone look at JiBX? it is released under the 3-clause BSD license.
> http://jibx.sourceforge.net/jibx-license.html. It contains some code that
> is uder the Apache 1.1 license which should be ok, and some code under XPP3
> which is not listed by Apache, but appears to be based on the BSD license.
>
> Concerning XPP3, clause 3 may be problematic because it is not directly in
> the BSD 3 clause. This third clause is not the advertising clause found in
> the BCD 4 clause, but it is similar as it applies to documentation, so that
> could be a problem. Maybe legal should look at it and give a ruling.
> Finally, XPP3 clauses 4 and 5 appear to my non-legal eyes to be the same
> and equivalent to the BSD clause 3.
>
> On Fri, Mar 9, 2018 at 4:54 PM, Andreas Beeker 
> wrote:
>
>> There's a workaround for the GPL problem:
>> https://issues.apache.org/jira/browse/LEGAL-264
>>
>> ... but my last experiments with the current ECMA schemas weren't so
>> successful:
>> https://stackoverflow.com/questions/46869482/
>>
>>
>> On 3/9/18 2:05 PM, Murphy, Mark wrote:
>> > 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.
>>
>>
>>
>

Re: publishing poi xmlbeans jars

[Alain FAGOT BÉAREZ]

+1

Je 2018-03-07 14:40, Dave Fisher skribis:

Hi -

Let’s get back on track.

We want to release XMLBeans 2.7.0 with the org.apache.xmlbeans
namespace for the benefit of all of the users who are dependent on it.
If POI does not want to do this then XMLBeans will need to go to the
Incubator.

Should we VOTE?

If yes then we can ask Infra to open the JIRA and move the svn
somewhere with the history. We also ask for the return of the website
to our LDAP.

Regards,
Dave

On Mar 7, 2018, at 4:04 AM, Murphy, Mark  
wrote:


If we do that, it needs to be in a major release because namespaces 
change. If we are going to repackage to support Java 9 modules, that 
should also happen at the same time.


-Original Message-
From: pj.fanning [mailto:fannin...@yahoo.com]
Sent: Tuesday, March 06, 2018 4:35 PM
To: dev@poi.apache.org
Subject: Re: publishing poi xmlbeans jars

I have an experimental xmlbeans jar where I changed the package name 
to org.apache.poi.xmlbeans just to see if it was feasible to get it 
build. I also have a poi branch that successfully uses this jar.

https://repo1.maven.org/maven2/com/github/pjfanning/xmlbeans/2.7.0-beta1/
It should be feasible to use a commons based package name if that was 
the route we went.




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


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



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



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

Re: xdocreport dependency on full ooxml-schemas jar

[Alain FAGOT BÉAREZ]

Hi,

About your first point, I will copy and paste a frequent answer from BugZilla. 
Thanks Nick for your clean response template on this matter. 

As per http://poi.apache.org/faq.html#faq-N10025 each missing CT* class 
requires to write a short JUnit unit test that uses this class, so the build 
can know to include it in the future.

About your second point, it is a fact that the spreadsheet support is far more 
developed than support for the other formats.

Best regards,
Alain FAGOT BÉAREZ

⁣


 Originale Nachricht 
Von: "pj.fanning" <fannin...@yahoo.com>
Gesendet: Wed Apr 04 18:51:24 GMT-03:00 2018
An: dev@poi.apache.org
Betreff: xdocreport dependency on full ooxml-schemas jar

https://github.com/opensagres/xdocreport depends on the full ooxml-schemas
jar as opposed to the poi-ooxml-schemas.jar. I was under the impression that
the latter jar contained the ooxml-schema classes that we expect to suffice
in most cases.
xdocreport won't compile with just poi-ooxml-schemas. Is it possible that we
are missing a few classes in poi-ooxml-schemas.jar that we should add?
I have pasted the errors from my test build below.

A 2nd topic is that this project depends very heavily on the generated CT
classes - presumably because the XWPF code base does not expose the
necessary 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-extension/fr.opensagres.poi.xwpf.converter.core/src/main/java/fr/opensagres/poi/xwpf/converter/core/styles/table/cell/AbstractTableCellValueProvider.java:[30,62]
cannot find symbol
[ERROR] symbol:   class CTTblStylePr
[ERROR] location: package
org.openxmlformats.schemas.wordprocessingml.x2006.main
[ERROR]
/Users/pj.fanning/code/xdocreport/thirdparties-extension/fr.opensagres.poi.xwpf.converter.core/src/main/java/fr/opensagres/poi/xwpf/converter/core/styles/table/cell/AbstractTableCellValueProvider.java:[56,28]
cannot find symbol
[ERROR] symbol:   class CTTblStylePr
[ERROR] location: class
fr.opensagres.poi.xwpf.converter.core.styles.table.cell.AbstractTableCellValueProvider
[ERROR]
/Users/pj.fanning/code/xdocreport/thirdparties-extension/fr.opensagres.poi.xwpf.converter.core/src/main/java/fr/opensagres/poi/xwpf/converter/core/styles/XWPFStylesDocument.java:[54,62]
cannot find symbol
[ERROR] symbol:   class CTFont
[ERROR] location: package
org.openxmlformats.schemas.wordprocessingml.x2006.main
[ERROR]
/Users/pj.fanning/code/xdocreport/thirdparties-extension/fr.opensagres.poi.xwpf.converter.core/src/main/java/fr/opensagres/poi/xwpf/converter/core/styles/XWPFStylesDocument.java:[73,62]
cannot find symbol
[ERROR] symbol:   class CTTextDirection
[ERROR] location: package
org.openxmlformats.schemas.wordprocessingml.x2006.main
[ERROR]
/Users/pj.fanning/code/xdocreport/thirdparties-extension/fr.opensagres.poi.xwpf.converter.core/src/main/java/fr/opensagres/poi/xwpf/converter/core/styles/XWPFStylesDocument.java:[75,62]
cannot find symbol
[ERROR] symbol:   class CTTwipsMeasure
[ERROR] location: package
org.openxmlformats.schemas.wordprocessingml.x2006.main
[ERROR]
/Users/pj.fanning/code/xdocreport/thirdparties-extension/fr.opensagres.poi.xwpf.converter.core/src/main/java/fr/opensagres/poi/xwpf/converter/core/styles/XWPFStylesDocument.java:[76,62]
cannot find symbol
[ERROR] symbol:   class FontsDocument
[ERROR] location: package
org.openxmlformats.schemas.wordprocessingml.x2006.main
[ERROR]
/Users/pj.fanning/code/xdocreport/thirdparties-extension/fr.opensagres.poi.xwpf.converter.core/src/main/java/fr/opensagres/poi/xwpf/converter/core/styles/table/cell/AbstractTableCellValueProvider.java:[79,45]
cannot find symbol
[ERROR] symbol:   class CTTblStylePr
[ERROR] location: class
fr.opensagres.poi.xwpf.converter.core.styles.table.cell.AbstractTableCellValueProvider
[ERROR]
/Users/pj.fanning/code/xdocreport/thirdparties-extension/fr.opensagres.poi.xwpf.converter.core/src/main/java/fr/opensagres/poi/xwpf/converter/core/styles/AbstractValueProvider.java:[213,123]
package
org.openxmlformats.schemas.wordprocessingml.x2006.main.STTblStyleOverrideType
does not exist
[ERROR]
/Users/pj.fanning/code/xdocreport/thirdparties-extension/fr.opensagres.poi.xwpf.converter.core/src/main/java/fr/opensagres/poi/xwpf/converter/core/styles/AbstractValueProvider.java:[364,107]
package
org.openxmlformats.schemas.wordprocessingml.x2006.main.STTblStyleOverrideType
does not exist
[ERROR]
/Users/pj.fanning/code/xdocreport/thirdparties-extension/fr.opensagres.poi.xwpf.converter.core/src/main/java/fr/opensagres/poi/xwpf/converter/core/styles/AbstractValueProvider.java:[372,120]
package
org.openxmlformats.schemas.wordprocessingml.x2006.main.STTblStyleOverrideType
does not exist
[ERROR]
/Users/pj.fanning/code/xdocreport/thirdparties-extension/fr.opensagres.poi.xwpf.converter.core/src/main/ja

Re: Fwd: Challenge on automatic generation of documentation

[Alain FAGOT BÉAREZ]

+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: xmlbeans 3.0.2 release?

[Alain FAGOT BÉAREZ]

+1

Je 2018-09-26 19:54, Javen O'Neal skribis:

+1

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


Should we do an XMLBeans 3.0.2 release?


https://issues.apache.org/jira/browse/XMLBEANS-520?jql=project%20%3D%20XMLBEANS%20AND%20fixVersion%20%3D%20%22Version%203.0.2%22



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


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




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

Re: POI 4.0.1 release

[Alain FAGOT BÉAREZ]

+1 to release 4.0.1

The blocking issues related to charts in XDDF are now fixed. Related Bugzilla 
issue has also been resolved.

Some tricks from StackOverflow tickets have been integrated into the code base 
and in the examples. Some Bugzilla issues were resolved as side effect.

Remaining chart related issues in Bugzilla will require either some 
investigation (shifting rows and columns in XSSF) or brand new implementation 
(chart extensions like TreeMap and SunBurst). The easiest one is more about 
gathering examples from various SO tickets and building a new example, rather 
than improvement of the API for charts.

⁣Gesendet mit BlueMail ​

Von: "pj.fanning"
Gesendet: Tue Oct 30 04:59:08 GMT-03:00 2018
An: dev@poi.apache.org
Betreff: POI 4.0.1 release

Is it time for us to look at doing a POI 4.0.1 release?

Are there any issues we would like to see completed before we proceed?



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


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


 Originale Nachricht 
Von: "pj.fanning" 
Gesendet: Tue Oct 30 04:59:08 GMT-03:00 2018
An: dev@poi.apache.org
Betreff: POI 4.0.1 release

Is it time for us to look at doing a POI 4.0.1 release?

Are there any issues we would like to see completed before we proceed?



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

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

Re: [VOTE] xmlbeans 3.0.2 release [rc2]

[Alain FAGOT BÉAREZ]

+1

Je 2018-10-23 18:13, pj.fanning skribis:

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


-
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: [VOTE] xmlbeans 3.0.2 release

[Alain FAGOT BÉAREZ]

As long as the resulting bytecode targets JVM 1.6 bytecode, it should not 
matter which JDK is used for compilation. I don't remember exactly where in the 
`build.gradle` the `jvmTarget: "1.6"` has to be defined, but it would be pretty 
much all...

⁣Gesendet mit BlueMail ​


 Originale Nachricht 
Von: "pj.fanning" 
Gesendet: Sun Sep 30 17:21:43 GMT-03:00 2018
An: dev@poi.apache.org
Betreff: Re: [VOTE] xmlbeans 3.0.2 release

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.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: poi-ooxml-schemas missing some inner classes

[Alain FAGOT BÉAREZ]

Hi,

By this patch, you fixed also bug 
https://bz.apache.org/bugzilla/show_bug.cgi?id=62259 which you can accordingly 
close.

Best regards,
Alain


On 2018/07/11 23:39:45, "pj.fanning"  wrote: 
> I checked in some artificial tests that load some of the ooxml-schemas> 
> classes that are missing.> 
> I was able to get the ooxml build and tests to work locally after> 
> regenerating poi-ooxml-schemas with the extra classes.> 
> 
> 
> 
> --> 
> 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: Copying chart

[Alain FAGOT BÉAREZ]

Hi FD,

I think all you need is the following method on XSSFDrawing:

```
/**
 * Imports the chart from the srcChart into this drawing.
 *
 * @param srcChart
 *the source chart to be cloned into this drawing.
 * @return the newly created chart.
 * @throws XmlException
 * @throws IOException
 */
public XSSFChart importChart(XSSFChart srcChart) throws IOException, 
XmlException {
CTTwoCellAnchor anchor = ((XSSFDrawing) 
srcChart.getParent()).getCTDrawing().getTwoCellAnchorArray(0);
CTMarker from = (CTMarker) anchor.getFrom().copy();
CTMarker to = (CTMarker) anchor.getTo().copy();
XSSFClientAnchor destAnchor = new XSSFClientAnchor(from, to);
destAnchor.setAnchorType(AnchorType.MOVE_AND_RESIZE);
XSSFChart destChart = createChart(destAnchor);
destChart.getCTChartSpace().set(srcChart.getCTChartSpace().copy());
destChart.getCTChart().set(srcChart.getCTChart().copy());
return destChart;
}
```

I feel that retrieving the source chart and creating the new destination 
drawing are better handled outside.

I will open a PR for code review.

Best regards,
Alain


> On 24 Aug 2018, at 10:50, monnomiznog...@gmail.com wrote:
> 
> Hi Alain,
> 
> I'll paste some test code here. In my work we have a lot of restrictions when 
> it comes to websites.
> 
> Sorry I don't know how to format this code.
> 
> Important: the chartModel.xlsx should contain a chart, preferably with no 
> relations. After all you need the model to be copied to your report but then 
> you must at least implement the data source for the chart, maybe also the 
> title, the series names, etc. But the heavy customization of the chart is 
> already done in the model.
> 
>//Open chart model file
>   //My use experience: one chart par xlsx model file, in one sheet. Could 
> be otherwise of course.
>   FileInputStream in = new FileInputStream("c:/temp/chartModel.xlsx");
>XSSFWorkbook srcWB = new XSSFWorkbook(in);
>XSSFWorkbook destWB = new XSSFWorkbook();
>XSSFSheet destSH = destWB.createSheet();
>XSSFDrawing destDR = destSH.createDrawingPatriarch();
>int sheetNum = 0; 
>XSSFSheet srcSH = srcWB.getSheetAt(sheetNum);
> 
>List srcRels = 
> srcSH.createDrawingPatriarch().getRelations();
>for (POIXMLDocumentPart srcRel : srcRels)
>{
>  if (srcRel instanceof XSSFChart)
>  {
>XSSFChart srcChart = (XSSFChart) srcRel;
>   
>   //Create chartSpace and chart by parsing source chart
>   CTChartSpace chartSpace = 
> ChartSpaceDocument.Factory.parse(srcChart.getPackagePart().getInputStream(), 
> POIXMLTypeLoader.DEFAULT_XML_OPTIONS).getChartSpace(); 
>   CTChart ctc = chartSpace.getChart();
> 
>//XSSFClientAnchor origAnch = chart.getGraphicFrame().getAnchor();
>   //Frame is null ! I tried to get anchor using the following:
>CTMarker from = ((XSSFDrawing) 
> srcChart.getParent()).getCTDrawing().getTwoCellAnchorArray(0).getFrom();
>CTMarker to = ((XSSFDrawing) 
> srcChart.getParent()).getCTDrawing().getTwoCellAnchorArray(0).getTo();
>XSSFClientAnchor anchor = new XSSFClientAnchor((int) from.getColOff(), 
> (int) from.getRowOff(), (int) to.getColOff(), (int) to.getRowOff(), 
> from.getCol(), from.getRow(), to.getCol(), to.getRow());
>anchor.setAnchorType(AnchorType.MOVE_AND_RESIZE);
>   //Create chart in the destination workbook
>XSSFChart destChart = destDR.createChart(anchor);
>   
>   //A new XSSFChart constructor is needed maybe. The following 2 
> lines use reflection in order to force values for these 2 private variables 
> of XSSFChart
>Utilities.setVariable(destChart, "chartSpace", chartSpace, true);
>Utilities.setVariable(destChart, "chart", ctc, true);
> }
>   }
>   
>   //Write the new workbook (could also be one you already have opened for 
> edition)
>FileOutputStream out = new FileOutputStream("c:/temp/test.xlsx");
>destWB.write(out);
>out.flush();
>out.close();
>in.close();
>srcWB.close();
>destWB.close();
>   
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
> For additional commands, e-mail: dev-h...@poi.apache.org

Re: XmlBeans - Link commits to Jira

[Alain FAGOT BÉAREZ]

+1

⁣Enviado por BlueMail ​


 Mensagem Original 
De: Andreas Beeker 
Por: Sun Feb 24 21:59:43 GMT+01:00 2019
Para: POI Developers List 
Assunto: XmlBeans - Link commits to Jira

Hi *,

I've opened a ticket for linking our svn commits to the corresponding Jira 
ticket:
https://issues.apache.org/jira/browse/INFRA-17694

I'll request the following ... with a lazy consensus (please check above, for 
the context):

[Tracking:xmlbeans]
svn: https://svn.apache.org/repos/asf/xmlbeans/trunk
trigger: (XMLBEANS-\d+)
reviewboard: false
ignoredBranches: (none - only track trunk)
worklog: true

worklog = true is rarely used - setting it to false will result in a new commit 
comment. I think the worklog is more practical to not spam the comment section.

trigger means the phrase to be added to the commit comments. So you need to add 
"(XMLBEANS-12345)" to your commit.

Andi.

Re: PPTX getting the custome marked list with special icons.

[Alain FAGOT BÉAREZ]

Hi,

It seems the bullet style is defined at the master level, not directly 
at the paragraph level, in your particular case.


Unfortunately, I did not have time to finish the high level API which 
was intended to perform the search for these paragraph properties.


When trying to use the following code on your paragraph, some null 
reference will be returned too:


String bulletId = 
shape.getTextBody().getParagraph(0).getBulletProperties().getPicture().getXmlObject().getEmbed();


Cheers,
Alain FAGOT BÉAREZ

Je 2020-03-04 09:55, savotii skribis:

Unfortunately, your example doesn't work for me.
para.getPPr().getBuBlip() returns a null.


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

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

[Alain FAGOT BÉAREZ]

+1

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

Re: Todos for POI 5.0

[Alain FAGOT BÉAREZ]

Hi all,

There is additionally a change I started to work on in May:

l) extend from XDDF for paragraphs and runs in XSLF and XSSF

I had unfortunately not been able to make the final changes.

Best regards,
Alain FAGOT BÉAREZ

⁣Obter o BlueMail para Android ​

Em 17 de ago de 2020 00:42, em 00:42, Andreas Beeker  
escreveu:
>Hi Devs,
>
>there are a quite a few todos left, before we can start with a release
>candidate:
>
>a) fix the maven poms to reflect the current dependencies
>maybe we need to look into using profiles for Java 8 vs JPMS
>
>b) release xmlbeans
>
>c) fix the sonar build and check if we have any blockers and
>vulnerabilities
>
>d) create a sample OSGi project e.g. with Apache Felix and check the
>interoperability of JPMS and OSGi [1]
>
>e) update the servicemix bundle for POI and XmlBeans
>
>f) remove all the obsolete deprecates
>HWPF contains deprecates without alternatives, maybe undeprecate them
>as nobody cares about those ...
>
>g) test and provide a patch for TIKA
>
>h) check/fix the documentation on how to use the modules
>
>i) maybe try the modules in an application server and see how they
>behave
>
>j) discuss if we might want to consider #56205, now that the schema
>jars will be updated
>
>k) replace further (integer) constants with enums?
>
>Please append and comment the list if you have further ideas ... and
>yes "don't break everything" is there too, but with semantic versioning
>its tempting to do breaking changes on the major version. ... and if
>you want to adopt one of the points, please do so.
>
>Best wishes,
>Andi.
>
>[1]
>
>https://blog.osgi.org/2013/02/javautilserviceloader-in-osgi.html
>
>https://adapt.to/content/dam/adaptto/production/presentations/2018/adaptTo2018-Java9-and-OSGi-R7-with-Apache-Felix-and-Sling-Carsten-Ziegeler-Karl-Pauls.pdf/_jcr_content/renditions/original.media_file.download_attachment.file/adaptTo2018-Java9-and-OSGi-R7-with-Apache-Felix-and-Sling-Carsten-Ziegeler-Karl-Pauls.pdf

Missing commons-compress jar in dist

[Alain FAGOT BÉAREZ]

Hi,

While trying to experiment the latest build, I noticed the 
commons-compress-1.20.jar was not present in the binary distribution.

Cheers,
Alain FAGOT BÉAREZ


⁣Obter o BlueMail para Android ​

Re: Missing commons-compress jar in dist

[Alain FAGOT BÉAREZ]

Hi,

I just dropped the current lib folder of my local project and replaced 
its content with the jars from the #977 build.


All tests passed without any trouble. Thanks PJ!

Cheers,
Alain FAGOT BÉAREZ

PS: I understood that JAXB dependencies had been removed recently to 
ease the move to Java 11 modules.



Je 2020-05-29 00:45, fannin...@apache.org skribis:

I fixed the issue with commons-compress.jar. I notice that the
build.xml assemble target has some other jars that we seem to want to
include in the tar.gz but the wrong path is provided. I removed the
junit line but can add it back if it is needed. The jaxb jars are also
not being included.






On Thursday 28 May 2020, 10:14:43 GMT+2, Alain FAGOT BÉAREZ
 wrote:





Hi,

While trying to experiment the latest build, I noticed the
commons-compress-1.20.jar was not present in the binary distribution.

Cheers,
Alain FAGOT BÉAREZ


⁣Obter o BlueMail para Android ​

-
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

Bug 63290 - was Re: Next version?

[Alain FAGOT BÉAREZ]

Hi,

About #63290, I recently pushed a change for XSLTTextRun to recover
the CTTextCharacterProperties from its paragraph default run properties 
(defRPr)

when no run properties are defined.

The test is incomplete but at least shows the correct font size for the 
provided example.


Best regards,
Alain FAGOT BÉAREZ

Je 2020-05-29 17:49, Andreas Beeker skribis:

Hi,

the JAXB dependency was removed as part of #64411 and I haven't yet
checked/fixed the release procedures.
I'm currently struggling with #63290.

Before releasing POI 5.0.0, I'd like to try to update XmlBeans along
the xmlbeans-536 branch,
so we can go away from the Jigsaw incompatible main directory
schemaorg_apache_xmlbeans.


*Although 5.0.0 is mentioned in a few files, please make up you mind,
if we release 4.1.3 with minor changes first or go the full step.*


Andi


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

Re: POI 5.0.0 - are we ready?

[Alain FAGOT BÉAREZ]

Hi all,

The only changes I would recommend to have in the 5.0.0 release are related to 
the current chart bugs.

I did open a PR which I have no time to test and effectively use, about the 
hole size in the doughnut chart.

One other is related to the examples not producing a file which can be opened 
with Microsoft Office... For that one, I have no idea what is the root cause.

Best regards,
Alain FAGOT BÉAREZ



⁣Obter o BlueMail para Android ​

Em 5 de dez de 2020 14:11, em 14:11, Yegor Kozlov  
escreveu:
>Trunk is in a good shape. I don't see any blockers to release what we
>have.
>
>Yegor
>
>чт, 3 дек. 2020 г., 2:08 fannin...@apache.org :
>
>> My view is that it's been a while since we last did a release. There
>> shouldn't be any pressure to finish any work that is in progress but
>if we
>> think the code base is stable enough, we could release what we have
>and do
>> a 5.1.0 or 6.0.0 release in the near future.
>>
>>
>>
>>
>>
>>
>> On Wednesday 2 December 2020, 22:39:52 GMT, Andreas Beeker <
>> kiwiwi...@apache.org> wrote:
>>
>>
>>
>>
>>
>> Hi Devs,
>>
>> although I still have an unfinished business with EMF/WMF raster
>> operations, I think this would take some more time to be resolved.
>> I only know from Alain that he's still working on XDDF - but maybe
>his
>> work can be included into 5.1.0.
>>
>> So are we ready for the 5.0.0 release?
>>
>> Best wishes,
>> 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
>>
>>

How to best deal with XSLFTextParagraph, XSSFTextParagraph and XDDFTextParagraph?

[Alain FAGOT BÉAREZ]

Hi,

Currently I am trying to find a path between maintaining some source 
compatibility and throwing it completely away.


To better illustrate my concerns, please take a look at the latest 
commit on my working branch:

https://github.com/cuali/poi/commit/dc6523f1df00fd10c11eef863c6c9a24e45e9905

On one hand, I break code compatibility renaming *etLineSpacing to 
*etLineSpacingValue in order to merge these functions into 
XDDFTextParagraph:

https://github.com/cuali/poi/commit/dc6523f1df00fd10c11eef863c6c9a24e45e9905#diff-e99644263dc7f4a47e813d54a36c272be278fa8e39c85d4ce4c4357f5223d674R280

On the other hand, I introduce bridges between legacy enumeration and 
the XDDF enumeration:

https://github.com/cuali/poi/commit/dc6523f1df00fd10c11eef863c6c9a24e45e9905#diff-d6d7d40b89c121304c594a27abcd97e36a5e479d6aa87f500145412dfe29b680R52-R76

In this effort, I am dancing between the constraints of existing common 
interface between HSLFTextParagraph and XSLFTextParagraph on one side,
and duplicated code, which I mostly copied into XDDFTextParagraph in the 
past years, in XSLFTextParagraph and XSSFTextParagraph on the other 
side.
The origin of the whole XDDF package is due to the fact that both XSLF 
and XSSF use the same underlying drawingml schema to represent text 
bodies,
but two distinct implementations had been derived for text bodies in 
slides and in spreadsheets before I joined the project.


Maybe the right approach would be to simply throw away both XSLF and 
XSSF specific implementations and keep only the XDDFTextParagaph 
instead?
But then, what would occur with the common interface shared between 
HSLFTextParagraph and XSLFTextParagraph, when replacing with 
XDDFTextParagaph?
Should it be extended to HSSFTextParagraph and XDDFTextParagaph as well? 
I never touched any class on the H**F side of the force!


I would have liked to finish this code cleanup before the wrapping up of 
the 5.0.0 release otherwise we would have yet another major break to 
6.0.0 with that.


Could you provide some kind of sane advices?

Kind regards,
Alain FAGOT BÉAREZ

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

Re: Logging

[Alain FAGOT BÉAREZ]

Hi,

+1 for a 5.0.1 before the switch to Log4j, removing the POILogger from the code 
base

Alain FAGOT BÉAREZ


⁣Obter o BlueMail para Android ​

Em 25 de jan de 2021 08:21, em 08:21, Dominik Stadler  
escreveu:
>Hi,
>
>+1 for a 5.0.1 first, there were already a few useful fixes which we
>could
>pack into a small bugfix release along with fixes for the "known
>issues" in
>5.0.0.
>
>On the actual framework to use I don't have a preference, I seem to end
>up
>with at least 3 different ones in any project as soon as more than a
>few
>dependencies are dragged in, so trying to stick to one never really
>works
>anyway.
>
>Dominik.
>
>On Sat, Jan 23, 2021 at 11:11 PM PJ Fanning
>
>wrote:
>
>> If we change the logging to log4j2 then I think we should at least
>bump
>> the POI version to 5.1.0.
>>
>> I would prefer to see a 5.0.1 release before we make the logging
>change -
>> since we raised awareness of a known issue in the release notes.
>>
>> I would like to see POILogger removed. I dislike having to use a
>system
>> property to override the default POILogger implementation
>(NullLogger).
>>
>> In the past, I'd have preferred slf4j because it gives users more
>control
>> as to what logging implementation to use but slf4j doesn't seem to be
>as
>> actively maintained as it once was.
>>
>>
>>
>>
>>
>>
>> On Saturday 23 January 2021, 20:39:04 GMT, Andreas Beeker <
>> kiwiwi...@apache.org> wrote:
>>
>>
>>
>>
>>
>> Hi Devs,
>>
>> As POI 5.0.0 is out and Marius is now a committer (*hint* ;) ), I
>think
>> the logging topic can be discussed again.
>>
>> So do we want ...
>> a) to keep SLF4J
>> b) or replace it with Log4j 2
>> c) or any other logging api
>>
>> ... and ...
>> d) to keep the POILogger class/facade
>> e) or directly call the Logging API
>>
>> As we have now some time until 5.0.1, I would vote for b) + e). I can
>also
>> do the replacement if no-one else dares too.
>>
>> What's your stance?
>>
>> Are dependency changes like this a major (semver) version change?
>>
>> 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: XSLFTable handling - partly revert #1875901 ?

[Alain FAGOT BÉAREZ]

Hi Andi, 


Please consider my attempt to revert the addRow method to its behaviour
prior to 4.1.2, where I broke it, in my pull request
https://github.com/apache/poi/pull/221 


I must admit that the underlying handling of the table grid kind of
escapes the mind focus when I try to reason about rows and cells. 

Sorry for all the inconveniences, 

Alain 


Je 2021-01-19 01:26, Andreas Beeker skribis:

Hi Alain, 

please review revision 1875901. 

I think it would be better to not add the cells in XSLFTable.initializeRow, as this changes a lot the way how the tables were used up till now. 


So basically there are two modes in which to look at the tables:
* generating them from the scratch: so you would add each row and each cell 
explicitly like one would generate html tables
* adding a cell to an existing row like in Excel, where the cells of the surrounding rows need to be filled accordingly 

I think the second operation could be provided more explicitly and not via a call to XSLFTableRow.addCell, i.e. there's too much "magic" involved for me. 

Although I've fixed the growing table grid locally [1] this dependents on the above decision. 


Best wishes,
Andi 


[1] XSLFSheet ...:

@Override
public XSLFTable createTable(int numRows, int numCols){
if (numRows < 1 || numCols < 1) {
throw new IllegalArgumentException("numRows and numCols must be greater than 
0");
}
XSLFTable sh = getDrawing().createTable();
getShapes().add(sh);
sh.setParent(this);
for (int r=0; r

Re: POI 5.0.1?

[Alain FAGOT BÉAREZ]

Hi,

About bugs related to charts, I managed to fix three of them. I don't have much 
hope to fix any other in the next few days.

+1 for 5.0.1 as soon as reasonably possible

Best regards,
Alain FAGOT BÉAREZ


⁣Obter o BlueMail para Android ​

Em 1 de fev de 2021 14:44, em 14:44, Dominik Stadler  
escreveu:
>Hi,
>
>I don't see any immediate blocker, hopefully some users upgraded to
>Apache
>POI 5.0.0 in the meantime without reports of severe problems, so seems
>the
>initial release was fairly good as well.
>
>No recent open bugs marked as "active patches" that I see,
>
>No PRs on Github that are severe.
>
>For https://bz.apache.org/bugzilla/show_bug.cgi?id=65103 "Java
>application
>cannot launch using JPMS and POI-OOXML 5.0.0" I am not sure, could be
>user-error as well and likely needs some more back- and forth before it
>is
>triaged enough to fix anything if necessary.
>
>So +1 from me as well for already doing a bugfix release now.
>
>Regards... Dominik.
>
>
>On Mon, Feb 1, 2021 at 2:55 AM Marius Volkhart 
>wrote:
>
>> +1 for 5.0.1 from me.
>>
>> --
>> Cheers,
>> Marius Volkhart
>>
>>
>>
>> On Wed, Jan 27, 2021 at 10:36 PM Andreas Beeker
>
>> wrote:
>>
>> > Hi Devs,
>> >
>> > when are we ready for POI 5.0.1?
>> >
>> > ... until then I'll continue fixing sonar issues.
>> >
>> > I'll try to fix the "Constant names should comply with a naming
>> > convention" issues next by introducing enum values and deprecating
>int
>> > constants.
>> >
>> > Andi
>> >
>> >
>> >
>-
>> > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
>> > For additional commands, e-mail: dev-h...@poi.apache.org
>> >
>> >
>>

Re: [VOTE] Apache XmlBeans 5.0.1 release (RC1)

[Alain FAGOT BÉAREZ]

+1

⁣Obter o BlueMail para Android ​

Em 2 de jul de 2021 23:07, em 23:07, Andreas Beeker  
escreveu:
>Hi *,
>
>I've prepared artifacts for the release of Apache XmlBeans 5.0.1 (RC1).
>
>The most notable changes in this release are:
>
>* Support annotations longer than 64kb
>* Support enumerations with more than 64k entries
>* Enable mapping of schema annotations to javadoc entries in the
>generated classes via schema compiler option
>* Generate TypeSystemHolder as .java (in sources) instead of .class (in
>resources)
>
>https://dist.apache.org/repos/dist/dev/poi/xmlbeans/5.0.1-RC1/
>
>I haven't updated the "provided" dependencies as those have to be
>activated anyway explicitly.
>
>Please vote to release the artifacts.
>The vote keeps open until 2021-07-09 23:00 UTC.
>Planned release announcement date is Saturday, 2021-07-10.
>
>Here is my +1
>
>Andi
>
>
>-
>To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
>For additional commands, e-mail: dev-h...@poi.apache.org

How to find why seven files are failing the integration tests?

[Alain FAGOT BÉAREZ]

Hi all,

Where can I find more details about the reasons why the following 7 
files make the tests fail with my modified sheet cloning method which 
includes now the charts as well?


test-integration:
[junitlauncher]
[junitlauncher] Running org.apache.poi.stress.TestAllFiles
[junitlauncher]Failed: #1876 spreadsheet/64450.xlsx XSSF
[junitlauncher]Failed: #1886 spreadsheet/65016.xlsx XSSF
[junitlauncher]Failed: #2207 spreadsheet/WithChart.xlsx XSSF
[junitlauncher]Failed: #2240 spreadsheet/WithThreeCharts.xlsx XSSF
[junitlauncher]Failed: #2244 spreadsheet/WithTwoCharts.xlsx XSSF
[junitlauncher]Failed: #2313 
spreadsheet/dataValidationTableRange.xlsx XSSF
[junitlauncher]Failed: #2445 spreadsheet/simple-monthly-budget.xlsx 
XSSF
[junitlauncher] Tests run: 7683, Failures: 7, Aborted: 0, Skipped: 0, 
Time elapsed: 158.311000 sec


What is now going wrong in which operation with them?

Best regards,
Alain FAGOT BÉAREZ

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

Re: How to find why seven files are failing the integration tests?

[Alain FAGOT BÉAREZ]

Hi,

Thanks for the stack trace and for the pointer to the other tests results! I 
will check the errors and try to get the code to handle these seven files 
correctly as well.

Best regards,
Alain FAGOT BÉAREZ


⁣Obter o BlueMail para Android ​

Em 13 de fev de 2021 14:55, em 14:55, PJ Fanning  
escreveu:
>Hi Alain,
>WithChart.xlsx fails with
>
>Caused by: java.lang.NullPointerException
>
>        at
>org.apache.poi.xddf.usermodel.chart.XDDFDataSourcesFactory.fromDataSource(XDDFDataSourcesFactory.java:45)
>
>        at
>org.apache.poi.xddf.usermodel.chart.XDDFLineChartData$Series.(XDDFLineChartData.java:119)
>
>        at
>org.apache.poi.xddf.usermodel.chart.XDDFLineChartData.(XDDFLineChartData.java:45)
>
>        at
>org.apache.poi.xddf.usermodel.chart.XDDFChart.getChartSeries(XDDFChart.java:456)
>
>        at
>org.apache.poi.xddf.usermodel.chart.XDDFChart.replaceReferences(XDDFChart.java:1088)
>
>        at
>org.apache.poi.xssf.usermodel.XSSFWorkbook.cloneSheet(XSSFWorkbook.java:682)
>
>        at
>org.apache.poi.xssf.usermodel.XSSFWorkbook.cloneSheet(XSSFWorkbook.java:578)
>
>        at
>org.apache.poi.xssf.usermodel.XSSFWorkbook.cloneSheet(XSSFWorkbook.java:122)
>
>If you run `ant test-integration` on your laptop, the results are
>logged in
>`build/integration-test-results/TEST-org.apache.poi.stress.TestAllFiles.txt`.
>
>My machine struggles the run all the files through the test but you can
>edit the TestAllFiles.java file in org.apache.poi.stress package and
>change the DirectoryScanner to only include some files.
>
>DirectoryScanner scanner = new DirectoryScanner();
>scanner.setBasedir(ROOT_DIR);
>//I added next line just to run the WithChart.xlsx file test
>scanner.setIncludes(new String[]{"spreadsheet/WithChart.xlsx"});
>scanner.setExcludes(SCAN_EXCLUDES);
>
>
>
>
>
>
>On Friday 12 February 2021, 22:50:48 GMT, Alain FAGOT BÉAREZ
> wrote:
>
>
>
>
>
>Hi all,
>
>Where can I find more details about the reasons why the following 7
>files make the tests fail with my modified sheet cloning method which
>includes now the charts as well?
>
>test-integration:
>[junitlauncher]
>[junitlauncher] Running org.apache.poi.stress.TestAllFiles
>[junitlauncher]    Failed: #1876 spreadsheet/64450.xlsx XSSF
>[junitlauncher]    Failed: #1886 spreadsheet/65016.xlsx XSSF
>[junitlauncher]    Failed: #2207 spreadsheet/WithChart.xlsx XSSF
>[junitlauncher]    Failed: #2240 spreadsheet/WithThreeCharts.xlsx XSSF
>[junitlauncher]    Failed: #2244 spreadsheet/WithTwoCharts.xlsx XSSF
>[junitlauncher]    Failed: #2313
>spreadsheet/dataValidationTableRange.xlsx XSSF
>[junitlauncher]    Failed: #2445 spreadsheet/simple-monthly-budget.xlsx
>
>XSSF
>[junitlauncher] Tests run: 7683, Failures: 7, Aborted: 0, Skipped: 0,
>Time elapsed: 158.311000 sec
>
>What is now going wrong in which operation with them?
>
>Best regards,
>Alain FAGOT BÉAREZ
>
>-
>To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
>For additional commands, e-mail: dev-h...@poi.apache.org
>
>
>-
>To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
>For additional commands, e-mail: dev-h...@poi.apache.org

Re: Next release of POI

[Alain FAGOT BÉAREZ]

Hi,

a) many changes deserve to be released

b) up to you to estimate the benefits or the burden

c) I don't think we introduced API breaking changes, so 5.1.0 would encompass 
the logging changes

Best regards,
Alain FAGOT BÉAREZ


⁣Obter o BlueMail para Android ​

Em 29 de ago de 2021 21:11, em 21:11, PJ Fanning  
escreveu:
>Hi Andi,
>
>a) I think we need a new release
>
>b) I don't think we need to solve all the build issues before the next
>release
>
>c) I'd prefer to call the next release 6.0.0 or failing that 5.1.0. The
>log4j change makes calling next release 5.0.1 problematic for me. 
>
>
>
>
>
>
>On Sunday 29 August 2021, 18:57:42 IST, Andreas Beeker
> wrote:
>
>
>
>
>
>Hi Devs,
>
>a) what's your opinion about rolling the next release?
>
>From my side, only the distsource build is not implemented in gradle
>and a few of the release task need to be done manually.
>
>b) Now that the gradle dist plugin picks up all the dependencies, how
>important is the distsource check?
>
>c) what's our next release version? 5.0.1,  5.1 or 6.0
>
>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: slf4j dependency on an beta version

[Alain FAGOT BÉAREZ]

Hi,

The company where I work currently also uses 1.7.32 with no reason to use any 
beta versions.

+1 for 1.7.32

Cheers,
Alain FAGOT BÉAREZ



⁣Obter o BlueMail para Android ​

Em 23 de set de 2021 21:17, em 21:17, PJ Fanning  
escreveu:
> Thanks Andi - I'll change to 1.7.32.
>
>
>On Thursday 23 September 2021, 20:15:38 IST, Andreas Beeker
> wrote:
>
> Hi PJ,
>
>On 23.09.21 20:54, PJ Fanning wrote:
>> Does anyone know why we don't just rely on slf4j-api 1.7.x?
>>
>I've raised the dependency to the beta version, because I saw the 2.x
>alpha and thought this would be the latest stable and they aren't
>continuing on the 1.x branch.
>
>1.7.x is ok for me, if you ask me in that way ;)
>
>Andi
>
>
>-
>To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
>For additional commands, e-mail: dev-h...@poi.apache.org
>
>

Re: POI 5.1.0 RC2?

[Alain FAGOT BÉAREZ]

Hi,

I will definitely need to reorganise my life to reserve some time for the 
required XDDF improvements. The code has been developed with only a few 
examples. This is why it is still marked with @Beta but people seem to start 
using it for real...

Best regards,
Alain FAGOT BÉAREZ


⁣Obter o BlueMail para Android ​

Em 18 de out de 2021 23:14, em 23:14, PJ Fanning  
escreveu:
>A large fraction of the errors
>in 
>http://people.apache.org/~centic/poi_regression/reports/index500RC2to510RC1.html
>relate to cloning sheets that contain charts - where the XDDF code
>fails to clone the chart.
>
>This is just an observation - I must admit to not knowing much about
>the XDDF code.
>
>
>
>
>
>
>On Monday 18 October 2021, 18:04:54 IST, Dominik Stadler
> wrote:
>
>
>
>
>
>Hi,
>
>See the report at
>http://people.apache.org/~centic/poi_regression/reports/index500RC2to510RC1.html
>, one of the files is
>http://people.apache.org/~centic/poi_regression/reports/bib-chernigovka.netdo.ru_download_docs_17459.doc
>(it's actually a docx, so is processed via XSSFFileHandler).
>
>Thanks... Dominik.
>
>On Mon, Oct 18, 2021 at 5:06 PM PJ Fanning
>
>wrote:
>
>> Hi Dominik,
>> Would you be able to provide one of the files that causes the missing
>xsb
>> issues? I could try debugging to see if I can see why it fails.
>>
>>
>>
>>
>>
>> On Monday 18 October 2021, 12:12:02 IST, PJ Fanning
>>  wrote:
>>
>>
>>
>>
>>
>> Maybe POI 5.1.0 poi-ooxml can default to poi-ooxml-full as the
>dependency
>> and we could produce the lite jar with a health warning and
>documentation
>> about how to use that instead if you choose to? After POI 5.1.0, we
>could
>> see if the community needs the lite jar at all. Some users still try
>to use
>> POI on android and maybe they would prefer smaller jar sizes.
>>
>>
>>
>>
>>
>>
>> On Monday 18 October 2021, 11:54:04 IST, Dominik Stadler <
>> dominik.stad...@gmx.at> wrote:
>>
>>
>>
>>
>>
>> Hi,
>>
>> hm, would be fairly tedious to look for up to 107 documents and add
>all of
>> them to the integration-tests. Would be nice to know what changes
>made them
>> required now as the documents themselves did not change. For now I
>will
>> trigger another mass-testing run with "full" sometimes this week.
>>
>> FYI, as "lite" is only 3-times smaller than "full" nowadays and
>disk-sizes
>> and download speeds have greatly improved over the years I will
>propose
>> removal of the "lite" jar and all the related pieces after the 5.1.0
>> release. The amount of work we put into this is very high and gains
>for our
>> uses are small by now. Even the recent JDK 17 segfaults in CI may be
>> related to byte-code rewriting that is done for this. Also building
>locally
>> takes ages because nearly every Gradle target has to run all tests
>> including integration-tests now, very hard to do anything useful, at
>least
>> for me.
>>
>> Dominik.
>>
>>
>>
>> On Mon, Oct 18, 2021 at 11:40 AM PJ Fanning
>
>> wrote:
>>
>> > Thanks Dominik for running the tests. I'm not sure what the best
>approach
>> > is but adding some of the files that cause the missing xsb issues
>to the
>> > poi-test-data dir might be a good starting point.
>> >
>> >
>> >
>> >
>> >
>> >
>> > On Monday 18 October 2021, 08:05:21 IST, Dominik Stadler <
>> > dominik.stad...@gmx.at> wrote:
>> >
>> >
>> >
>> >
>> >
>> > FYI, I did re-run the mass-testing and the missing schema is still
>> > reported a lot (>90k times).
>> >
>> > One sample missing xsb is
>> > org/apache/poi/schemas/ooxml/system/ooxml/backgroundelement.xsb
>> >
>> > This was also not included in the "lite" package in 5.0.0, so it
>seems
>> > some code-change now requires this, but it is not included
>> automatically...
>> >
>> > I extracted the attached list of 107 missing XSBs.
>> >
>> > Dominik.
>> >
>> >
>> > On Fri, Oct 15, 2021 at 1:17 AM Andreas Beeker
>
>> > wrote:
>> > > "Kept you waiting, huh?" (tm) -No problem for me ... XmlBeans RC2
>looks
>> > good so far, therefore it can be only a matter of days.
>> > >
>> > >
>> > > On

Re: [VOTE] Apache XmlBeans 5.0.3 release (RC2)

[Alain FAGOT BÉAREZ]

+1

⁣Obter o BlueMail para Android ​

Em 23 de dez de 2021 21:11, em 21:11, PJ Fanning  
escreveu:
>Hi everyone,
>
>I've prepared artifacts for the release of Apache XmlBeans 5.0.3 (RC2).
>
>The most notable changes in this release are:
>
>* SampleXmlUtil misses root element with only one child
>* Duplicated "xmlns" attribute in XmlObject.toString() result
>* Upgrade dependencies (javaparser 3.23.1, log4j 2.17.0)
>
>
>A full list of changes is available in the change log:
>
>https://issues.apache.org/jira/projects/XMLBEANS/versions/12350699
>
>
>The artifacts are at:
>
>https://dist.apache.org/repos/dist/release/poi/xmlbeans/dev/
>
>
>
>You can use this maven URL for your mvn/gradle builds:
>
>https://repository.apache.org/content/repositories/staging
>
>
>
>I haven't updated the "provided" dependencies as those have to be
>activated anyway explicitly.
>
>
>Please vote to release the artifacts.
>
>The vote keeps open until 2021-12-29 23:00 UTC.
>
>Planned release announcement date is Friday, 2021-12-31.
>
>
>Here is my +1
>
>
>PJ
>
>-
>To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
>For additional commands, e-mail: dev-h...@poi.apache.org

Re: Java 11 for POI 5?

[Alain FAGOT BÉAREZ]

Hi,

+1 for moving to Java 11 as minimum

My opinion is that we should jump to the oldest LTS version each time one LTS 
reached its end of life. This means that we would jump from 8 to 17 at once... 
Which is also not so friendly to be done right now!

Kind regards,
Alain FAGOT BÉAREZ




⁣Obter o BlueMail para Android ​

Em 17 de fev de 2024 09:39, em 09:39, Dominik Stadler 
 escreveu:
>Hi,
>
>What do others thing?
>
>We currently are at +2/-1 for moving to Java 11 minimum.
>
>Would be good if we get a more significant number of votes for this.
>
>Thanks... Dominik.
>
>
>On Sat, Feb 3, 2024 at 10:04 PM Axel Howind  wrote:
>
>> Hi,
>>
>> for whatever reason I cannot reach both the Nabble and MarkMail
>archives
>> to check if this has been discussed before, but I think it would be a
>good
>> idea to bump the minimum Java version for POI 5 to 11. I’d also be ok
>(or
>> rather like) 17. What do you think?
>>
>> Cheers,
>> Axel
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
>> For additional commands, e-mail: dev-h...@poi.apache.org
>>
>>