[jira] [Created] (ODFTOOLKIT-479) Adding Java Microbenchmark Harness performance tests
Svante Schubert created ODFTOOLKIT-479: -- Summary: Adding Java Microbenchmark Harness performance tests Key: ODFTOOLKIT-479 URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-479 Project: ODF Toolkit Issue Type: Wish Affects Versions: 0.6.2-incubating Reporter: Svante Schubert I have read about the new JMH (Java Microbenchmark Harness) of Java. see [http://tutorials.jenkov.com/java-performance/jmh.html] [https://www.baeldung.com/java-microbenchmark-harness] Is this the right tool? I have just applied some of the above to get a performance test running. *I will add right away a new GIT branch "performance"* Something is missing and I have not yet found out what. Could someone being curious please give me some assistance on that? Thanks in advance, Svante -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ODFTOOLKIT-478) Adding namespaces to manifest and digital signature DOM by fix & refactoring of generator
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Svante Schubert resolved ODFTOOLKIT-478. Resolution: Fixed Fix Version/s: 0.6.2-incubating ODF Toolkit build worked under Java version: 1.8.0_181, vendor: Oracle Corporation, runtime: C:\Program Files\Java\jdk1.8.0_181\jre Default locale: en_US, platform encoding: Cp1252 OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" > Adding namespaces to manifest and digital signature DOM by fix & refactoring > of generator > - > > Key: ODFTOOLKIT-478 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-478 > Project: ODF Toolkit > Issue Type: Bug > Components: generator, odfdom >Affects Versions: 0.6.2-incubating >Reporter: Svante Schubert >Assignee: Svante Schubert >Priority: Major > Fix For: 0.6.2-incubating > > Attachments: > generator__refactor-creation-of-manifest_dsig-files.patch, > odfdom__new-generated-pkg-dom - missing namespaces.patch > > > There are no namespaces generated for the generated DOM classes of the > manifest schema and the digital signature schema. > I realized this during my attempt to continue merging the ODFDOM of my > feature branch > https://github.com/svanteschubert/odftoolkit/tree/odf-changes > with our latest ODFDOM version. > As I am funded by PrototypeFund and will work as well on the source code > generation for the ODF Toolkit, I have done several updates already. > # Updated from Apache Velocity 1.7 to 2.0 (to read the latest manual and get > latest features) > # Using latest Apache Xerces parser instead of the JDK bundled parser (just > a precaution) for a compile-time library. > # The Velocity template shall in the future derive from each other ODF 1.2 > DOM java fixes/enhancements for the DOM of the > content.xml/meta.xml/styles.xml shall be simultaneously used by manifest and > signature. > # I continue to refactor (after this issue) and make generation more modular > so DOM from other formats can easier be loaded. > # Later (after this issue), it is to consider if some Attributes in general > and some simple Elements become members of a class to raise. Performance > tests might tell. > I have first refactored within Schema Generator and fixed afterwards the > ODFDOM package layer, therefore there are two patches. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ODFTOOLKIT-478) Adding namespaces to manifest and digital signature DOM by fix & refactoring of generator
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Svante Schubert updated ODFTOOLKIT-478: --- Attachment: odfdom__new-generated-pkg-dom - missing namespaces.patch > Adding namespaces to manifest and digital signature DOM by fix & refactoring > of generator > - > > Key: ODFTOOLKIT-478 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-478 > Project: ODF Toolkit > Issue Type: Bug > Components: generator, odfdom >Affects Versions: 0.6.2-incubating >Reporter: Svante Schubert >Assignee: Svante Schubert >Priority: Major > Attachments: > generator__refactor-creation-of-manifest_dsig-files.patch, > odfdom__new-generated-pkg-dom - missing namespaces.patch > > > There are no namespaces generated for the generated DOM classes of the > manifest schema and the digital signature schema. > I realized this during my attempt to continue merging the ODFDOM of my > feature branch > https://github.com/svanteschubert/odftoolkit/tree/odf-changes > with our latest ODFDOM version. > As I am funded by PrototypeFund and will work as well on the source code > generation for the ODF Toolkit, I have done several updates already. > # Updated from Apache Velocity 1.7 to 2.0 (to read the latest manual and get > latest features) > # Using latest Apache Xerces parser instead of the JDK bundled parser (just > a precaution) for a compile-time library. > # The Velocity template shall in the future derive from each other ODF 1.2 > DOM java fixes/enhancements for the DOM of the > content.xml/meta.xml/styles.xml shall be simultaneously used by manifest and > signature. > # I continue to refactor (after this issue) and make generation more modular > so DOM from other formats can easier be loaded. > # Later (after this issue), it is to consider if some Attributes in general > and some simple Elements become members of a class to raise. Performance > tests might tell. > I have first refactored within Schema Generator and fixed afterwards the > ODFDOM package layer, therefore there are two patches. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ODFTOOLKIT-478) Adding namespaces to manifest and digital signature DOM by fix & refactoring of generator
Svante Schubert created ODFTOOLKIT-478: -- Summary: Adding namespaces to manifest and digital signature DOM by fix & refactoring of generator Key: ODFTOOLKIT-478 URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-478 Project: ODF Toolkit Issue Type: Bug Components: generator, odfdom Affects Versions: 0.6.2-incubating Reporter: Svante Schubert Assignee: Svante Schubert There are no namespaces generated for the generated DOM classes of the manifest schema and the digital signature schema. I realized this during my attempt to continue merging the ODFDOM of my feature branch https://github.com/svanteschubert/odftoolkit/tree/odf-changes with our latest ODFDOM version. As I am funded by PrototypeFund and will work as well on the source code generation for the ODF Toolkit, I have done several updates already. # Updated from Apache Velocity 1.7 to 2.0 (to read the latest manual and get latest features) # Using latest Apache Xerces parser instead of the JDK bundled parser (just a precaution) for a compile-time library. # The Velocity template shall in the future derive from each other ODF 1.2 DOM java fixes/enhancements for the DOM of the content.xml/meta.xml/styles.xml shall be simultaneously used by manifest and signature. # I continue to refactor (after this issue) and make generation more modular so DOM from other formats can easier be loaded. # Later (after this issue), it is to consider if some Attributes in general and some simple Elements become members of a class to raise. Performance tests might tell. I have first refactored within Schema Generator and fixed afterwards the ODFDOM package layer, therefore there are two patches. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ODFTOOLKIT-477) Added cell padding to simple api
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16607038#comment-16607038 ] Svante Schubert commented on ODFTOOLKIT-477: Hello Ibrahim, Thanks for your patch! It would be very cool if you could write some brief regression test that tests the cell padding features you have added. Like, adding a new test method in org.odftoolkit.simple.table.TabelCellTest, which sets a padding saves the document, reloads it and tests if the padding was correctly set. By doing so, we could simply see by loading the saved document if the padding was correctly set and we would have an automated regression test that would guarantee us that the feature will never break away unnoticed. Best regards, Svante > Added cell padding to simple api > > > Key: ODFTOOLKIT-477 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-477 > Project: ODF Toolkit > Issue Type: Improvement > Components: simple api >Reporter: Adam Ibrahim >Priority: Minor > Attachments: 0001-Add-ability-to-change-padding-for-table-cells.patch > > > I was creating a document where the padding on the cells mattered. So I added > the ability to manipuate the cell padding from the simple API. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ODFTOOLKIT-474) list decorators with different bullet points
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Svante Schubert resolved ODFTOOLKIT-474. Resolution: Fixed GitHub has been enabled and I have pushed your patch yesterday to the repository! Cheers, Svante > list decorators with different bullet points > > > Key: ODFTOOLKIT-474 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-474 > Project: ODF Toolkit > Issue Type: Improvement > Components: simple api >Reporter: Georg Füchsle >Assignee: Svante Schubert >Priority: Major > Attachments: ListDecoratorImplementation.patch, ListTest.java.patch > > > Now it is not possible to create lists like: > a) item1 > b) item2 > or > I) item1 > II) item2 > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ODFTOOLKIT-474) list decorators with different bullet points
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16468928#comment-16468928 ] Svante Schubert commented on ODFTOOLKIT-474: I have reviewed the patches and they works well, the problem I encountered earlier was related to the SVN patch import from Netbeans 8, I am longing for Netbeans 9 from Apache ;) Only one thing I have adopted, I declared the DEFAULT_DISC_CHAR only once and might it available for all classes from the package. Our GITHUB is still read-only, but I will push as soon the final problems have been resolved, see https://issues.apache.org/jira/browse/INFRA-15596 Thanks again for the patch, Georg! Svante > list decorators with different bullet points > > > Key: ODFTOOLKIT-474 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-474 > Project: ODF Toolkit > Issue Type: Improvement > Components: simple api >Reporter: Georg Füchsle >Assignee: Svante Schubert >Priority: Major > Attachments: ListDecoratorImplementation.patch, ListTest.java.patch > > > Now it is not possible to create lists like: > a) item1 > b) item2 > or > I) item1 > II) item2 > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (ODFTOOLKIT-474) list decorators with different bullet points
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Svante Schubert reassigned ODFTOOLKIT-474: -- Assignee: Svante Schubert > list decorators with different bullet points > > > Key: ODFTOOLKIT-474 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-474 > Project: ODF Toolkit > Issue Type: Improvement > Components: simple api >Reporter: Georg Füchsle >Assignee: Svante Schubert >Priority: Major > Attachments: ListDecoratorImplementation.patch, ListTest.java.patch > > > Now it is not possible to create lists like: > a) item1 > b) item2 > or > I) item1 > II) item2 > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (ODFTOOLKIT-474) list decorators with different bullet points
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Svante Schubert reassigned ODFTOOLKIT-474: -- Assignee: (was: Svante Schubert) > list decorators with different bullet points > > > Key: ODFTOOLKIT-474 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-474 > Project: ODF Toolkit > Issue Type: Improvement > Components: simple api >Reporter: Georg Füchsle >Priority: Major > Attachments: ListDecoratorImplementation.patch, ListTest.java.patch > > > Now it is not possible to create lists like: > a) item1 > b) item2 > or > I) item1 > II) item2 > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (ODFTOOLKIT-474) list decorators with different bullet points
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Svante Schubert reassigned ODFTOOLKIT-474: -- Assignee: Svante Schubert > list decorators with different bullet points > > > Key: ODFTOOLKIT-474 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-474 > Project: ODF Toolkit > Issue Type: Improvement > Components: simple api >Reporter: Georg Füchsle >Assignee: Svante Schubert >Priority: Major > Attachments: ListDecoratorImplementation.patch, ListTest.java.patch > > > Now it is not possible to create lists like: > a) item1 > b) item2 > or > I) item1 > II) item2 > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ODFTOOLKIT-473) cache alien element and attribute class to make it faster in OdfXMLFactory
[
https://issues.apache.org/jira/browse/ODFTOOLKIT-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433958#comment-16433958
]
Svante Schubert commented on ODFTOOLKIT-473:
Pretty cool, Fanliwen!
On the road, but I will dive into your patches asap!
Any suggestions in regard to a performance regression test?
There are some large regression test documents in a test subfolder, but no
performance test work out-of-the-box, yet.
Thanks for your contribution!
Svante
> cache alien element and attribute class to make it faster in OdfXMLFactory
> --
>
> Key: ODFTOOLKIT-473
> URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-473
> Project: ODF Toolkit
> Issue Type: Improvement
> Components: odfdom
>Affects Versions: 0.6.2-incubating
>Reporter: fanliwen
>Assignee: Svante Schubert
>Priority: Major
> Labels: performance
> Fix For: 0.6.2-incubating
>
> Attachments: alien-performance-jprofiler.png,
> test-case-after-fix.png, test-case-befor-fix.png
>
>
> Hi,
> Class.forName may not be an efficient method. and in
> org.odftoolkit.odfdom.pkg{color:#cc7832}.{color}OdfXMLFactory
> line:153 Class, it use Class.forName to find the Element/Atrribute
> Class. The classCache map make it better to find the Class. But
> we need a cache for Alien Element/Atrribute Class too, otherwise it will find
> the same alien Class by Class.forName again and again. It take too much of
> CPU cycle.
> It show you in the attachment which a snapshot by JProfiler.It call the
> Class.forName 39459 times to find the same Class.
> And this is my pull request in GitHub:
> https://github.com/apache/odftoolkit/pull/3
> Regards.
> ravenq.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (ODFTOOLKIT-473) cache alien element and attribute class to make it faster in OdfXMLFactory
[
https://issues.apache.org/jira/browse/ODFTOOLKIT-473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svante Schubert reassigned ODFTOOLKIT-473:
--
Assignee: Svante Schubert
> cache alien element and attribute class to make it faster in OdfXMLFactory
> --
>
> Key: ODFTOOLKIT-473
> URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-473
> Project: ODF Toolkit
> Issue Type: Improvement
> Components: odfdom
>Affects Versions: 0.6.2-incubating
>Reporter: fanliwen
>Assignee: Svante Schubert
>Priority: Major
> Labels: performance
> Fix For: 0.6.2-incubating
>
> Attachments: alien-performance-jprofiler.png,
> test-case-after-fix.png, test-case-befor-fix.png
>
>
> Hi,
> Class.forName may not be an efficient method. and in
> org.odftoolkit.odfdom.pkg{color:#cc7832}.{color}OdfXMLFactory
> line:153 Class, it use Class.forName to find the Element/Atrribute
> Class. The classCache map make it better to find the Class. But
> we need a cache for Alien Element/Atrribute Class too, otherwise it will find
> the same alien Class by Class.forName again and again. It take too much of
> CPU cycle.
> It show you in the attachment which a snapshot by JProfiler.It call the
> Class.forName 39459 times to find the same Class.
> And this is my pull request in GitHub:
> https://github.com/apache/odftoolkit/pull/3
> Regards.
> ravenq.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ODFTOOLKIT-472) mimetype error
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425768#comment-16425768 ] Svante Schubert commented on ODFTOOLKIT-472: Hello Guzman, do you delete/edit the metadata with the ODF Toolkit and if this is the case, could you please provide a short test function that does it, so someone could debug it. You might reuse an existing metadata test to prove your point. PS: If you are editing the file with note++ it is rather an issue for note++ and you might want to close this issue ;) Thanks in advance, Svante > mimetype error > -- > > Key: ODFTOOLKIT-472 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-472 > Project: ODF Toolkit > Issue Type: Bug > Components: odfdom >Affects Versions: 0.6.2-incubating > Environment: Windows 10 Home 64 Bits > ODF Toolkit 0.6.2 >Reporter: Guzman Rejon >Priority: Major > Attachments: correctmimetypeapplication.odt, > corruptmimetypeapplication.odt > > > Hello, > For odt files, after delete or update its metadata the mimetypeapplication is > corrupted so even is possible open or edit the document in Open Office, other > applications like TIKA not recognize them due to a corrupt > mimetypeapplication. > Example: > # Create a odt file and open it with note++ or some editor, the > mimetypeapplication looks like (please see correctmimetypeapplication.odt): > *mimetypeapplication/vnd.oasis.opendocument.text* > 2. Delete metadata for odt file > 3. Edit with note++ and mimetypeapplication is corrupted (please see > > corruptmimetypeapplication.odt): > *mimetypeK,(ÈÉLN,ÉÌÏÓ/ËKÑËO,Î,ÖË/HÍKÉO.ÍMÍ+Ñ+I* > Could you please send us a patch or workaround to solve this issue? > Thanks a lot in Advance, > Best Regards, > Guzman -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ODFTOOLKIT-300) Memory Leak in ODF Simple API
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369140#comment-16369140 ] Svante Schubert commented on ODFTOOLKIT-300: [~karpenko.alexander] : As you have worked yourself into the problem and as it might influence you, would you be able to come up with a patch to solve the problem, finally? Thanks in advance, Svante > Memory Leak in ODF Simple API > - > > Key: ODFTOOLKIT-300 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-300 > Project: ODF Toolkit > Issue Type: Bug > Components: simple api >Affects Versions: 0.5-incubating > Environment: odfdom-java-0.8.7.jar; simple-odf-0.6.6.jar >Reporter: Mathias Silbermann >Assignee: Svante Schubert >Priority: Major > Fix For: 0.6.2-incubating > > Attachments: MemoryLeak_300.java, TestTextSelection.odt > > > There is a memory leak in the ODF Simple API. I tried both, versions 0.6.6 > and 0.6.5. It appears when running code like the examples on cookbook page > http://incubator.apache.org/odftoolkit/simple/document/cookbook/Manipulate%20TextSearch.html > In short, the call TextNavigation.nextSelection() leads to the leak. When you > look down the method's call stack, you will find that items are added to the > static variable "repository" of the static inner class > "Selection.SelectionManager". The added items are never removed from the > repository. One indication is that the method > Selection.SelectionManager.unregisterItem() is never called. > The code works fine if text navigation is done with few documents. But when > its run on a server thousands of times, it will fill the JVMs memory. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ODFTOOLKIT-471) API crashes/fails to set the format string of a cell in scientific notation
[
https://issues.apache.org/jira/browse/ODFTOOLKIT-471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16360566#comment-16360566
]
Svante Schubert commented on ODFTOOLKIT-471:
IBM has created the Simple API, but abandoned support, so if you desire a fix
you might need it to do it yourself. That's the thing about open source, it is
free, but the service is not necessarily included. You know the slogan: Improve
the parts, that are itching you. :)
1) You get the latest sources. See
http://incubator.apache.org/odftoolkit/source.html
2) There will be the need for a regression test, so best starting taking a look
at the existing ones. If you search for 'setFormatString' in
/simple/src/test
You find a lot of occurrences in this class:
/simple/src/test/java/org/odftoolkit/simple/table/TableCellTest.java
If you add your crash & "don't work" scenarios, you should be able to reproduce
the problem.
If there are any further questions, do not hesitate to ask.
Good Luck,
Svante
> API crashes/fails to set the format string of a cell in scientific notation
> ---
>
> Key: ODFTOOLKIT-471
> URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-471
> Project: ODF Toolkit
> Issue Type: Bug
> Components: simple api
>Affects Versions: 0.6.2-incubating
>Reporter: Enrico Scantamburlo
>Priority: Major
>
> I need to create a ods document using the Apache ODF Toolking and to format
> the content of its cells.
> I was able to set a format for dates and simple numbers, but for some reason
> when I try to format with scientific notation it does not work. It fails to
> parse the string or it wraps the E00 into "E00"
> {code:java}
> Row numRow = rows.get(1);
> numRow.getCellByIndex(0).setDoubleValue(9.12345678);
> numRow.getCellByIndex(0).setFormatString("0.000"); // works
> //numRow.getCellByIndex(0).setFormatString("0.00E+00"); // crashes
> //numRow.getCellByIndex(0).setFormatString("0.00E00"); // does not work, it
> becomes 0.00"E00"
> {code}
> I also posted a question [ here |
> [https://stackoverflow.com/questions/48709473/formatting-cells-with-apache-odf-toolkit-simple-api-and-java]
> ]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (ODFTOOLKIT-470) Font size change does not work in Microsoft Office 2016
Svante Schubert created ODFTOOLKIT-470: -- Summary: Font size change does not work in Microsoft Office 2016 Key: ODFTOOLKIT-470 URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-470 Project: ODF Toolkit Issue Type: Bug Components: simple api Affects Versions: 0.6.2-incubating Reporter: Svante Schubert Setting the font size for a western font size, will not change the font size for complex and CJK language, which seems to be a problem for MS Office 2016. Run testHeaderFooterFontSize() method of Simple API Junit test org.odftoolkit.simple.text.FooterTest.java and read a detailed description in the mail on the odf-dev list: https://lists.apache.org/thread.html/5df40ed1ca043b4e4c9cb9e5af3c2880550d67796672eb5fcb5f4e2e@%3Codf-dev.incubator.apache.org%3E -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ODFTOOLKIT-469) Setting Local results to invalid ODF documents
Svante Schubert created ODFTOOLKIT-469: -- Summary: Setting Local results to invalid ODF documents Key: ODFTOOLKIT-469 URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-469 Project: ODF Toolkit Issue Type: Bug Components: simple api Affects Versions: 0.6.2-incubating Reporter: Svante Schubert Setting Local results to invalid ODF documents. Run testHeaderFooterFontSize() method of Simple API Junit test org.odftoolkit.simple.text.FooterTest.java and validate the output in https://odfvalidator.org/ A detailed description can be found in the mail on the odf-dev list: https://lists.apache.org/thread.html/5df40ed1ca043b4e4c9cb9e5af3c2880550d67796672eb5fcb5f4e2e@%3Codf-dev.incubator.apache.org%3E -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ODFTOOLKIT-466) Exceptions when trying to read border
[
https://issues.apache.org/jira/browse/ODFTOOLKIT-466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16255382#comment-16255382
]
Svante Schubert commented on ODFTOOLKIT-466:
>From my perspective, the Simple API has no reason to exist on a long term. It
>was once created by a fork from IBM - which with their abundance of
>OpenOffice.org also got abandoned. In addition, the fork involved many code
>duplications to the ODFDOM project (likely by and copy/paste) and not
>well-designed feature as the lists or the table handling as you see, which
>need a rewrite.
Therefore, I will be focusing on improving the ODFDOM project instead. By first
enhancing the code generation and building afterwards an improved highlevel API
upon it supporting collaboration by dispatchable ODF changes each representing
a single user change.
To focus and save time, I will personally no longer invest time into the Simple
API, it is deprecated to me.
> Exceptions when trying to read border
> -
>
> Key: ODFTOOLKIT-466
> URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-466
> Project: ODF Toolkit
> Issue Type: Bug
> Components: simple api
>Reporter: Olivier Cailloux
>
> When reading in an ODS document a border that has a diagonal set, I get
> various exceptions: {{IllegalArgumentException}}, {{NumberFormatException}},
> {{NullPointerException}}.
> Example and sample files
> [here|https://github.com/oliviercailloux/Test-ODFToolkit-ODS/tree/bug-diag].
> Here is the code.
> {code:java}
> try (InputStream inputStream = TestODS.class.getResourceAsStream("IAE.ods");
> SpreadsheetDocument spreadsheetDoc =
> SpreadsheetDocument.loadDocument(inputStream)) {
> Table table = spreadsheetDoc.getTableByName("Table");
> Cell a1Cell = table.getCellByPosition("A1");
> Cell borderCell = table.getCellByPosition("F4");
> Border left =
> borderCell.getStyleHandler().getBorder(CellBordersType.LEFT);
> Border borderBottomLeft =
> borderCell.getStyleHandler().getBorder(CellBordersType.DIAGONALBLTR);
> Border borderTopLeft =
> borderCell.getStyleHandler().getBorder(CellBordersType.DIAGONALTLBR);
> }
> {code}
> The code generally crashes at
> {{borderCell.getStyleHandler().getBorder(CellBordersType.LEFT);}} (or later,
> depending on the document).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (ODFTOOLKIT-458) Map the ODF XML RelaxNG schema into a GraphDB for Analysis
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Svante Schubert updated ODFTOOLKIT-458: --- Attachment: Gephi-GraphML-Odf-Table-View.png table_table.graphml After building generator/schema2template of the codegenerator branch of my GitHub fork, there will be GraphML files for all XML element of PuzzlePieces (see https://incubator.apache.org/odftoolkit/0.6.2-incubating/schema2template/) under /generator/schema2template/target/graphML/ For instance, OpenDocument-v1_2-os-schema_rng/ as The table_table.graphml file is attached similar a screenshot from the rendered GraphML in Gephi, after using the forceLayout and several layout extensions. (Gephi is basically an Application build on top of Netbeans). A description how you tune the layout can be found at https://gephi.org/tutorials/gephi-tutorial-visualization.pdf Note: The graphml screenshot is of the previous version, the current one alrady marks graph edges representing a sequence green and providing an order attribute. > Map the ODF XML RelaxNG schema into a GraphDB for Analysis > -- > > Key: ODFTOOLKIT-458 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-458 > Project: ODF Toolkit > Issue Type: Wish >Reporter: Svante Schubert >Assignee: Svante Schubert > Attachments: Gephi-GraphML-Odf-Table-View.png, edge.properties, > odf12-graph.xml, table_table.graphml, vertex.properties > > > *PROBLEM* > The ODF XML (RelaxNG) schema is too big to easily read or be analysed by > humans. > In version ODF 1.2 it has 598 elements and 1300 attributes. > *SOLUTION* > Therefore I would love to load the ODF XML RelaxNG schema into a GraphDB (for > instance Neo4J) and do some basic analysis (sanity checks) on it. > For instance, I am curious on query questions as: > a) is a certain ODF element able to become nested (e.g. ) > b) is every ODF element with an ID allowed to exist more than once (this > issue occurred) > c) what is the minimum mandatory ODF XML document > etc. > These queries could help a lot to understand and test the XML schema. > Certainly, I would love to have afterwards more tooling. > For instance, to be able to add metadata to the nodes to categorise nodes > (which are meant for metadata, styles, text container, which are just plain > boilerplate (e.g. office:body) > The idea is to improve the generation of ODFDOM source code to allow easier > maintainability. > *DESIGN IDEA* > Instead of reading plain RelaxNG, I thought it might be a better idea to read > already a 'normalised' document the dumped internal model from MSV. You may > find the dump for each ODF version as test references from > /generator/schema2template/src/test/resources/examples/odf > e.g. > http://svn.apache.org/viewvc/incubator/odf/trunk/generator/schema2template/src/test/resources/examples/odf/odf12-msvtree.ref?revision=1167972=co > > NOTE: > You may find more about the information on the dump and the MSV model in: > /generator/schema2template/src/main/java/schema2template/example/odf/OdfHelper.java > and > /generator/schema2template/target/apidocs/index.html > https://incubator.apache.org/odftoolkit/0.6.2-incubating/schema2template/ > I would love to have a discussion on further thoughts of yours on the list. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (ODFTOOLKIT-458) Map the ODF XML RelaxNG schema into a GraphDB for Analysis
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16249684#comment-16249684 ] Svante Schubert commented on ODFTOOLKIT-458: I have provided an interesting new milestone for the code generation, that I have placed for now on my github repo: https://github.com/svanteschubert/odftoolkit/tree/code-generation [Note: The reason not to commit it yet to trunk, is aside of our ongoing SVN2GIT transition also some W3C schema test files from the invoice domain (e.g. UN/CEFACT Cross Industrie Invoice and the new Italien XML invoice format according to the new EU semantic specification regarding electronic invoice), which likely not fit to the Apache license, but I am currently using for testing.] *My milestone:* In the code generator (generator/schema2template/) our XML PuzzlePieces expressing parts of the schema (ie. starting from one element including all nodes down to their element descendants and stopping with them) is now represented by a subgraph of the RelaxNG XML schema stored in the Apache Tinkerpop Graph Database reference implementation. Even better, I was able to dump the graph model for every puzzle piece of every schema (also some W3C invoice schemas) the graph as GraphXML and was able to nicely render it using the Gephi tool. I will attach one version of the table:table to show you the advantage. The next step to me is to simplify the graph after dumping the raw version and removing human noise, for instance # Removing all REF to elements, which are just named as the element (only exchanging ':' with '_') # Exchange the (Choice -> Epsilon) pattern with an optional attribute # Drop the interleave node for attributes Likely more pattern will follow during round-trip of optimizations. > Map the ODF XML RelaxNG schema into a GraphDB for Analysis > -- > > Key: ODFTOOLKIT-458 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-458 > Project: ODF Toolkit > Issue Type: Wish >Reporter: Svante Schubert >Assignee: Svante Schubert > Attachments: edge.properties, odf12-graph.xml, vertex.properties > > > *PROBLEM* > The ODF XML (RelaxNG) schema is too big to easily read or be analysed by > humans. > In version ODF 1.2 it has 598 elements and 1300 attributes. > *SOLUTION* > Therefore I would love to load the ODF XML RelaxNG schema into a GraphDB (for > instance Neo4J) and do some basic analysis (sanity checks) on it. > For instance, I am curious on query questions as: > a) is a certain ODF element able to become nested (e.g. ) > b) is every ODF element with an ID allowed to exist more than once (this > issue occurred) > c) what is the minimum mandatory ODF XML document > etc. > These queries could help a lot to understand and test the XML schema. > Certainly, I would love to have afterwards more tooling. > For instance, to be able to add metadata to the nodes to categorise nodes > (which are meant for metadata, styles, text container, which are just plain > boilerplate (e.g. office:body) > The idea is to improve the generation of ODFDOM source code to allow easier > maintainability. > *DESIGN IDEA* > Instead of reading plain RelaxNG, I thought it might be a better idea to read > already a 'normalised' document the dumped internal model from MSV. You may > find the dump for each ODF version as test references from > /generator/schema2template/src/test/resources/examples/odf > e.g. > http://svn.apache.org/viewvc/incubator/odf/trunk/generator/schema2template/src/test/resources/examples/odf/odf12-msvtree.ref?revision=1167972=co > > NOTE: > You may find more about the information on the dump and the MSV model in: > /generator/schema2template/src/main/java/schema2template/example/odf/OdfHelper.java > and > /generator/schema2template/target/apidocs/index.html > https://incubator.apache.org/odftoolkit/0.6.2-incubating/schema2template/ > I would love to have a discussion on further thoughts of yours on the list. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (ODFTOOLKIT-465) Enabling JDK 9 build
Svante Schubert created ODFTOOLKIT-465: -- Summary: Enabling JDK 9 build Key: ODFTOOLKIT-465 URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-465 Project: ODF Toolkit Issue Type: Improvement Reporter: Svante Schubert Assignee: Svante Schubert Oracle has published its last public JDK 8 release and the first patch of JDK 9 is published as well. Therefore it is about time to make the ODF Toolkit build with JDK 9. Currently, the ODF Toolkit does not build, due to the modularization by JIGSAW. The tools.jar do no longer exist, but the required JavaDoc Taglet API became part of JDK API. Our Taglet project is compiling when applying the patch suggested by: https://stackoverflow.com/questions/35240134/declare-maven-dependency-on-tools-jar-to-work-on-jdk-9 Other issues might hide behind this problem. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (ODFTOOLKIT-424) PERFORMANCE: Reuse XMLFactrories, currently created too frequently during insertNode and setTextContent.
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Svante Schubert updated ODFTOOLKIT-424: --- Summary: PERFORMANCE: Reuse XMLFactrories, currently created too frequently during insertNode and setTextContent. (was: PERFORMANCE: Reuse DOMRDFaParser, currently created too frequently during insertNode and setTextContent.) > PERFORMANCE: Reuse XMLFactrories, currently created too frequently during > insertNode and setTextContent. > > > Key: ODFTOOLKIT-424 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-424 > Project: ODF Toolkit > Issue Type: Improvement > Components: odfdom > Environment: odfdom-java-0.8.11-incubating-SNAPSHOT, jdk1.8.0_77, > MSWin7 >Reporter: Nimarukan >Assignee: Svante Schubert >Priority: Minor > Labels: patch, performance > Fix For: 0.6.2-incubating > > Attachments: Issue-424-patches.zip > > > https://issues.apache.org/jira/secure/attachment/12795379/odftoolkit-performance-test.zip > This spreadsheet filling and copying test runs more slowly than desired. > One problem that contributes to the slow performance is that > DOMRDFaParser is created too frequently, potentially for every cell, > during insertNode and setTextContent. > Possible fixes, that reuse the DOMRDFaParser and its XMLOutputFactory and > XMLEventFactory, can reduce the run time to 36-40% of the current runtime on > 0.8.11 snapshot. > h4. DIAGNOSIS > Profiling the test (in NetBeans) reveals the filesystem is being accessed > proportional to the number of cells. > A culprit appears to be that > org.odftoolkit.odfdom.pkg.OdfFileDom.updateInContentMetadataCache(org.w3c.dom.Node) > is called by > - > org.odftoolkit.odfdom.dom.element.text.TextParagraphElementBase.onInsertNode > () > - > org.odftoolkit.odfdom.dom.element.table.TableTableCellElementBase.onInsertNode > () > - > org.odftoolkit.odfdom.dom.element.text.TextParagraphElementBase.setTextContent > (String) > On every call updateInContentMetaDataCache calls > - org.odftoolkit.odfdom.pkg.rdfa.DOMRDFaParser.createInstance(this.sink) > which in turn calls > -- javax.xml.stream.XMLEventFactory.newInstance() > -- javax.xml.stream.XMLOutputFactory.newInstance() > -- org.odftoolkit.odfdom.pkg.rdfa.DOMRDFaParser(JenaSink, XMLOutputFactory, > XMLEVentFactory, URIExtractor) > which in turn calls > --- org.odftoolkit.odfdom.pkg.rdfa.RDFaParser(JenaSink, XMLOutputFactory, > XMLEVentFactory, URIExtractor) > which in turn calls > net.rootdev.javardfa.Parser(StatementSink) > which in turn AGAIN calls > - javax.xml.stream.XMLEventFactory.newInstance() > - javax.xml.stream.XMLOutputFactory.newInstance() > The newInstance methods are expensive because they access the file system > looking for service providers. Repeating such expensive calls for every cell > is one reason this test case is slow. > h4. POSSIBLE FIXES: > h5. A. One approach is to address three opportunities to improve: > - 1. Make RDFaParser share its XMLEventFactory, XMLOutputFactory, and > URIExtractor with its superclass javardfa.Parser, so that they are not > duplicated within each parser. > - 2. Reuse XMLEventFactory and XMLOutputFactory from JenaSink like > URIExtractor, so they do not have to be recreated on every call that creates > a SAXRDFaParser or DOMRDFaParser. > - 3. Reuse SAXRDFaParser and DOMRDFaParser from the same JenaSink, so they do > not have to be recreated on every call that needs an RDFa parser. > h5. B. Another approach is to do 1 and 2 without 3. > This will eliminate repeatedly constructing the expensive factories for > each cell, but leaves the repeated construction of the parsers. > h5. C. A simpler approach is to only reuse DOMRDFaParser: > This will greatly reduce the frequency of creating the factories (including > the duplicate ones). (SAXRDFaParser is only called by OdfFileDom in the > initialize method, so it is not important to reuse.) > h4. POSSIBLE CRITERIA: > h5. Reducing computation: > Rough figures from brief runs (not repeated runs): > B reduces time to about 40% of the original. > C reduces time to about 37% of the original. > A reduces time to about 36% of the original. > 'A' saves more computation than 'B' or 'C'. > h5. Minimizing change: > The RDFa parsers are all code that overrides library superclass > net.rootdev.javardfa.Parser with some modifications. The superclass was not > designed for the modifications, so there is a large duplication of code. To > preserve the similarities between the superclass code and the copied subclass > code, it may be best to minimize modifications to copied code in the subclass > parsers. > Approach 'C' meets
[jira] [Updated] (ODFTOOLKIT-464) Pom does not follow best practices
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Svante Schubert updated ODFTOOLKIT-464: --- Summary: Pom does not follow best practices (was: Pom does not follow best practices: missing optional keyword) > Pom does not follow best practices > -- > > Key: ODFTOOLKIT-464 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-464 > Project: ODF Toolkit > Issue Type: Bug > Components: simple api >Reporter: Olivier Cailloux >Assignee: Svante Schubert >Priority: Minor > > When depending on Apache ODFToolkit simple-odf in my application > (org.apache.odftoolkit:simple-odf:0.8.2-incubating), I observe that > com.sun:tools is transitively imposed on my project as a dependency (coming > from taglets, see its > [POM|https://repo1.maven.org/maven2/org/apache/odftoolkit/taglets/0.8.11-incubating/taglets-0.8.11-incubating.pom], > coming from > [org.apache.odftoolkit:odfdom-java:0.8.11-incubating|http://search.maven.org/#search%7cgav%7c1%7cg%3A%22org.apache.odftoolkit%22%20AND%20a%3A%22odfdom-java%22]). > Similarly, org.slf4j:slf4j-log4j12 is passed to my project as a dependency. > I suspect these dependencies are actually not required for projects depending > on simple-odf. > It is possible and simple to ease the life of users of simple-odf by adding > in the relevant pom files. This would respect Maven best > practices. (See for example > [SO|https://stackoverflow.com/questions/32231814/how-can-i-remove-logback-from-a-librarys-dependency-while-keeping-slf4j].) > Workaround: add exclusion rules for these artifacts (see this example > [POM|https://github.com/oliviercailloux/Test-ODFToolkit-ODS/blob/master/pom.xml]). > (I tried to discuss it > [here|https://lists.apache.org/thread.html/6fa4257e67ede90bac58f5518e1be41e7561a451149cbc9eecdbbf1e@%3Codf-users.incubator.apache.org%3E] > but received no answer.) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (ODFTOOLKIT-464) Pom does not follow best practices: missing optional keyword
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Svante Schubert resolved ODFTOOLKIT-464. Resolution: Fixed Assignee: Svante Schubert Thanks for the clarification, Olivier. I have applied your suggested fix. The ODFDOM build is still fine after removing the explicit tools.jar dependency as you had suggested. The implicit one within the JavaDoc description is sufficient. And as on the latest branch (trunc) the latest Jena version is already used, the none API reference to LOG4J has vanished. After the fix the simple API dependency tree looks after calling in the Simple Project on command line: mvn dependency:tree [INFO] Scanning for projects... [INFO] [INFO] [INFO] Building Simple Java API for ODF (Simple ODF) 0.9.0-incubating-SNAPSHOT [INFO] [INFO] [INFO] --- maven-dependency-plugin:2.10:tree (default-cli) @ simple-odf --- [INFO] org.apache.odftoolkit:simple-odf:jar:0.9.0-incubating-SNAPSHOT [INFO] +- org.apache.odftoolkit:odfdom-java:jar:0.9.0-incubating-SNAPSHOT:compile [INFO] | +- org.apache.jena:jena-core:jar:3.2.0:compile [INFO] | | +- org.slf4j:slf4j-api:jar:1.7.21:compile [INFO] | | +- org.apache.jena:jena-iri:jar:3.2.0:compile [INFO] | | +- commons-cli:commons-cli:jar:1.3:compile [INFO] | | \- org.apache.jena:jena-base:jar:3.2.0:compile [INFO] | | +- org.apache.jena:jena-shaded-guava:jar:3.2.0:compile [INFO] | | +- org.apache.commons:commons-csv:jar:1.3:compile [INFO] | | +- org.apache.commons:commons-lang3:jar:3.4:compile [INFO] | | \- com.github.andrewoma.dexx:collection:jar:0.6:compile [INFO] | +- net.rootdev:java-rdfa:jar:0.4.2:compile [INFO] | \- commons-validator:commons-validator:jar:1.6:compile [INFO] | +- commons-beanutils:commons-beanutils:jar:1.9.2:compile [INFO] | +- commons-digester:commons-digester:jar:1.8.1:compile [INFO] | +- commons-logging:commons-logging:jar:1.2:compile [INFO] | \- commons-collections:commons-collections:jar:3.2.2:compile [INFO] +- xerces:xercesImpl:jar:2.11.0:compile [INFO] +- xml-apis:xml-apis:jar:1.4.01:compile [INFO] \- junit:junit:jar:4.12:test [INFO]\- org.hamcrest:hamcrest-core:jar:1.3:test [INFO] > Pom does not follow best practices: missing optional keyword > > > Key: ODFTOOLKIT-464 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-464 > Project: ODF Toolkit > Issue Type: Bug > Components: simple api >Reporter: Olivier Cailloux >Assignee: Svante Schubert >Priority: Minor > > When depending on Apache ODFToolkit simple-odf in my application > (org.apache.odftoolkit:simple-odf:0.8.2-incubating), I observe that > com.sun:tools is transitively imposed on my project as a dependency (coming > from taglets, see its > [POM|https://repo1.maven.org/maven2/org/apache/odftoolkit/taglets/0.8.11-incubating/taglets-0.8.11-incubating.pom], > coming from > [org.apache.odftoolkit:odfdom-java:0.8.11-incubating|http://search.maven.org/#search%7cgav%7c1%7cg%3A%22org.apache.odftoolkit%22%20AND%20a%3A%22odfdom-java%22]). > Similarly, org.slf4j:slf4j-log4j12 is passed to my project as a dependency. > I suspect these dependencies are actually not required for projects depending > on simple-odf. > It is possible and simple to ease the life of users of simple-odf by adding > in the relevant pom files. This would respect Maven best > practices. (See for example > [SO|https://stackoverflow.com/questions/32231814/how-can-i-remove-logback-from-a-librarys-dependency-while-keeping-slf4j].) > Workaround: add exclusion rules for these artifacts (see this example > [POM|https://github.com/oliviercailloux/Test-ODFToolkit-ODS/blob/master/pom.xml]). > (I tried to discuss it > [here|https://lists.apache.org/thread.html/6fa4257e67ede90bac58f5518e1be41e7561a451149cbc9eecdbbf1e@%3Codf-users.incubator.apache.org%3E] > but received no answer.) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (ODFTOOLKIT-187) ODF Java model based on MSV tree has a random factor
[
https://issues.apache.org/jira/browse/ODFTOOLKIT-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16171373#comment-16171373
]
Svante Schubert commented on ODFTOOLKIT-187:
As the problem results from dumping two Java hash sets the bug is potentially
related to the hashing function.
After enhancing the hash function of the Java Set content, ie. PuzzlePiece.java
the random buggy behaviour did not happen to me again.
BEFORE:
public int hashCode() {
return mExpression.hashCode();
}
AFTER:
public int hashCode() {
return 1013 * (mName.hashCode()) ^ 1009 *
(mExpression.hashCode());
}
> ODF Java model based on MSV tree has a random factor
>
>
> Key: ODFTOOLKIT-187
> URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-187
> Project: ODF Toolkit
> Issue Type: Bug
> Components: codegen
>Affects Versions: odfdom-0.8.7
> Environment: Operating System: All
> Platform: All
>Reporter: Svante Schubert
>Assignee: Svante Schubert
>
> As the test method testExtractPuzzlePiecesWithDuplicates() of PuzzlePieceTest
> reveals varies the number of duplicates (with JDK 5).
> The new MSV engine did not solve this problem, therefore we have to
> investigate further what are the changes.
> Are you able to have a look into this after the review of my work on the MSV,
> where you might base your approach on, Devin?
> Regards,
> Svante
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (ODFTOOLKIT-457) Update Multi-Schema-Validator Reference (and Maven instance)
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16171361#comment-16171361 ] Svante Schubert commented on ODFTOOLKIT-457: The patch has been integrated but still waiting for a release of MSV to access the patch. Remineded Kohsuke again on https://github.com/kohsuke/msv/pull/5 > Update Multi-Schema-Validator Reference (and Maven instance) > > > Key: ODFTOOLKIT-457 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-457 > Project: ODF Toolkit > Issue Type: Improvement > Components: generator >Affects Versions: 0.6.2-incubating >Reporter: Svante Schubert >Assignee: Svante Schubert > Attachments: msv-2017-1-SNAPSHOT.patch > > > I realised last week, that Oracle has moved Sun's Java net projects > (including MSV) to an archive, see https://msv.java.net > As you might know, we are using the Multi Schema Validator to read the ODF > RelaxNG Grammars from the ODF TC site > (http://docs.oasis-open.org/office/v1.2/os/) to create the typed Java sources > of ODF Java classes within our project > /generator/schema2template. > (NOTE: We are not using JAXB - Java Architecture for XML Binding (JAXB) - as > this works only for the W3C XML Schema). > The sources are being created in conjunction with Apache Velocity template > engine. > The latest sources can be found by the former Sun/Oracle developer on GitHub: > https://github.com/kohsuke/msv > Unfortunately, although most patches are on his side, his version number > lacks behind by the last given by Oracle, which we are using. > Therefore I spend a day to merge the fixes from the archived Oracle branch > into the latest from kohsuke on my github > https://github.com/svanteschubert/msv > and asked for a pull request from kohsuke: > https://github.com/kohsuke/msv/pull/5 > Only copyright have not been updated to Oracle's, but I wanted to start to > communicate on a pure technical level. I have asked kohsuke and the Oracle > admin about Maven Central rights, but there is no answer so far. > If anyone like to improve MSV (like adding sequence & choice evaluation for > class generation), the MSV repository should be locally exchanged with my > GitHub version. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (ODFTOOLKIT-458) Map the ODF XML RelaxNG schema into a GraphDB for Analysis
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16154220#comment-16154220 ] Svante Schubert commented on ODFTOOLKIT-458: Next step would be to create some relevant example queries, such as * difference between text:p and text:h element * minimal mandatory ODF text document Perhaps in Gremlin script, I have been moving from Neo4J to something more interoperable, such as http://tinkerpop.apache.org/ > Map the ODF XML RelaxNG schema into a GraphDB for Analysis > -- > > Key: ODFTOOLKIT-458 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-458 > Project: ODF Toolkit > Issue Type: Wish >Reporter: Svante Schubert >Assignee: Svante Schubert > Attachments: edge.properties, odf12-graph.xml, vertex.properties > > > *PROBLEM* > The ODF XML (RelaxNG) schema is too big to easily read or be analysed by > humans. > In version ODF 1.2 it has 598 elements and 1300 attributes. > *SOLUTION* > Therefore I would love to load the ODF XML RelaxNG schema into a GraphDB (for > instance Neo4J) and do some basic analysis (sanity checks) on it. > For instance, I am curious on query questions as: > a) is a certain ODF element able to become nested (e.g. ) > b) is every ODF element with an ID allowed to exist more than once (this > issue occurred) > c) what is the minimum mandatory ODF XML document > etc. > These queries could help a lot to understand and test the XML schema. > Certainly, I would love to have afterwards more tooling. > For instance, to be able to add metadata to the nodes to categorise nodes > (which are meant for metadata, styles, text container, which are just plain > boilerplate (e.g. office:body) > The idea is to improve the generation of ODFDOM source code to allow easier > maintainability. > *DESIGN IDEA* > Instead of reading plain RelaxNG, I thought it might be a better idea to read > already a 'normalised' document the dumped internal model from MSV. You may > find the dump for each ODF version as test references from > /generator/schema2template/src/test/resources/examples/odf > e.g. > http://svn.apache.org/viewvc/incubator/odf/trunk/generator/schema2template/src/test/resources/examples/odf/odf12-msvtree.ref?revision=1167972=co > > NOTE: > You may find more about the information on the dump and the MSV model in: > /generator/schema2template/src/main/java/schema2template/example/odf/OdfHelper.java > and > /generator/schema2template/target/apidocs/index.html > https://incubator.apache.org/odftoolkit/0.6.2-incubating/schema2template/ > I would love to have a discussion on further thoughts of yours on the list. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (ODFTOOLKIT-458) Map the ODF XML RelaxNG schema into a GraphDB for Analysis
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Svante Schubert updated ODFTOOLKIT-458: --- Attachment: odf12-graph.xml vertex.properties edge.properties 1) The two edge and vertex property files containing the data from the MSV memory dump 2) The odf12-graph.xml file exported from a graph database, which was created from the property files before > Map the ODF XML RelaxNG schema into a GraphDB for Analysis > -- > > Key: ODFTOOLKIT-458 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-458 > Project: ODF Toolkit > Issue Type: Wish >Reporter: Svante Schubert >Assignee: Svante Schubert > Attachments: edge.properties, odf12-graph.xml, vertex.properties > > > *PROBLEM* > The ODF XML (RelaxNG) schema is too big to easily read or be analysed by > humans. > In version ODF 1.2 it has 598 elements and 1300 attributes. > *SOLUTION* > Therefore I would love to load the ODF XML RelaxNG schema into a GraphDB (for > instance Neo4J) and do some basic analysis (sanity checks) on it. > For instance, I am curious on query questions as: > a) is a certain ODF element able to become nested (e.g. ) > b) is every ODF element with an ID allowed to exist more than once (this > issue occurred) > c) what is the minimum mandatory ODF XML document > etc. > These queries could help a lot to understand and test the XML schema. > Certainly, I would love to have afterwards more tooling. > For instance, to be able to add metadata to the nodes to categorise nodes > (which are meant for metadata, styles, text container, which are just plain > boilerplate (e.g. office:body) > The idea is to improve the generation of ODFDOM source code to allow easier > maintainability. > *DESIGN IDEA* > Instead of reading plain RelaxNG, I thought it might be a better idea to read > already a 'normalised' document the dumped internal model from MSV. You may > find the dump for each ODF version as test references from > /generator/schema2template/src/test/resources/examples/odf > e.g. > http://svn.apache.org/viewvc/incubator/odf/trunk/generator/schema2template/src/test/resources/examples/odf/odf12-msvtree.ref?revision=1167972=co > > NOTE: > You may find more about the information on the dump and the MSV model in: > /generator/schema2template/src/main/java/schema2template/example/odf/OdfHelper.java > and > /generator/schema2template/target/apidocs/index.html > https://incubator.apache.org/odftoolkit/0.6.2-incubating/schema2template/ > I would love to have a discussion on further thoughts of yours on the list. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (ODFTOOLKIT-458) Map the ODF XML RelaxNG schema into a GraphDB for Analysis
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16154196#comment-16154196 ] Svante Schubert commented on ODFTOOLKIT-458: The first part - the creation of a Graph database filled with the ODF RelaxNG grammar - is working in general and ready for review: a) The ANTL4 grammar to parse the MSV memory dump text file can be found here: https://github.com/svanteschubert/gumtree/tree/msv/gen.antlr4-msv/src/main/antlr/com/github/gumtreediff/gen/antlr4/msv b) The Java class to trigger the grammar and create two property files with data for verteces and edges can be found here: https://github.com/svanteschubert/gumtree/blob/msv/gen.antlr4-msv/src/main/java/com/github/gumtreediff/gen/antlr4/msv/MsvFileMapper.java c) The Java class to read the two property files from the previous step to fill a Graph database and export the new graph into some graphXML file to be loaded into an empty graph database, can be found here: https://github.com/svanteschubert/gumtree/blob/msv/gen.antlr4-msv/src/main/java/com/github/gumtreediff/gen/antlr4/msv/MsvTreeGenerator.java I will attach the two property files and the graphXML file to this issue. NOTE: Currently there is some issue with building ANTLR 4 using package names and split lexer and parser on Unix/Linux. I could only made it run with Windows. > Map the ODF XML RelaxNG schema into a GraphDB for Analysis > -- > > Key: ODFTOOLKIT-458 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-458 > Project: ODF Toolkit > Issue Type: Wish >Reporter: Svante Schubert >Assignee: Svante Schubert > > *PROBLEM* > The ODF XML (RelaxNG) schema is too big to easily read or be analysed by > humans. > In version ODF 1.2 it has 598 elements and 1300 attributes. > *SOLUTION* > Therefore I would love to load the ODF XML RelaxNG schema into a GraphDB (for > instance Neo4J) and do some basic analysis (sanity checks) on it. > For instance, I am curious on query questions as: > a) is a certain ODF element able to become nested (e.g. ) > b) is every ODF element with an ID allowed to exist more than once (this > issue occurred) > c) what is the minimum mandatory ODF XML document > etc. > These queries could help a lot to understand and test the XML schema. > Certainly, I would love to have afterwards more tooling. > For instance, to be able to add metadata to the nodes to categorise nodes > (which are meant for metadata, styles, text container, which are just plain > boilerplate (e.g. office:body) > The idea is to improve the generation of ODFDOM source code to allow easier > maintainability. > *DESIGN IDEA* > Instead of reading plain RelaxNG, I thought it might be a better idea to read > already a 'normalised' document the dumped internal model from MSV. You may > find the dump for each ODF version as test references from > /generator/schema2template/src/test/resources/examples/odf > e.g. > http://svn.apache.org/viewvc/incubator/odf/trunk/generator/schema2template/src/test/resources/examples/odf/odf12-msvtree.ref?revision=1167972=co > > NOTE: > You may find more about the information on the dump and the MSV model in: > /generator/schema2template/src/main/java/schema2template/example/odf/OdfHelper.java > and > /generator/schema2template/target/apidocs/index.html > https://incubator.apache.org/odftoolkit/0.6.2-incubating/schema2template/ > I would love to have a discussion on further thoughts of yours on the list. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (ODFTOOLKIT-464) Pom does not follow best practices: missing optional keyword
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16149595#comment-16149595 ] Svante Schubert commented on ODFTOOLKIT-464: If the dependency should be only on the slf4j API you should get in contact with the Apache Jena project as their project is making this dependency explicit. Regarding the tools.jar, it should and - as far as I am aware of - is only used during JavaDoc creation time. There were once build problems when Oracle changed the location path of the tools.jar within the JDK with Java 8, but I am not aware of any runtime dependency nor problems. > Pom does not follow best practices: missing optional keyword > > > Key: ODFTOOLKIT-464 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-464 > Project: ODF Toolkit > Issue Type: Bug > Components: simple api >Reporter: Olivier Cailloux >Priority: Minor > > When depending on Apache ODFToolkit simple-odf in my application > (org.apache.odftoolkit:simple-odf:0.8.2-incubating), I observe that > com.sun:tools is transitively imposed on my project as a dependency (coming > from taglets, see its > [POM|https://repo1.maven.org/maven2/org/apache/odftoolkit/taglets/0.8.11-incubating/taglets-0.8.11-incubating.pom]). > Similarly, org.slf4j:slf4j-log4j12 is passed to my project as a dependency. > I suspect these dependencies are actually not required for projects depending > on simple-odf. > It is possible and simple to ease the life of users of simple-odf by adding > in the relevant pom files. This would respect Maven best > practices. (See for example > [SO|https://stackoverflow.com/questions/32231814/how-can-i-remove-logback-from-a-librarys-dependency-while-keeping-slf4j].) > Workaround: add exclusion rules for these artifacts (see this example > [POM|https://github.com/oliviercailloux/Test-ODFToolkit-ODS/blob/master/pom.xml]). > (I tried to discuss it > [here|https://lists.apache.org/thread.html/6fa4257e67ede90bac58f5518e1be41e7561a451149cbc9eecdbbf1e@%3Codf-users.incubator.apache.org%3E] > but received no answer.) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (ODFTOOLKIT-464) Pom does not follow best practices: missing optional keyword
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Svante Schubert resolved ODFTOOLKIT-464. Resolution: Invalid Hello Olivier, existing run-time dependencies as the Simple Logging Facade for Java (SLF4J) can not be optional as it is used by the RDF metadata framework Jena. Making the use of RDF and its library optional would require a patch Other mentioned dependencies as the JDK tools.jar are used for JavaDoc enhancements during compile time and already not required during run-time. Therefore, I believe the issue is rather invalid. If someone disagrees, simply reopen the issue with some comment or even better with a patch. :) Regards, Svante > Pom does not follow best practices: missing optional keyword > > > Key: ODFTOOLKIT-464 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-464 > Project: ODF Toolkit > Issue Type: Bug > Components: simple api >Reporter: Olivier Cailloux >Priority: Minor > > When depending on Apache ODFToolkit simple-odf in my application > (org.apache.odftoolkit:simple-odf:0.8.2-incubating), I observe that > com.sun:tools is transitively imposed on my project as a dependency (coming > from taglets, see its > [POM|https://repo1.maven.org/maven2/org/apache/odftoolkit/taglets/0.8.11-incubating/taglets-0.8.11-incubating.pom]). > Similarly, org.slf4j:slf4j-log4j12 is passed to my project as a dependency. > I suspect these dependencies are actually not required for projects depending > on simple-odf. > It is possible and simple to ease the life of users of simple-odf by adding > in the relevant pom files. This would respect Maven best > practices. (See for example > [SO|https://stackoverflow.com/questions/32231814/how-can-i-remove-logback-from-a-librarys-dependency-while-keeping-slf4j].) > Workaround: add exclusion rules for these artifacts (see this example > [POM|https://github.com/oliviercailloux/Test-ODFToolkit-ODS/blob/master/pom.xml]). > (I tried to discuss it > [here|https://lists.apache.org/thread.html/6fa4257e67ede90bac58f5518e1be41e7561a451149cbc9eecdbbf1e@%3Codf-users.incubator.apache.org%3E] > but received no answer.) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (ODFTOOLKIT-464) Pom does not follow best practices: missing optional keyword
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16146959#comment-16146959 ] Svante Schubert commented on ODFTOOLKIT-464: Hello Olivier, The dependencies viewed in the maven dependencies tree are at compile-time (as labeled by the suffix of each entry), not necessary run-time dependencies. For instance, there are no run-time dependencies on com.sun.tools JAR. These are only used for the taglets to create HTML references to the ODF specification within our JavaDoc. You can double check by taking a looking into the JAR with all dependencies, it is simple/target/simple-odf-0.9.0-incubating-SNAPSHOT-jar-with-dependencies.jar Regarding slf4j, take a look at https://www.slf4j.org/ It is the Simple Logging Facade for Java (SLF4J) which serves as a simple facade or abstraction for various logging frameworks (e.g. java.util.logging, logback, log4j) allowing the end user to plug in the desired logging framework at deployment time. No pain from my side to remove this. I see no evident problem for me to be solved, there are others more important to me that require my attention, but if you (or others) have suggestions to improve the situation patches are welcome. Best, Svante > Pom does not follow best practices: missing optional keyword > > > Key: ODFTOOLKIT-464 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-464 > Project: ODF Toolkit > Issue Type: Bug > Components: simple api >Reporter: Olivier Cailloux >Priority: Minor > > When depending on Apache ODFToolkit simple-odf in my application > (org.apache.odftoolkit:simple-odf:0.8.2-incubating), I observe that > com.sun:tools is transitively imposed on my project as a dependency (coming > from taglets, see its > [POM|https://repo1.maven.org/maven2/org/apache/odftoolkit/taglets/0.8.11-incubating/taglets-0.8.11-incubating.pom]). > Similarly, org.slf4j:slf4j-log4j12 is passed to my project as a dependency. > I suspect these dependencies are actually not required for projects depending > on simple-odf. > It is possible and simple to ease the life of users of simple-odf by adding > in the relevant pom files. This would respect Maven best > practices. (See for example > [SO|https://stackoverflow.com/questions/32231814/how-can-i-remove-logback-from-a-librarys-dependency-while-keeping-slf4j].) > Workaround: add exclusion rules for these artifacts (see this example > [POM|https://github.com/oliviercailloux/Test-ODFToolkit-ODS/blob/master/pom.xml]). > (I tried to discuss it > [here|https://lists.apache.org/thread.html/6fa4257e67ede90bac58f5518e1be41e7561a451149cbc9eecdbbf1e@%3Codf-users.incubator.apache.org%3E] > but received no answer.) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (ODFTOOLKIT-464) Pom does not follow best practices: missing optional keyword
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16130307#comment-16130307 ] Svante Schubert commented on ODFTOOLKIT-464: Hello Olivier, the taglets are only required for JavaDoc creation and not for the run time, log4j have to be tested. Could you provide a subversion patch someone might apply and test? Thanks in advance, Svante PS: Sorry, for the oversight of your posting, holiday season take its toll... > Pom does not follow best practices: missing optional keyword > > > Key: ODFTOOLKIT-464 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-464 > Project: ODF Toolkit > Issue Type: Bug > Components: simple api >Reporter: Olivier Cailloux >Priority: Minor > > When depending on Apache ODFToolkit simple-odf in my application > (org.apache.odftoolkit:simple-odf:0.8.2-incubating), I observe that > com.sun:tools is transitively imposed on my project as a dependency (coming > from taglets, see its > [POM|https://repo1.maven.org/maven2/org/apache/odftoolkit/taglets/0.8.11-incubating/taglets-0.8.11-incubating.pom]). > Similarly, org.slf4j:slf4j-log4j12 is passed to my project as a dependency. > I suspect these dependencies are actually not required for projects depending > on simple-odf. > It is possible and simple to ease the life of users of simple-odf by adding > in the relevant pom files. This would respect Maven best > practices. (See for example > [SO|https://stackoverflow.com/questions/32231814/how-can-i-remove-logback-from-a-librarys-dependency-while-keeping-slf4j].) > Workaround: add exclusion rules for these artifacts (see this example > [POM|https://github.com/oliviercailloux/Test-ODFToolkit-ODS/blob/master/pom.xml]). > (I tried to discuss it > [here|https://lists.apache.org/thread.html/6fa4257e67ede90bac58f5518e1be41e7561a451149cbc9eecdbbf1e@%3Codf-users.incubator.apache.org%3E] > but received no answer.) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (ODFTOOLKIT-463) Performance issues
[
https://issues.apache.org/jira/browse/ODFTOOLKIT-463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101625#comment-16101625
]
Svante Schubert commented on ODFTOOLKIT-463:
I missed the addition of the link earlier. I wonder where to place the
performance regression test, is the code added to each project or shared?
I assume the performance regression test is not executed with every build, but
only when explicitly called due to warm-up phase and duration, although it
would be nice to be certain it is executed before a commit.
It's fine with me if we require Oracle JDK due to their extensions for the
performance tests as long the test software referenced from the build script is
available for everyone.
What tooling are you using in addition, Thomas?
> Performance issues
> --
>
> Key: ODFTOOLKIT-463
> URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-463
> Project: ODF Toolkit
> Issue Type: Bug
>Reporter: Thomas Hackel
>Priority: Minor
> Attachments: odf-hotspots.png
>
>
> Version: 0.8.2-incubating (not present in JIRA)
> I have different "output writers" for formats like ODF/CSV/POI etc.
> The ODF version is the slowest of all, it might be a usage problem or a
> ODFToolkit issue.
> It seems that creating new Rows/Cells is consuming a lot of time.
> All other implementations have the QueryDSL.fetch method as the major
> hotspot. With ODFToolkit this data gathering method is only at place 3.
> All what i am doing is creating a new row for each line of data:
> {code:java}
> row = table.getRowByIndex(rowNumber);
> {code}
> I am talking about only 6000 rows.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (ODFTOOLKIT-463) Performance issues
[
https://issues.apache.org/jira/browse/ODFTOOLKIT-463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101608#comment-16101608
]
Svante Schubert commented on ODFTOOLKIT-463:
Thomas, I am not using the Simple API, but working on the ODFDOM level.
But I am willing to invest some time into performance testing. What would you
suggest to build up a performance test scenario or even some performance
regression tests?
Thanks in advance,
Svante
> Performance issues
> --
>
> Key: ODFTOOLKIT-463
> URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-463
> Project: ODF Toolkit
> Issue Type: Bug
>Reporter: Thomas Hackel
>Priority: Minor
> Attachments: odf-hotspots.png
>
>
> Version: 0.8.2-incubating (not present in JIRA)
> I have different "output writers" for formats like ODF/CSV/POI etc.
> The ODF version is the slowest of all, it might be a usage problem or a
> ODFToolkit issue.
> It seems that creating new Rows/Cells is consuming a lot of time.
> All other implementations have the QueryDSL.fetch method as the major
> hotspot. With ODFToolkit this data gathering method is only at place 3.
> All what i am doing is creating a new row for each line of data:
> {code:java}
> row = table.getRowByIndex(rowNumber);
> {code}
> I am talking about only 6000 rows.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (ODFTOOLKIT-462) Adding manifest file to ODFDOM jar-with-dependencies JAR
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Svante Schubert resolved ODFTOOLKIT-462. Resolution: Fixed Fixed with added integration regression tests. > Adding manifest file to ODFDOM jar-with-dependencies JAR > - > > Key: ODFTOOLKIT-462 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-462 > Project: ODF Toolkit > Issue Type: Improvement > Components: odfdom >Affects Versions: 0.6.2-incubating >Reporter: Svante Schubert >Assignee: Svante Schubert >Priority: Minor > Fix For: 0.6.2-incubating > > > java -jar odfdom-java-0.9.0-incubating-SNAPSHOT.jar > provides two lines of basic information to the user: > odfdom 0.9.0-incubating-SNAPSHOT (build 2017-07-20T11:49:15) > from http://incubator.apache.org/odftoolkit/odfdom/index.html supporting ODF > 1.2 > The same should be provided for the JAR including all dependencies: > odfdom-0.9.0-incubating-SNAPSHOT-jar-with-dependencies.jar > An existing integration test of the ODFDOM was disabled and is activated > again and extended. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (ODFTOOLKIT-462) Adding manifest file to ODFDOM jar-with-dependencies JAR
Svante Schubert created ODFTOOLKIT-462: -- Summary: Adding manifest file to ODFDOM jar-with-dependencies JAR Key: ODFTOOLKIT-462 URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-462 Project: ODF Toolkit Issue Type: Improvement Components: odfdom Affects Versions: 0.6.2-incubating Reporter: Svante Schubert Assignee: Svante Schubert Priority: Minor Fix For: 0.6.2-incubating java -jar odfdom-java-0.9.0-incubating-SNAPSHOT.jar provides two lines of basic information to the user: odfdom 0.9.0-incubating-SNAPSHOT (build 2017-07-20T11:49:15) from http://incubator.apache.org/odftoolkit/odfdom/index.html supporting ODF 1.2 The same should be provided for the JAR including all dependencies: odfdom-0.9.0-incubating-SNAPSHOT-jar-with-dependencies.jar An existing integration test of the ODFDOM was disabled and is activated again and extended. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (ODFTOOLKIT-461) [PATCH] regression in validator command line handling
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Svante Schubert resolved ODFTOOLKIT-461. Resolution: Fixed Assignee: Svante Schubert Fix Version/s: 0.6.2-incubating I have added some regression test using the command line option based on the JAR (integration test). Thanks again for the patch, Michael! Svante > [PATCH] regression in validator command line handling > - > > Key: ODFTOOLKIT-461 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-461 > Project: ODF Toolkit > Issue Type: Bug > Components: validator >Affects Versions: 0.7-incubating, 0.6.2-incubating >Reporter: Michael Stahl >Assignee: Svante Schubert > Labels: patch > Fix For: 0.6.2-incubating > > Attachments: 0001-validator-fix-schema-file-command-line-flags.patch > > > this simple invocation fails: > java -jar > .m2/repository/org/apache/odftoolkit/odfvalidator/1.2.0-incubating-SNAPSHOT/odfvalidator-1.2.0-incubating-SNAPSHOT-jar-with-dependencies.jar > foo.odt > Exception in thread "main" java.lang.NullPointerException > at > org.odftoolkit.odfvalidator.ODFValidator.getValidatorForSchema(ODFValidator.java:288) > at > org.odftoolkit.odfvalidator.ODFValidator.getManifestValidator(ODFValidator.java:186) > at > org.odftoolkit.odfvalidator.ODFRootPackageValidator.validateManifest(ODFRootPackageValidator.java:170) > at > org.odftoolkit.odfvalidator.ODFRootPackageValidator.validatePre(ODFRootPackageValidator.java:93) > at > org.odftoolkit.odfvalidator.ODFPackageValidator._validate(ODFPackageValidator.java:111) > at > org.odftoolkit.odfvalidator.ODFPackageValidator.validate(ODFPackageValidator.java:81) > at > org.odftoolkit.odfvalidator.ODFValidator.validateFile(ODFValidator.java:163) > at > org.odftoolkit.odfvalidator.ODFValidator.validate(ODFValidator.java:125) > at org.odftoolkit.odfvalidator.Main.main(Main.java:294) > because of commit > https://svn-master.apache.org/repos/asf/incubator/odf/trunk@1759341 > #ODFTOOLKIT-437# ODFValidator: make schema files configurable from cmd line -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (ODFTOOLKIT-461) [PATCH] regression in validator command line handling
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16093126#comment-16093126 ] Svante Schubert commented on ODFTOOLKIT-461: Thanks for the patch, Michael. I am currently trying to remember how to build a JUnit regression test for command line invocation. Any idea? > [PATCH] regression in validator command line handling > - > > Key: ODFTOOLKIT-461 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-461 > Project: ODF Toolkit > Issue Type: Bug > Components: validator >Affects Versions: 0.7-incubating, 0.6.2-incubating >Reporter: Michael Stahl > Labels: patch > Attachments: 0001-validator-fix-schema-file-command-line-flags.patch > > > this simple invocation fails: > java -jar > .m2/repository/org/apache/odftoolkit/odfvalidator/1.2.0-incubating-SNAPSHOT/odfvalidator-1.2.0-incubating-SNAPSHOT-jar-with-dependencies.jar > foo.odt > Exception in thread "main" java.lang.NullPointerException > at > org.odftoolkit.odfvalidator.ODFValidator.getValidatorForSchema(ODFValidator.java:288) > at > org.odftoolkit.odfvalidator.ODFValidator.getManifestValidator(ODFValidator.java:186) > at > org.odftoolkit.odfvalidator.ODFRootPackageValidator.validateManifest(ODFRootPackageValidator.java:170) > at > org.odftoolkit.odfvalidator.ODFRootPackageValidator.validatePre(ODFRootPackageValidator.java:93) > at > org.odftoolkit.odfvalidator.ODFPackageValidator._validate(ODFPackageValidator.java:111) > at > org.odftoolkit.odfvalidator.ODFPackageValidator.validate(ODFPackageValidator.java:81) > at > org.odftoolkit.odfvalidator.ODFValidator.validateFile(ODFValidator.java:163) > at > org.odftoolkit.odfvalidator.ODFValidator.validate(ODFValidator.java:125) > at org.odftoolkit.odfvalidator.Main.main(Main.java:294) > because of commit > https://svn-master.apache.org/repos/asf/incubator/odf/trunk@1759341 > #ODFTOOLKIT-437# ODFValidator: make schema files configurable from cmd line -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (ODFTOOLKIT-459) Updating Simple API getting started guide description and dependencies
[
https://issues.apache.org/jira/browse/ODFTOOLKIT-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svante Schubert updated ODFTOOLKIT-459:
---
Summary: Updating Simple API getting started guide description and
dependencies (was: Compilation error)
> Updating Simple API getting started guide description and dependencies
> --
>
> Key: ODFTOOLKIT-459
> URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-459
> Project: ODF Toolkit
> Issue Type: Bug
> Components: simple api
>Affects Versions: 0.6-incubating
> Environment: Mac OS 10.11.6
> Android Studio 2.3.3
>Reporter: Herman Tse
>Assignee: Svante Schubert
> Fix For: 0.6.2-incubating
>
>
> Followed instructions on
> http://incubator.apache.org/odftoolkit/simple/gettingstartguide.html
> and included :
> simple-odf-0.6.6.jar
> odfdom-java-0.8.7.jar
> xercesImpl-2.9.1.jar
> xml-apis-1.3.04.jar
> in 'libs' folder and classpath for compilation.
> build.gradle(android):
> android {
> buildToolsVersion "25.0.0"
> compileSdkVersion 25
> sourceSets {
> main {
> manifest.srcFile 'AndroidManifest.xml'
> java.srcDirs = ['src']
> aidl.srcDirs = ['src']
> renderscript.srcDirs = ['src']
> res.srcDirs = ['res']
> assets.srcDirs = ['assets']
> jniLibs.srcDirs = ['libs']
> }
> instrumentTest.setRoot('tests')
> }
> packagingOptions {
> exclude 'META-INF/robovm/ios/robovm.xml'
> }
> defaultConfig {
> applicationId "com.hermantseproduction.htmonkey"
> minSdkVersion 14
> targetSdkVersion 25
> versionName "1.0"
> versionCode 1
>}
> }
> ends up with error when run:
> AGPBI: {"kind":"error","text":"Error converting bytecode to dex:\nCause:
> java.lang.RuntimeException: Exception parsing
> classes","sources":[{}],"original":"UNEXPECTED TOP-LEVEL
> EXCEPTION:\njava.lang.RuntimeException: Exception parsing classes\n\tat
> com.android.dx.command.dexer.Main.processClass(Main.java:781)\n\tat
> com.android.dx.command.dexer.Main.processFileBytes(Main.java:747)\n\tat
> com.android.dx.command.dexer.Main.access$1200(Main.java:88)\n\tat
> com.android.dx.command.dexer.Main$FileBytesConsumer.processFileBytes(Main.java:1689)\n\tat
>
> com.android.dx.cf.direct.ClassPathOpener.processArchive(ClassPathOpener.java:284)\n\tat
>
> com.android.dx.cf.direct.ClassPathOpener.processOne(ClassPathOpener.java:166)\n\tat
>
> com.android.dx.cf.direct.ClassPathOpener.process(ClassPathOpener.java:144)\n\tat
> com.android.dx.command.dexer.Main.processOne(Main.java:695)\n\tat
> com.android.dx.command.dexer.Main.processAllFiles(Main.java:592)\n\tat
> com.android.dx.command.dexer.Main.runMonoDex(Main.java:321)\n\tat
> com.android.dx.command.dexer.Main.run(Main.java:292)\n\tat
> com.android.builder.internal.compiler.DexWrapper.run(DexWrapper.java:54)\n\tat
>
> com.android.builder.core.DexByteCodeConverter.lambda$dexInProcess$0(DexByteCodeConverter.java:174)\n\tat
> java.util.concurrent.FutureTask.run(FutureTask.java:266)\n\tat
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)\n\tat
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)\n\tat
> java.lang.Thread.run(Thread.java:745)\nCaused by:
> com.android.dx.cf.iface.ParseException: bad utf-8 byte a0 at offset
> 0004\n\tat
> com.android.dx.cf.cst.ConstantPoolParser.parseUtf8(ConstantPoolParser.java:374)\n\tat
>
> com.android.dx.cf.cst.ConstantPoolParser.parse0(ConstantPoolParser.java:262)\n\tat
>
> com.android.dx.cf.cst.ConstantPoolParser.parse0(ConstantPoolParser.java:294)\n\tat
>
> com.android.dx.cf.cst.ConstantPoolParser.parse(ConstantPoolParser.java:150)\n\tat
>
> com.android.dx.cf.cst.ConstantPoolParser.parseIfNecessary(ConstantPoolParser.java:124)\n\tat
>
> com.android.dx.cf.cst.ConstantPoolParser.getPool(ConstantPoolParser.java:115)\n\tat
>
> com.android.dx.cf.direct.DirectClassFile.parse0(DirectClassFile.java:482)\n\tat
>
> com.android.dx.cf.direct.DirectClassFile.parse(DirectClassFile.java:406)\n\tat
>
> com.android.dx.cf.direct.DirectClassFile.parseToInterfacesIfNecessary(DirectClassFile.java:388)\n\tat
>
> com.android.dx.cf.direct.DirectClassFile.getMagic(DirectClassFile.java:251)\n\tat
> com.android.dx.command.dexer.Main.parseClass(Main.java:793)\n\tat
> com.android.dx.command.dexer.Main.access$1600(Main.java:88)\n\tat
> com.android.dx.command.dexer.Main$ClassParserTask.call(Main.java:1728)\n\tat
> com.android.dx.command.dexer.Main.processClass(Main.java:779)\n\t... 16
> more\nCaused by: java.lang.IllegalArgumentException: bad utf-8 byte a0 at
> offset 0004\n\tat
>
[jira] [Resolved] (ODFTOOLKIT-459) Compilation error
[
https://issues.apache.org/jira/browse/ODFTOOLKIT-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svante Schubert resolved ODFTOOLKIT-459.
Resolution: Fixed
Assignee: Svante Schubert
Fix Version/s: 0.6.2-incubating
Hello Herman Tse,
Thanks for pointing out the outdated version numbers.
I have updated the the Simple API demo dependencies and added an all-inclusive
JAR from the last release including all dependencies for a quick proof of
concept test.
http://incubator.apache.org/odftoolkit/simple/gettingstartguide.html
Please try your scenario with the new environment.
I fear that we will not be able to assist you in the compile error in your
environment unless you make it obvious by a regression test within the sources
from this project.
Good luck with your work.
Svante
PS: I would be happy if you could tell us a little more about your work on the
odf-dev list.
> Compilation error
> -
>
> Key: ODFTOOLKIT-459
> URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-459
> Project: ODF Toolkit
> Issue Type: Bug
> Components: simple api
>Affects Versions: 0.6-incubating
> Environment: Mac OS 10.11.6
> Android Studio 2.3.3
>Reporter: Herman Tse
>Assignee: Svante Schubert
> Fix For: 0.6.2-incubating
>
>
> Followed instructions on
> http://incubator.apache.org/odftoolkit/simple/gettingstartguide.html
> and included :
> simple-odf-0.6.6.jar
> odfdom-java-0.8.7.jar
> xercesImpl-2.9.1.jar
> xml-apis-1.3.04.jar
> in 'libs' folder and classpath for compilation.
> build.gradle(android):
> android {
> buildToolsVersion "25.0.0"
> compileSdkVersion 25
> sourceSets {
> main {
> manifest.srcFile 'AndroidManifest.xml'
> java.srcDirs = ['src']
> aidl.srcDirs = ['src']
> renderscript.srcDirs = ['src']
> res.srcDirs = ['res']
> assets.srcDirs = ['assets']
> jniLibs.srcDirs = ['libs']
> }
> instrumentTest.setRoot('tests')
> }
> packagingOptions {
> exclude 'META-INF/robovm/ios/robovm.xml'
> }
> defaultConfig {
> applicationId "com.hermantseproduction.htmonkey"
> minSdkVersion 14
> targetSdkVersion 25
> versionName "1.0"
> versionCode 1
>}
> }
> ends up with error when run:
> AGPBI: {"kind":"error","text":"Error converting bytecode to dex:\nCause:
> java.lang.RuntimeException: Exception parsing
> classes","sources":[{}],"original":"UNEXPECTED TOP-LEVEL
> EXCEPTION:\njava.lang.RuntimeException: Exception parsing classes\n\tat
> com.android.dx.command.dexer.Main.processClass(Main.java:781)\n\tat
> com.android.dx.command.dexer.Main.processFileBytes(Main.java:747)\n\tat
> com.android.dx.command.dexer.Main.access$1200(Main.java:88)\n\tat
> com.android.dx.command.dexer.Main$FileBytesConsumer.processFileBytes(Main.java:1689)\n\tat
>
> com.android.dx.cf.direct.ClassPathOpener.processArchive(ClassPathOpener.java:284)\n\tat
>
> com.android.dx.cf.direct.ClassPathOpener.processOne(ClassPathOpener.java:166)\n\tat
>
> com.android.dx.cf.direct.ClassPathOpener.process(ClassPathOpener.java:144)\n\tat
> com.android.dx.command.dexer.Main.processOne(Main.java:695)\n\tat
> com.android.dx.command.dexer.Main.processAllFiles(Main.java:592)\n\tat
> com.android.dx.command.dexer.Main.runMonoDex(Main.java:321)\n\tat
> com.android.dx.command.dexer.Main.run(Main.java:292)\n\tat
> com.android.builder.internal.compiler.DexWrapper.run(DexWrapper.java:54)\n\tat
>
> com.android.builder.core.DexByteCodeConverter.lambda$dexInProcess$0(DexByteCodeConverter.java:174)\n\tat
> java.util.concurrent.FutureTask.run(FutureTask.java:266)\n\tat
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)\n\tat
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)\n\tat
> java.lang.Thread.run(Thread.java:745)\nCaused by:
> com.android.dx.cf.iface.ParseException: bad utf-8 byte a0 at offset
> 0004\n\tat
> com.android.dx.cf.cst.ConstantPoolParser.parseUtf8(ConstantPoolParser.java:374)\n\tat
>
> com.android.dx.cf.cst.ConstantPoolParser.parse0(ConstantPoolParser.java:262)\n\tat
>
> com.android.dx.cf.cst.ConstantPoolParser.parse0(ConstantPoolParser.java:294)\n\tat
>
> com.android.dx.cf.cst.ConstantPoolParser.parse(ConstantPoolParser.java:150)\n\tat
>
> com.android.dx.cf.cst.ConstantPoolParser.parseIfNecessary(ConstantPoolParser.java:124)\n\tat
>
> com.android.dx.cf.cst.ConstantPoolParser.getPool(ConstantPoolParser.java:115)\n\tat
>
> com.android.dx.cf.direct.DirectClassFile.parse0(DirectClassFile.java:482)\n\tat
>
> com.android.dx.cf.direct.DirectClassFile.parse(DirectClassFile.java:406)\n\tat
>
>
[jira] [Commented] (ODFTOOLKIT-458) Map the ODF XML RelaxNG schema into a GraphDB for Analysis
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16068025#comment-16068025 ] Svante Schubert commented on ODFTOOLKIT-458: I finally realised that the file of the memory dump of the Multi-Schema-Model is already representing a graph model. Therefore, I know now how an easy algorithm to create the graph with a plain computer language as in Java would look like, but I want to learn ANTRL for other use cases as well. Therefore I am reading myself now through ANTLR 4 examples. If anybody is already a user of ANTLR, any help is welcome ;) But let me explain how this initial algorithm for reading the Multi-Schema-Validator model from file to create the (Neo4J) graph would look like. This algorithm would create the graph step by step, which is line by line from the file (representing the internal graph model of the Multi-Schema-Validator http://svn.apache.org/viewvc/incubator/odf/trunk/generator/schema2template/src/test/resources/examples/odf/odf12-msvtree.ref?revision=1167972=co every line is (in our initial version) the creation of a graph node and its insertion to a parent (of course, only the initial first node at level 0 and has no parent). Every line is the creating a graph node (for the initial test version) Each node is being added to the graph level the integer number at the beginning of the line is indicating. The example below shows the first 9 lines of the file. Therefore 9 nodes will be added to the graph. First, the sequence from 0 to 7 adds each node as a child to the node from the previous line, which is one level higher (with the exception of 0: CHOICE being the first node of the graph). 0: CHOICE 1: REF 'office-document', 2: ELEMENT "office:document", 3: SEQUENCE 4: REF 'office-document-attrs', 5: ATTRIBUTE "office:mimetype", 6: REF 'string', 7: DATA 'string', 4: REF 'office-document-common-attrs', Second, we have to memorise the last parent of each level, so we can jump back to it. Whenever the integer number of the follow-up line is rising again, we have to look-up the last parent of its level. Like in the end of our example: 7: DATA 'string', 4: REF 'office-document-common-attrs', We will need to add the level 4 REF to the previous level 3 node, which in our example is the SEQUENCE node. > Map the ODF XML RelaxNG schema into a GraphDB for Analysis > -- > > Key: ODFTOOLKIT-458 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-458 > Project: ODF Toolkit > Issue Type: Wish >Reporter: Svante Schubert >Assignee: Svante Schubert > > *PROBLEM* > The ODF XML (RelaxNG) schema is too big to easily read or be analysed by > humans. > In version ODF 1.2 it has 598 elements and 1300 attributes. > *SOLUTION* > Therefore I would love to load the ODF XML RelaxNG schema into a GraphDB (for > instance Neo4J) and do some basic analysis (sanity checks) on it. > For instance, I am curious on query questions as: > a) is a certain ODF element able to become nested (e.g. ) > b) is every ODF element with an ID allowed to exist more than once (this > issue occurred) > c) what is the minimum mandatory ODF XML document > etc. > These queries could help a lot to understand and test the XML schema. > Certainly, I would love to have afterwards more tooling. > For instance, to be able to add metadata to the nodes to categorise nodes > (which are meant for metadata, styles, text container, which are just plain > boilerplate (e.g. office:body) > The idea is to improve the generation of ODFDOM source code to allow easier > maintainability. > *DESIGN IDEA* > Instead of reading plain RelaxNG, I thought it might be a better idea to read > already a 'normalised' document the dumped internal model from MSV. You may > find the dump for each ODF version as test references from > /generator/schema2template/src/test/resources/examples/odf > e.g. > http://svn.apache.org/viewvc/incubator/odf/trunk/generator/schema2template/src/test/resources/examples/odf/odf12-msvtree.ref?revision=1167972=co > > NOTE: > You may find more about the information on the dump and the MSV model in: > /generator/schema2template/src/main/java/schema2template/example/odf/OdfHelper.java > and > /generator/schema2template/target/apidocs/index.html > https://incubator.apache.org/odftoolkit/0.6.2-incubating/schema2template/ > I would love to have a discussion on further thoughts of yours on the list. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (ODFTOOLKIT-456) Missing support for getting active sheet in Spreadsheets
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Svante Schubert closed ODFTOOLKIT-456. -- Pushed patch to TRUNC. NOTE: I have updated an existing document by exchanging the active sheet from the first to second. By saving a default value was exchange, which was fixed in an existing other test. > Missing support for getting active sheet in Spreadsheets > > > Key: ODFTOOLKIT-456 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-456 > Project: ODF Toolkit > Issue Type: New Feature > Components: simple api >Reporter: Siddharth Prasad >Assignee: Svante Schubert > Fix For: 0.6.2-incubating > > Attachments: ActiveSpreadsheetTest.ods, > simple-odf-getActiveSheet.patch, TestSpreadsheetTable_LO.ods, > TestSpreadsheetTable_MSO.ods > > > POI has the feature to be able to get the active sheet index of any > spreadsheet file. But since POI doesn't work with .ods files, I have to use > ODFToolkit. But this feature is missing. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (ODFTOOLKIT-456) Missing support for getting active sheet in Spreadsheets
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Svante Schubert resolved ODFTOOLKIT-456. Resolution: Fixed Assignee: Svante Schubert Fix Version/s: 0.6.2-incubating Thanks for the patch, Siddharth! I have reviewed and tested your patch. There was only one slight improvement. When a Microsoft created ODS is being questioned there will be no settings.xml, so the returned active table would be NULL. I have added a fallback to return the first spreadsheet instead. Pushed your patch to TRUNC! > Missing support for getting active sheet in Spreadsheets > > > Key: ODFTOOLKIT-456 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-456 > Project: ODF Toolkit > Issue Type: New Feature > Components: simple api >Reporter: Siddharth Prasad >Assignee: Svante Schubert > Fix For: 0.6.2-incubating > > Attachments: ActiveSpreadsheetTest.ods, > simple-odf-getActiveSheet.patch, TestSpreadsheetTable_LO.ods, > TestSpreadsheetTable_MSO.ods > > > POI has the feature to be able to get the active sheet index of any > spreadsheet file. But since POI doesn't work with .ods files, I have to use > ODFToolkit. But this feature is missing. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (ODFTOOLKIT-456) Missing support for getting active sheet in Spreadsheets
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Svante Schubert updated ODFTOOLKIT-456: --- Attachment: TestSpreadsheetTable_MSO.ods TestSpreadsheetTable_LO.ods I have attached two new test file. The LO (LibreOffice) created document will exchange the existing TestSreadsheetTable.ods document. The difference is that the active spreadsheet is the middle sheet and not the first (to higher the burden of the test) ;) The other test document has been created by Microsoft Excel 2016. As you might see there is no settings.xml being saved (likely as it is not part of the ODF standard). > Missing support for getting active sheet in Spreadsheets > > > Key: ODFTOOLKIT-456 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-456 > Project: ODF Toolkit > Issue Type: New Feature > Components: simple api >Reporter: Siddharth Prasad > Attachments: ActiveSpreadsheetTest.ods, > simple-odf-getActiveSheet.patch, TestSpreadsheetTable_LO.ods, > TestSpreadsheetTable_MSO.ods > > > POI has the feature to be able to get the active sheet index of any > spreadsheet file. But since POI doesn't work with .ods files, I have to use > ODFToolkit. But this feature is missing. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (ODFTOOLKIT-458) Map the ODF XML RelaxNG schema into a GraphDB for Analysis
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Svante Schubert updated ODFTOOLKIT-458: --- Description: *PROBLEM* The ODF XML (RelaxNG) schema is too big to easily read or be analysed by humans. In version ODF 1.2 it has 598 elements and 1300 attributes. *SOLUTION* Therefore I would love to load the ODF XML RelaxNG schema into a GraphDB (for instance Neo4J) and do some basic analysis (sanity checks) on it. For instance, I am curious on query questions as: a) is a certain ODF element able to become nested (e.g. ) b) is every ODF element with an ID allowed to exist more than once (this issue occurred) c) what is the minimum mandatory ODF XML document etc. These queries could help a lot to understand and test the XML schema. Certainly, I would love to have afterwards more tooling. For instance, to be able to add metadata to the nodes to categorise nodes (which are meant for metadata, styles, text container, which are just plain boilerplate (e.g. office:body) The idea is to improve the generation of ODFDOM source code to allow easier maintainability. *DESIGN IDEA* Instead of reading plain RelaxNG, I thought it might be a better idea to read already a 'normalised' document the dumped internal model from MSV. You may find the dump for each ODF version as test references from /generator/schema2template/src/test/resources/examples/odf e.g. http://svn.apache.org/viewvc/incubator/odf/trunk/generator/schema2template/src/test/resources/examples/odf/odf12-msvtree.ref?revision=1167972=co NOTE: You may find more about the information on the dump and the MSV model in: /generator/schema2template/src/main/java/schema2template/example/odf/OdfHelper.java and /generator/schema2template/target/apidocs/index.html https://incubator.apache.org/odftoolkit/0.6.2-incubating/schema2template/ I would love to have a discussion on further thoughts of yours on the list. was: *PROBLEM* The ODF XML (RelaxNG) schema is too big to easily read or be analysed by humans. In version ODF 1.2 it has 598 elements and 1300 attributes. *SOLUTION* Therefore I would love to load the ODF XML RelaxNG schema into a GraphDB (for instance Neo4J) and do some basic analysis (sanity checks) on it. For instance, I am curious on query questions as: a) is a certain ODF element able to become nested (e.g. ) b) is every ODF element with an ID allowed to exist more than once (this issue occurred) c) what is the minimum mandatory ODF XML document etc. These queries could help a lot to understand and test the XML schema. Certainly, I would love to have afterwards more tooling. For instance, to be able to add metadata to the nodes to categorise nodes (which are meant for metadata, styles, text container, which are just plain boilerplate (e.g. office:body) The idea is to improve the generation of ODFDOM source code to allow easier maintainability. *DESIGN IDEA* Instead of reading plain RelaxNG, I thought it might be a better idea to read already a 'normalised' document the dumped internal model from MSV. You may find the dump for each ODF version as test references from /generator/schema2template/src/test/resources/examples/odf e.g. http://svn.apache.org/viewvc/incubator/odf/trunk/generator/schema2template/src/test/resources/examples/odf/odf12-msvtree.ref?revision=1167972=co NOTE: You may find more about the information on the dump and the MSV model in: /generator/schema2template/src/main/java/schema2template/example/odf/OdfHelper.java and /generator/schema2template/target/apidocs/index.html https://incubator.apache.org/odftoolkit/0.6.2-incubating/schema2template/ I would love to have a discussion on further thoughts of yours on the list. > Map the ODF XML RelaxNG schema into a GraphDB for Analysis > -- > > Key: ODFTOOLKIT-458 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-458 > Project: ODF Toolkit > Issue Type: Wish >Reporter: Svante Schubert >Assignee: Svante Schubert > > *PROBLEM* > The ODF XML (RelaxNG) schema is too big to easily read or be analysed by > humans. > In version ODF 1.2 it has 598 elements and 1300 attributes. > *SOLUTION* > Therefore I would love to load the ODF XML RelaxNG schema into a GraphDB (for > instance Neo4J) and do some basic analysis (sanity checks) on it. > For instance, I am curious on query questions as: > a) is a certain ODF element able to become nested (e.g. ) > b) is every ODF element with an ID allowed to exist more than once (this > issue occurred) > c) what is the minimum mandatory ODF XML document > etc. > These queries could help a lot to understand and test the XML schema. > Certainly, I would love to have afterwards more tooling. > For instance, to be able to add metadata to the nodes to categorise nodes
[jira] [Created] (ODFTOOLKIT-458) Map the ODF XML RelaxNG schema into a GraphDB for Analysis
Svante Schubert created ODFTOOLKIT-458: -- Summary: Map the ODF XML RelaxNG schema into a GraphDB for Analysis Key: ODFTOOLKIT-458 URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-458 Project: ODF Toolkit Issue Type: Wish Reporter: Svante Schubert Assignee: Svante Schubert *PROBLEM* The ODF XML (RelaxNG) schema is too big to easily read or be analysed by humans. In version ODF 1.2 it has 598 elements and 1300 attributes. *SOLUTION* Therefore I would love to load the ODF XML RelaxNG schema into a GraphDB (for instance Neo4J) and do some basic analysis (sanity checks) on it. For instance, I am curious on query questions as: a) is a certain ODF element able to become nested (e.g. ) b) is every ODF element with an ID allowed to exist more than once (this issue occurred) c) what is the minimum mandatory ODF XML document etc. These queries could help a lot to understand and test the XML schema. Certainly, I would love to have afterwards more tooling. For instance, to be able to add metadata to the nodes to categorise nodes (which are meant for metadata, styles, text container, which are just plain boilerplate (e.g. office:body) The idea is to improve the generation of ODFDOM source code to allow easier maintainability. *DESIGN IDEA* Instead of reading plain RelaxNG, I thought it might be a better idea to read already a 'normalised' document the dumped internal model from MSV. You may find the dump for each ODF version as test references from /generator/schema2template/src/test/resources/examples/odf e.g. http://svn.apache.org/viewvc/incubator/odf/trunk/generator/schema2template/src/test/resources/examples/odf/odf12-msvtree.ref?revision=1167972=co NOTE: You may find more about the information on the dump and the MSV model in: /generator/schema2template/src/main/java/schema2template/example/odf/OdfHelper.java and /generator/schema2template/target/apidocs/index.html https://incubator.apache.org/odftoolkit/0.6.2-incubating/schema2template/ I would love to have a discussion on further thoughts of yours on the list. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (ODFTOOLKIT-457) Update Multi-Schema-Validator Reference (and Maven instance)
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Svante Schubert updated ODFTOOLKIT-457: --- Attachment: msv-2017-1-SNAPSHOT.patch NOTE: The new version is not yet at Maven Central, but only available as GitHub repository: https://github.com/svanteschubert/msv Its description can be found in the pull request: https://github.com/kohsuke/msv/pull/5 > Update Multi-Schema-Validator Reference (and Maven instance) > > > Key: ODFTOOLKIT-457 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-457 > Project: ODF Toolkit > Issue Type: Improvement > Components: generator >Affects Versions: 0.6.2-incubating >Reporter: Svante Schubert >Assignee: Svante Schubert > Attachments: msv-2017-1-SNAPSHOT.patch > > > I realised last week, that Oracle has moved Sun's Java net projects > (including MSV) to an archive, see https://msv.java.net > As you might know, we are using the Multi Schema Validator to read the ODF > RelaxNG Grammars from the ODF TC site > (http://docs.oasis-open.org/office/v1.2/os/) to create the typed Java sources > of ODF Java classes within our project > /generator/schema2template. > (NOTE: We are not using JAXB - Java Architecture for XML Binding (JAXB) - as > this works only for the W3C XML Schema). > The sources are being created in conjunction with Apache Velocity template > engine. > The latest sources can be found by the former Sun/Oracle developer on GitHub: > https://github.com/kohsuke/msv > Unfortunately, although most patches are on his side, his version number > lacks behind by the last given by Oracle, which we are using. > Therefore I spend a day to merge the fixes from the archived Oracle branch > into the latest from kohsuke on my github > https://github.com/svanteschubert/msv > and asked for a pull request from kohsuke: > https://github.com/kohsuke/msv/pull/5 > Only copyright have not been updated to Oracle's, but I wanted to start to > communicate on a pure technical level. I have asked kohsuke and the Oracle > admin about Maven Central rights, but there is no answer so far. > If anyone like to improve MSV (like adding sequence & choice evaluation for > class generation), the MSV repository should be locally exchanged with my > GitHub version. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (ODFTOOLKIT-457) Update Multi-Schema-Validator Reference (and Maven instance)
Svante Schubert created ODFTOOLKIT-457: -- Summary: Update Multi-Schema-Validator Reference (and Maven instance) Key: ODFTOOLKIT-457 URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-457 Project: ODF Toolkit Issue Type: Improvement Components: generator Affects Versions: 0.6.2-incubating Reporter: Svante Schubert Assignee: Svante Schubert I realised last week, that Oracle has moved Sun's Java net projects (including MSV) to an archive, see https://msv.java.net As you might know, we are using the Multi Schema Validator to read the ODF RelaxNG Grammars from the ODF TC site (http://docs.oasis-open.org/office/v1.2/os/) to create the typed Java sources of ODF Java classes within our project /generator/schema2template. (NOTE: We are not using JAXB - Java Architecture for XML Binding (JAXB) - as this works only for the W3C XML Schema). The sources are being created in conjunction with Apache Velocity template engine. The latest sources can be found by the former Sun/Oracle developer on GitHub: https://github.com/kohsuke/msv Unfortunately, although most patches are on his side, his version number lacks behind by the last given by Oracle, which we are using. Therefore I spend a day to merge the fixes from the archived Oracle branch into the latest from kohsuke on my github https://github.com/svanteschubert/msv and asked for a pull request from kohsuke: https://github.com/kohsuke/msv/pull/5 Only copyright have not been updated to Oracle's, but I wanted to start to communicate on a pure technical level. I have asked kohsuke and the Oracle admin about Maven Central rights, but there is no answer so far. If anyone like to improve MSV (like adding sequence & choice evaluation for class generation), the MSV repository should be locally exchanged with my GitHub version. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (ODFTOOLKIT-455) Text document with "style:style" attribute cannot be parsed by odfdom
[
https://issues.apache.org/jira/browse/ODFTOOLKIT-455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svante Schubert resolved ODFTOOLKIT-455.
Resolution: Fixed
Assignee: Svante Schubert
Fix Version/s: 0.6.2-incubating
Thanks again, Bjorn!
I pushed the tested version to our TRUNC.
With your test patch only the build fails and with your test and fix patches
everything works splendid, building with "mvn clean install -Ppedantic"
> Text document with "style:style" attribute cannot be parsed by odfdom
> --
>
> Key: ODFTOOLKIT-455
> URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-455
> Project: ODF Toolkit
> Issue Type: Bug
> Components: odfdom
>Reporter: Bjoern Kirchhoff
>Assignee: Svante Schubert
> Fix For: 0.6.2-incubating
>
> Attachments: Example.odt, ODFTOOLKIT-455-Fix.patch,
> Test_document_with_stylestyle_attribute.patch
>
>
> A text document containing a "style:style" attribute for the element
> style:column-sep, cannot be parsed/loaded by OdfDom.
> style:height="100%" style:style="solid"/>
> This is the Excpetion thrown by odfdom-0.8.10:
> {quote}
> java.lang.ClassCastException:
> org.odftoolkit.odfdom.incubator.doc.style.OdfStyle cannot be cast to
> org.odftoolkit.odfdom.pkg.OdfAttribute
> at
> org.odftoolkit.odfdom.pkg.OdfXMLFactory.newOdfAttribute(OdfXMLFactory.java:256)
> at
> org.odftoolkit.odfdom.pkg.OdfFileDom.createAttributeNS(OdfFileDom.java:332)
> at
> org.odftoolkit.odfdom.pkg.OdfFileDom.createAttributeNS(OdfFileDom.java:322)
> at
> org.odftoolkit.odfdom.pkg.OdfFileSaxHandler.startElement(OdfFileSaxHandler.java:104)
> at
> org.odftoolkit.odfdom.pkg.rdfa.MultiContentHandler.startElement(MultiContentHandler.java:83)
> at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown
> Source)
> at
> org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown
> Source)
> at
> org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown
> Source)
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
> Source)
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
> Source)
> at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
> at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
> at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
> at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown
> Source)
> at org.odftoolkit.odfdom.pkg.OdfFileDom.initialize(OdfFileDom.java:223)
> at
> org.odftoolkit.odfdom.dom.OdfContentDom.initialize(OdfContentDom.java:60)
> at org.odftoolkit.odfdom.pkg.OdfFileDom.(OdfFileDom.java:105)
> at org.odftoolkit.odfdom.dom.OdfContentDom.(OdfContentDom.java:50)
> at org.odftoolkit.odfdom.pkg.OdfFileDom.newFileDom(OdfFileDom.java:157)
> at
> org.odftoolkit.odfdom.pkg.OdfPackageDocument.getFileDom(OdfPackageDocument.java:323)
> at
> org.odftoolkit.odfdom.dom.OdfSchemaDocument.getFileDom(OdfSchemaDocument.java:405)
> at
> org.odftoolkit.odfdom.dom.OdfSchemaDocument.getContentDom(OdfSchemaDocument.java:206)
> at org.odftoolkit.simple.Document.getContentRoot(Document.java:870)
> at
> org.odftoolkit.simple.TextDocument.getContentRoot(TextDocument.java:327)
> at
> org.odftoolkit.simple.TextDocument.getContentRoot(TextDocument.java:114)
> at
> de.eeconsultants.escriba.common.officecomponent.blockeditmode.TextBlockVariantUtil.main(TextBlockVariantUtil.java:593)
> {quote}
> The reason for this is, that OdfDom treats this attribute as an element
> inside the class OdfXMLFactory in the method called getOdfNodeClass.
> The line:
> {quote}
> if (mIncubatorElements.contains(qName))
> {quote}
> should look like this:
> {quote}
> if ( mIncubatorElements.contains(qName) &&
> nodeType.equals(ELEMENT_PACKAGE_NAME) )
> {quote}
> I will provide a patch and a testcase for that.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (ODFTOOLKIT-414) ClassCast: OdfStyle cannot be OdfAttribute on some (maybe new openoffice?)
[
https://issues.apache.org/jira/browse/ODFTOOLKIT-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svante Schubert closed ODFTOOLKIT-414.
--
Closing as duplicate
> ClassCast: OdfStyle cannot be OdfAttribute on some (maybe
> new openoffice?)
> -
>
> Key: ODFTOOLKIT-414
> URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-414
> Project: ODF Toolkit
> Issue Type: Bug
> Components: odfdom
>Affects Versions: 0.6.2-incubating
> Environment: any
>Reporter: Sanny Sanoff
>Assignee: Svante Schubert
> Labels: easyfix
>
> this part in content.xml causes the classcast:
> style:color="#00" style:height="100%" style:style="solid"/>
> this does not:
> style:color="#00" style:height="100%"/>
> Here is the source code (OdfXMLFactory.java):
> OdfAttribute attr = null;
> // lookup registered attribute class for qname
> Class attributeClass = getOdfAttributeClass(name);
> // if a class was registered create an instance of that class
> if (attributeClass != null) {
> // line 256:
> attr = (OdfAttribute) getNodeFromClass(dom,
> attributeClass);
> ^^^
> Here's the full stack trace:
> java.lang.ClassCastException:
> org.odftoolkit.odfdom.incubator.doc.style.OdfStyle cannot be cast to
> org.odftoolkit.odfdom.pkg.OdfAttribute
> at
> org.odftoolkit.odfdom.pkg.OdfXMLFactory.newOdfAttribute(OdfXMLFactory.java:256)
> at
> org.odftoolkit.odfdom.pkg.OdfFileDom.createAttributeNS(OdfFileDom.java:332)
> at
> org.odftoolkit.odfdom.pkg.OdfFileDom.createAttributeNS(OdfFileDom.java:322)
> at
> org.odftoolkit.odfdom.pkg.OdfFileSaxHandler.startElement(OdfFileSaxHandler.java:104)
> at
> org.odftoolkit.odfdom.pkg.rdfa.MultiContentHandler.startElement(MultiContentHandler.java:83)
> at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown
> Source)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (ODFTOOLKIT-414) ClassCast: OdfStyle cannot be OdfAttribute on some (maybe new openoffice?)
[
https://issues.apache.org/jira/browse/ODFTOOLKIT-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svante Schubert resolved ODFTOOLKIT-414.
Resolution: Fixed
Assignee: Svante Schubert
Thanks for the report, Sanny.
As Bjoern has provided a fix to 455, I will make this one the duplicate and
push the other fix.
> ClassCast: OdfStyle cannot be OdfAttribute on some (maybe
> new openoffice?)
> -
>
> Key: ODFTOOLKIT-414
> URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-414
> Project: ODF Toolkit
> Issue Type: Bug
> Components: odfdom
>Affects Versions: 0.6.2-incubating
> Environment: any
>Reporter: Sanny Sanoff
>Assignee: Svante Schubert
> Labels: easyfix
>
> this part in content.xml causes the classcast:
> style:color="#00" style:height="100%" style:style="solid"/>
> this does not:
> style:color="#00" style:height="100%"/>
> Here is the source code (OdfXMLFactory.java):
> OdfAttribute attr = null;
> // lookup registered attribute class for qname
> Class attributeClass = getOdfAttributeClass(name);
> // if a class was registered create an instance of that class
> if (attributeClass != null) {
> // line 256:
> attr = (OdfAttribute) getNodeFromClass(dom,
> attributeClass);
> ^^^
> Here's the full stack trace:
> java.lang.ClassCastException:
> org.odftoolkit.odfdom.incubator.doc.style.OdfStyle cannot be cast to
> org.odftoolkit.odfdom.pkg.OdfAttribute
> at
> org.odftoolkit.odfdom.pkg.OdfXMLFactory.newOdfAttribute(OdfXMLFactory.java:256)
> at
> org.odftoolkit.odfdom.pkg.OdfFileDom.createAttributeNS(OdfFileDom.java:332)
> at
> org.odftoolkit.odfdom.pkg.OdfFileDom.createAttributeNS(OdfFileDom.java:322)
> at
> org.odftoolkit.odfdom.pkg.OdfFileSaxHandler.startElement(OdfFileSaxHandler.java:104)
> at
> org.odftoolkit.odfdom.pkg.rdfa.MultiContentHandler.startElement(MultiContentHandler.java:83)
> at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown
> Source)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (ODFTOOLKIT-455) Text document with "style:style" attribute cannot be parsed by odfdom
[
https://issues.apache.org/jira/browse/ODFTOOLKIT-455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16055567#comment-16055567
]
Svante Schubert commented on ODFTOOLKIT-455:
Many thanks for your patch, Bjoern! :D
I have reviewed it and after a while the fix became obvious, do only look for
cached element classes from the incubator package, if it is an ODF element :)
Before 1.0 we should think about dropping the "incubator" package naming anyway.
Just wanted to be certain that still our typed ODF attribute classes are being
used..
During review, I have added a comment
// Ignore looking for XML namespace attributes or ODF elements without prefix,
as there are no typed ODF classes
// (NOTE: For any ODF node from the schema the ODF prefix would ALWAYS exist as
there is a prefix normalization during previous loading)
and added a parameter for the isAttribute boolean, as it only depends on the
two calling methods, I found it more intuitive for myself :)
I had problems with SVN patches adding files previously myself. So I have taken
the Example.odt from the JIRA usse and exchanged it with the empty
odfdom/src/test/resources/TestStyleStyleAttribute.odt within the test patch.
( I think we should move from Subversion to GIT sooner or later, better sooner)
The test doc - as you know - contained the attribute style:style, which is
named like the ODF element
> Text document with "style:style" attribute cannot be parsed by odfdom
> --
>
> Key: ODFTOOLKIT-455
> URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-455
> Project: ODF Toolkit
> Issue Type: Bug
> Components: odfdom
>Reporter: Bjoern Kirchhoff
> Attachments: Example.odt, ODFTOOLKIT-455-Fix.patch,
> Test_document_with_stylestyle_attribute.patch
>
>
> A text document containing a "style:style" attribute for the element
> style:column-sep, cannot be parsed/loaded by OdfDom.
> style:height="100%" style:style="solid"/>
> This is the Excpetion thrown by odfdom-0.8.10:
> {quote}
> java.lang.ClassCastException:
> org.odftoolkit.odfdom.incubator.doc.style.OdfStyle cannot be cast to
> org.odftoolkit.odfdom.pkg.OdfAttribute
> at
> org.odftoolkit.odfdom.pkg.OdfXMLFactory.newOdfAttribute(OdfXMLFactory.java:256)
> at
> org.odftoolkit.odfdom.pkg.OdfFileDom.createAttributeNS(OdfFileDom.java:332)
> at
> org.odftoolkit.odfdom.pkg.OdfFileDom.createAttributeNS(OdfFileDom.java:322)
> at
> org.odftoolkit.odfdom.pkg.OdfFileSaxHandler.startElement(OdfFileSaxHandler.java:104)
> at
> org.odftoolkit.odfdom.pkg.rdfa.MultiContentHandler.startElement(MultiContentHandler.java:83)
> at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown
> Source)
> at
> org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown
> Source)
> at
> org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown
> Source)
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
> Source)
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
> Source)
> at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
> at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
> at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
> at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown
> Source)
> at org.odftoolkit.odfdom.pkg.OdfFileDom.initialize(OdfFileDom.java:223)
> at
> org.odftoolkit.odfdom.dom.OdfContentDom.initialize(OdfContentDom.java:60)
> at org.odftoolkit.odfdom.pkg.OdfFileDom.(OdfFileDom.java:105)
> at org.odftoolkit.odfdom.dom.OdfContentDom.(OdfContentDom.java:50)
> at org.odftoolkit.odfdom.pkg.OdfFileDom.newFileDom(OdfFileDom.java:157)
> at
> org.odftoolkit.odfdom.pkg.OdfPackageDocument.getFileDom(OdfPackageDocument.java:323)
> at
> org.odftoolkit.odfdom.dom.OdfSchemaDocument.getFileDom(OdfSchemaDocument.java:405)
> at
> org.odftoolkit.odfdom.dom.OdfSchemaDocument.getContentDom(OdfSchemaDocument.java:206)
> at org.odftoolkit.simple.Document.getContentRoot(Document.java:870)
> at
> org.odftoolkit.simple.TextDocument.getContentRoot(TextDocument.java:327)
> at
> org.odftoolkit.simple.TextDocument.getContentRoot(TextDocument.java:114)
> at
> de.eeconsultants.escriba.common.officecomponent.blockeditmode.TextBlockVariantUtil.main(TextBlockVariantUtil.java:593)
> {quote}
> The reason for this is, that OdfDom treats this attribute as an element
> inside the class OdfXMLFactory in the method called getOdfNodeClass.
> The line:
>
[jira] [Updated] (ODFTOOLKIT-456) Missing support for getting active sheet in Spreadsheets
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Svante Schubert updated ODFTOOLKIT-456: --- Attachment: ActiveSpreadsheetTest.ods Spreadsheet with 5 sheets, the middle one is active and named as well active. Its name can be found within settings.xml If it is not found (other implementation than LibreOffice should be tested) a default value should be taken as the name is not yet in the ODF Standard. > Missing support for getting active sheet in Spreadsheets > > > Key: ODFTOOLKIT-456 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-456 > Project: ODF Toolkit > Issue Type: New Feature > Components: simple api >Reporter: Siddharth Prasad > Attachments: ActiveSpreadsheetTest.ods > > > POI has the feature to be able to get the active sheet index of any > spreadsheet file. But since POI doesn't work with .ods files, I have to use > ODFToolkit. But this feature is missing. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (ODFTOOLKIT-456) Missing support for getting active sheet in Spreadsheets
[
https://issues.apache.org/jira/browse/ODFTOOLKIT-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16055340#comment-16055340
]
Svante Schubert commented on ODFTOOLKIT-456:
@Siddarth Prasad
Bjoern is right, the function is not yet implemented as nobody desired it
earlier, but you may easily add it.
I would suggest you add to
org.odftoolkit.simple.SpreadsheetDocument
a function called:
public Table getActiveSheet() {,,,}
which calls internally public Table getTableByName(String name) using the name
found in settings.xml
XPATH something similar to:
/office:document-settings/office:settings/config:config-item-set/config:config-item-map-indexed/config:config-item-map-entry/config:config-item[@config:name='ActiveTable']
if you need any further help, just ping. :)
(I will attach a test document)
> Missing support for getting active sheet in Spreadsheets
>
>
> Key: ODFTOOLKIT-456
> URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-456
> Project: ODF Toolkit
> Issue Type: New Feature
> Components: simple api
>Reporter: Siddharth Prasad
>
> POI has the feature to be able to get the active sheet index of any
> spreadsheet file. But since POI doesn't work with .ods files, I have to use
> ODFToolkit. But this feature is missing.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (ODFTOOLKIT-454) Split table & merge table
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16055302#comment-16055302 ] Svante Schubert commented on ODFTOOLKIT-454: lijian what kind of help you require to implement it? What would be your design you would do, if you would have this task on your desk? PS: Do you like to implement it for Text and Spreadsheet? Any table within ODF documents? > Split table & merge table > - > > Key: ODFTOOLKIT-454 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-454 > Project: ODF Toolkit > Issue Type: New Feature >Reporter: lijian > > I do not find any implementation for *split or merge a table* so far. Can > some one help to implement? Thank you. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (ODFTOOLKIT-453) Create a temp directory for temp test documents
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Svante Schubert resolved ODFTOOLKIT-453. Resolution: Fixed Assignee: Svante Schubert Fix Version/s: 0.6.2-incubating Very nice idea to move the temporary directory into the build tree: simple/target/test-classes/ respectively odfdom/target/test-classes/ Works nice I have added similar cases you omitted for ODFDOM as well. pushed changes to trunk Thank you, Ian! Svante > Create a temp directory for temp test documents > --- > > Key: ODFTOOLKIT-453 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-453 > Project: ODF Toolkit > Issue Type: Improvement > Components: simple api >Reporter: Ian Cunningham >Assignee: Svante Schubert >Priority: Minor > Fix For: 0.6.2-incubating > > Attachments: tempDocuments.patch > > > When the JUint tests are run, temporary documents are created in the default > temp directory, They are not cleaned up. > The attached patch creates a temp directory under the test-classes directory > where the other test documents are created. > The temp documents may then be cleaned up via a mvn clean. > At the moment this is done only for the simple-api. I'll look at the other > projects later. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ODFTOOLKIT-452) Text document concatenation with errorneous list numbering
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Svante Schubert updated ODFTOOLKIT-452: --- Summary: Text document concatenation with errorneous list numbering (was: Insert Document) > Text document concatenation with errorneous list numbering > -- > > Key: ODFTOOLKIT-452 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-452 > Project: ODF Toolkit > Issue Type: Bug > Components: simple api >Affects Versions: 0.6.2-incubating >Reporter: Giuseppe Miniello > Attachments: template.odt, TestOdfToolkit.java, test.odt, > tmp08610502224696135458.odt > > > I'm using ODF Toolkit for manipulate odt documents, when i try to insert an > odt with numbered list into another odt but the result is wrong. > The final document loses the correct numbering. > The example is "TestOdfToolkit.java", the base document is "template.odt" and > the document that i try to insert is "tmp08610502224696135458.odt". > The result doc "test.odt" loses the correct numbering. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ODFTOOLKIT-452) Text document concatenation with errorneous list numbering
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Svante Schubert updated ODFTOOLKIT-452: --- Affects Version/s: 0.6.2-incubating > Text document concatenation with errorneous list numbering > -- > > Key: ODFTOOLKIT-452 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-452 > Project: ODF Toolkit > Issue Type: Bug > Components: simple api >Affects Versions: 0.6.2-incubating >Reporter: Giuseppe Miniello > Attachments: template.odt, TestOdfToolkit.java, test.odt, > tmp08610502224696135458.odt > > > I'm using ODF Toolkit for manipulate odt documents, when i try to insert an > odt with numbered list into another odt but the result is wrong. > The final document loses the correct numbering. > The example is "TestOdfToolkit.java", the base document is "template.odt" and > the document that i try to insert is "tmp08610502224696135458.odt". > The result doc "test.odt" loses the correct numbering. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ODFTOOLKIT-452) Text document concatenation with errorneous list numbering
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Svante Schubert updated ODFTOOLKIT-452: --- Component/s: simple api > Text document concatenation with errorneous list numbering > -- > > Key: ODFTOOLKIT-452 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-452 > Project: ODF Toolkit > Issue Type: Bug > Components: simple api >Affects Versions: 0.6.2-incubating >Reporter: Giuseppe Miniello > Attachments: template.odt, TestOdfToolkit.java, test.odt, > tmp08610502224696135458.odt > > > I'm using ODF Toolkit for manipulate odt documents, when i try to insert an > odt with numbered list into another odt but the result is wrong. > The final document loses the correct numbering. > The example is "TestOdfToolkit.java", the base document is "template.odt" and > the document that i try to insert is "tmp08610502224696135458.odt". > The result doc "test.odt" loses the correct numbering. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ODFTOOLKIT-452) Insert Document
[
https://issues.apache.org/jira/browse/ODFTOOLKIT-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16015897#comment-16015897
]
Svante Schubert commented on ODFTOOLKIT-452:
I quickly looked into it.
First of all, to make the problem easy reproducable the extension of a text is
most appropriate. For instance, your example only works on Windows due to your
file names.
To extend a test, take a look which library you are using, for instance, you
are using the SIMPLE library, therefore the following file might work:
org.odftoolkit.simple.text.ParagraphTest
A test might look like:
@Test
public void testList() {
try {
TextDocument doc =
TextDocument.loadDocument(ResourceUtilities.getAbsolutePath("templateForBase.odt"));
TextDocument doc4insertion =
TextDocument.loadDocument(ResourceUtilities.getAbsolutePath("templateForInsertion.odt"));
Paragraph paragraph = doc.addParagraph("");
doc.insertContentFromDocumentBefore(doc4insertion, paragraph, true);
doc.save(ResourceUtilities.newTestOutputFile("embeddedListOutput.odt"));
} catch (Exception e) {
LOGGER.log(Level.SEVERE, e.getMessage(), e);
Assert.fail();
}
}
Your input files would have to be placed on the path simple/src/test/resources
The output file would be found after testing at simple/target/test-classes
I can reproduce your problem and would guess it is a problem of styles being
used.
It is not really an embedded document, as an embedded document would receive a
new directory and can keep all the files.
Instead, it is inserted somewhere and the existing styles are all renamed.
Unfortunately, even similar styles receive different names.
Even further unfortunate, the IBM developers, who wrote this functionality have
left the project and are no longer maintaining the source code, neither do I. I
focus on the odfdom part.
The idea is to concatenate various ODT document, the problem what are you doing
with different styles?
I suggest you give it a try to fix yourself or ask for someone (or hire
someone) who might do this for you.
Good luck,
Svante
> Insert Document
> ---
>
> Key: ODFTOOLKIT-452
> URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-452
> Project: ODF Toolkit
> Issue Type: Bug
>Reporter: Giuseppe Miniello
> Attachments: template.odt, TestOdfToolkit.java, test.odt,
> tmp08610502224696135458.odt
>
>
> I'm using ODF Toolkit for manipulate odt documents, when i try to insert an
> odt with numbered list into another odt but the result is wrong.
> The final document loses the correct numbering.
> The example is "TestOdfToolkit.java", the base document is "template.odt" and
> the document that i try to insert is "tmp08610502224696135458.odt".
> The result doc "test.odt" loses the correct numbering.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (ODFTOOLKIT-435) the call of TextSelection.createSpanElement() adds invalide line-breaks
[
https://issues.apache.org/jira/browse/ODFTOOLKIT-435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svante Schubert closed ODFTOOLKIT-435.
--
All tests running, so pushed to TRUNC.
> the call of TextSelection.createSpanElement() adds invalide line-breaks
> ---
>
> Key: ODFTOOLKIT-435
> URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-435
> Project: ODF Toolkit
> Issue Type: Bug
> Components: simple api
>Reporter: Georg Füchsle
>Assignee: Svante Schubert
> Fix For: 0.6.2-incubating
>
> Attachments: SpanTest.diff, TextSelection.diff
>
>
> The call of TextSelection.createSpanElement() adds invalide line-breaks to
> the father paragraph if the paragraph has line-breaks included.
> For example:
> We use a Paragraph "para" that correspondes to following xml:
> {{before
> lbafter lb}}
>{{Paragraph para = ...}}
>{{TextSelection tSel = TextSelection.newTextSelection(null,}}
> {{para.getTextContent().replaceAll("\r\n","\n"),}}
> {{para.getOdfElement(), 0);}}
> {{TextSpanElement tspan = tSel.createSpanElement();}}
> After the call " tSel.createSpanElement()" the text is wrapped into a span
> but the span is followed by an additional line-break:
> {{before
> lbafter
> lb{color:red}{color}}}
> In our opinion the reason is in the function:
> {{private void TextSection.delete(int fromIndex, int leftLength, Node
> pNode)}}
> Here the text is deleted from the paragraph but the line-breaks will remain.
> After the call of delete() the text is reentered into the new span. In this
> way the line-break exits twice: Once inside the span once after the span.
> I attach a path-file including a JUnit test (SpanTest.testCreateSpanElement)
> that demonstrates this behavior.
> The path also includes a manipulated function
> {{TextSelection.createSpanElementInclLineBreak()}}
> that itself calls again a manipulated function
> {{TextSelection.deleteInclLineBreak(int fromIndex, int leftLength, Node
> pNode)}}
> instead of TextSelection.delete (...). With this function the test will
> succeed.
> What I do not have in track:
> 1. May the function delete(...) be replaced in everey circumstances?
> 2. Should also other tags than 'line-break' be considered as well? (for
> example 'tab') ?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (ODFTOOLKIT-435) the call of TextSelection.createSpanElement() adds invalide line-breaks
[
https://issues.apache.org/jira/browse/ODFTOOLKIT-435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svante Schubert updated ODFTOOLKIT-435:
---
Fix Version/s: 0.6.2-incubating
> the call of TextSelection.createSpanElement() adds invalide line-breaks
> ---
>
> Key: ODFTOOLKIT-435
> URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-435
> Project: ODF Toolkit
> Issue Type: Bug
> Components: simple api
>Reporter: Georg Füchsle
>Assignee: Svante Schubert
> Fix For: 0.6.2-incubating
>
> Attachments: SpanTest.diff, TextSelection.diff
>
>
> The call of TextSelection.createSpanElement() adds invalide line-breaks to
> the father paragraph if the paragraph has line-breaks included.
> For example:
> We use a Paragraph "para" that correspondes to following xml:
> {{before
> lbafter lb}}
>{{Paragraph para = ...}}
>{{TextSelection tSel = TextSelection.newTextSelection(null,}}
> {{para.getTextContent().replaceAll("\r\n","\n"),}}
> {{para.getOdfElement(), 0);}}
> {{TextSpanElement tspan = tSel.createSpanElement();}}
> After the call " tSel.createSpanElement()" the text is wrapped into a span
> but the span is followed by an additional line-break:
> {{before
> lbafter
> lb{color:red}{color}}}
> In our opinion the reason is in the function:
> {{private void TextSection.delete(int fromIndex, int leftLength, Node
> pNode)}}
> Here the text is deleted from the paragraph but the line-breaks will remain.
> After the call of delete() the text is reentered into the new span. In this
> way the line-break exits twice: Once inside the span once after the span.
> I attach a path-file including a JUnit test (SpanTest.testCreateSpanElement)
> that demonstrates this behavior.
> The path also includes a manipulated function
> {{TextSelection.createSpanElementInclLineBreak()}}
> that itself calls again a manipulated function
> {{TextSelection.deleteInclLineBreak(int fromIndex, int leftLength, Node
> pNode)}}
> instead of TextSelection.delete (...). With this function the test will
> succeed.
> What I do not have in track:
> 1. May the function delete(...) be replaced in everey circumstances?
> 2. Should also other tags than 'line-break' be considered as well? (for
> example 'tab') ?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (ODFTOOLKIT-435) the call of TextSelection.createSpanElement() adds invalide line-breaks
[
https://issues.apache.org/jira/browse/ODFTOOLKIT-435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svante Schubert resolved ODFTOOLKIT-435.
Resolution: Fixed
Hello Georg,
many thanks for your patch, I have reviewed it:
The test shows the issue and the patch is resolving it nicely.
I have removed your previous patch from the JIRA issue,
Thank you very much,
Svante
> the call of TextSelection.createSpanElement() adds invalide line-breaks
> ---
>
> Key: ODFTOOLKIT-435
> URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-435
> Project: ODF Toolkit
> Issue Type: Bug
> Components: simple api
>Reporter: Georg Füchsle
>Assignee: Svante Schubert
> Fix For: 0.6.2-incubating
>
> Attachments: SpanTest.diff, TextSelection.diff
>
>
> The call of TextSelection.createSpanElement() adds invalide line-breaks to
> the father paragraph if the paragraph has line-breaks included.
> For example:
> We use a Paragraph "para" that correspondes to following xml:
> {{before
> lbafter lb}}
>{{Paragraph para = ...}}
>{{TextSelection tSel = TextSelection.newTextSelection(null,}}
> {{para.getTextContent().replaceAll("\r\n","\n"),}}
> {{para.getOdfElement(), 0);}}
> {{TextSpanElement tspan = tSel.createSpanElement();}}
> After the call " tSel.createSpanElement()" the text is wrapped into a span
> but the span is followed by an additional line-break:
> {{before
> lbafter
> lb{color:red}{color}}}
> In our opinion the reason is in the function:
> {{private void TextSection.delete(int fromIndex, int leftLength, Node
> pNode)}}
> Here the text is deleted from the paragraph but the line-breaks will remain.
> After the call of delete() the text is reentered into the new span. In this
> way the line-break exits twice: Once inside the span once after the span.
> I attach a path-file including a JUnit test (SpanTest.testCreateSpanElement)
> that demonstrates this behavior.
> The path also includes a manipulated function
> {{TextSelection.createSpanElementInclLineBreak()}}
> that itself calls again a manipulated function
> {{TextSelection.deleteInclLineBreak(int fromIndex, int leftLength, Node
> pNode)}}
> instead of TextSelection.delete (...). With this function the test will
> succeed.
> What I do not have in track:
> 1. May the function delete(...) be replaced in everey circumstances?
> 2. Should also other tags than 'line-break' be considered as well? (for
> example 'tab') ?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (ODFTOOLKIT-435) the call of TextSelection.createSpanElement() adds invalide line-breaks
[
https://issues.apache.org/jira/browse/ODFTOOLKIT-435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svante Schubert updated ODFTOOLKIT-435:
---
Attachment: (was: linebreaksInCreateTextSpan.diff)
> the call of TextSelection.createSpanElement() adds invalide line-breaks
> ---
>
> Key: ODFTOOLKIT-435
> URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-435
> Project: ODF Toolkit
> Issue Type: Bug
> Components: simple api
>Reporter: Georg Füchsle
>Assignee: Svante Schubert
> Attachments: SpanTest.diff, TextSelection.diff
>
>
> The call of TextSelection.createSpanElement() adds invalide line-breaks to
> the father paragraph if the paragraph has line-breaks included.
> For example:
> We use a Paragraph "para" that correspondes to following xml:
> {{before
> lbafter lb}}
>{{Paragraph para = ...}}
>{{TextSelection tSel = TextSelection.newTextSelection(null,}}
> {{para.getTextContent().replaceAll("\r\n","\n"),}}
> {{para.getOdfElement(), 0);}}
> {{TextSpanElement tspan = tSel.createSpanElement();}}
> After the call " tSel.createSpanElement()" the text is wrapped into a span
> but the span is followed by an additional line-break:
> {{before
> lbafter
> lb{color:red}{color}}}
> In our opinion the reason is in the function:
> {{private void TextSection.delete(int fromIndex, int leftLength, Node
> pNode)}}
> Here the text is deleted from the paragraph but the line-breaks will remain.
> After the call of delete() the text is reentered into the new span. In this
> way the line-break exits twice: Once inside the span once after the span.
> I attach a path-file including a JUnit test (SpanTest.testCreateSpanElement)
> that demonstrates this behavior.
> The path also includes a manipulated function
> {{TextSelection.createSpanElementInclLineBreak()}}
> that itself calls again a manipulated function
> {{TextSelection.deleteInclLineBreak(int fromIndex, int leftLength, Node
> pNode)}}
> instead of TextSelection.delete (...). With this function the test will
> succeed.
> What I do not have in track:
> 1. May the function delete(...) be replaced in everey circumstances?
> 2. Should also other tags than 'line-break' be considered as well? (for
> example 'tab') ?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (ODFTOOLKIT-448) Upgrade Java version to JDK 8
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Svante Schubert resolved ODFTOOLKIT-448. Resolution: Fixed Fix Version/s: 0.7-incubating fixed on 0.7 > Upgrade Java version to JDK 8 > - > > Key: ODFTOOLKIT-448 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-448 > Project: ODF Toolkit > Issue Type: Improvement > Components: java >Affects Versions: 0.6.2-incubating >Reporter: Svante Schubert >Assignee: Svante Schubert >Priority: Minor > Fix For: 0.7-incubating > > > To allow the usage of latest JENA libraries, latest develpment features and > ease build processing we are going to upgrade to JDK 6 after the 0.6.2 > release. > Starting with 0.7.0 SNAPSHOT release. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Reopened] (ODFTOOLKIT-448) Upgrade Java version to JDK 8
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Svante Schubert reopened ODFTOOLKIT-448: forgot to set the attribute fixed on 0.7 > Upgrade Java version to JDK 8 > - > > Key: ODFTOOLKIT-448 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-448 > Project: ODF Toolkit > Issue Type: Improvement > Components: java >Affects Versions: 0.6.2-incubating >Reporter: Svante Schubert >Assignee: Svante Schubert >Priority: Minor > Fix For: 0.7-incubating > > > To allow the usage of latest JENA libraries, latest develpment features and > ease build processing we are going to upgrade to JDK 6 after the 0.6.2 > release. > Starting with 0.7.0 SNAPSHOT release. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (ODFTOOLKIT-448) Upgrade Java version to JDK 8
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Svante Schubert resolved ODFTOOLKIT-448. Resolution: Fixed Updated to JDK 8 > Upgrade Java version to JDK 8 > - > > Key: ODFTOOLKIT-448 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-448 > Project: ODF Toolkit > Issue Type: Improvement > Components: java >Affects Versions: 0.6.2-incubating >Reporter: Svante Schubert >Assignee: Svante Schubert >Priority: Minor > > To allow the usage of latest JENA libraries, latest develpment features and > ease build processing we are going to upgrade to JDK 6 after the 0.6.2 > release. > Starting with 0.7.0 SNAPSHOT release. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (ODFTOOLKIT-439) Java base line: Change to JDK 6 for next release
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Svante Schubert resolved ODFTOOLKIT-439. Resolution: Implemented We just finished the last release with JDK6, closing this one > Java base line: Change to JDK 6 for next release > > > Key: ODFTOOLKIT-439 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-439 > Project: ODF Toolkit > Issue Type: Improvement > Components: source >Reporter: Svante Schubert >Assignee: Svante Schubert >Priority: Minor > > For the upcoming release, I have changed the compiler dependencies from JDK 5 > to JDK 6 and rolled back the Jena library to 2.11.2 the last one using JDK 6. > Right after the release I suggest to switch directly to JDK 8 using the > latest Jena library. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (ODFTOOLKIT-439) Java base line: Change to JDK 6 for next release
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Svante Schubert closed ODFTOOLKIT-439. -- We just finished the last release with JDK6, closing this one > Java base line: Change to JDK 6 for next release > > > Key: ODFTOOLKIT-439 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-439 > Project: ODF Toolkit > Issue Type: Improvement > Components: source >Reporter: Svante Schubert >Assignee: Svante Schubert >Priority: Minor > > For the upcoming release, I have changed the compiler dependencies from JDK 5 > to JDK 6 and rolled back the Jena library to 2.11.2 the last one using JDK 6. > Right after the release I suggest to switch directly to JDK 8 using the > latest Jena library. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ODFTOOLKIT-450) Evaluate feed-back from our latest release
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15964061#comment-15964061 ] Svante Schubert commented on ODFTOOLKIT-450: There were two further emails on the comments above: http://mail-archives.apache.org/mod_mbox/incubator-general/201704.mbox/%3CCAAS6=7j=ajx6jjuqxhh87ox9tgrufx0guazplxi3hdn5sg8...@mail.gmail.com%3E http://mail-archives.apache.org/mod_mbox/incubator-general/201704.mbox/%3c58ec13af.4070...@apache.org%3E > Evaluate feed-back from our latest release > -- > > Key: ODFTOOLKIT-450 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-450 > Project: ODF Toolkit > Issue Type: Task >Affects Versions: 0.6.2-incubating >Reporter: Svante Schubert >Assignee: Svante Schubert > > From the vote for our latest release on gene...@incubator.apache.org we > received feedback that needs to be evaluated, work into issues and be fixed. > This task is about the evaluation and creation of follow-up issues. > The first mail was from Justin Mclean, see > http://mail-archives.apache.org/mod_mbox/incubator-general/201704.mbox/%3CB59A698B-E1AD-4A25-A774-CB9D98E18AD4%40classsoftware.com%3E > The second mail was from Josh Elser, see > http://mail-archives.apache.org/mod_mbox/incubator-general/201704.mbox/%3C58EAB861.2010706%40apache.org%3E -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (ODFTOOLKIT-450) Evaluate feed-back from our latest release
Svante Schubert created ODFTOOLKIT-450: -- Summary: Evaluate feed-back from our latest release Key: ODFTOOLKIT-450 URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-450 Project: ODF Toolkit Issue Type: Task Affects Versions: 0.6.2-incubating Reporter: Svante Schubert Assignee: Svante Schubert >From the vote for our latest release on gene...@incubator.apache.org we >received feedback that needs to be evaluated, work into issues and be fixed. This task is about the evaluation and creation of follow-up issues. The first mail was from Justin Mclean, see http://mail-archives.apache.org/mod_mbox/incubator-general/201704.mbox/%3CB59A698B-E1AD-4A25-A774-CB9D98E18AD4%40classsoftware.com%3E The second mail was from Josh Elser, see http://mail-archives.apache.org/mod_mbox/incubator-general/201704.mbox/%3C58EAB861.2010706%40apache.org%3E -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ODFTOOLKIT-38) DOCUMENTATION: ODF 1.2 - XML reference
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15945683#comment-15945683 ] Svante Schubert commented on ODFTOOLKIT-38: --- There is already an HTML version of a subset of the ODF RelaxNG schema that is being created as part of a test: /generator/schema2template/target/OdfReference.html Unfortunately, there is no implementation of SEQUENCE and CHOICE. In addition, some nodes have number suffix, which is a bit disturbing and need further investigation. Finally, the usage of an image for the CHOICE symbol like in some XML tools would help usability. If some of the above is fixed, sub tasks might be created. > DOCUMENTATION: ODF 1.2 - XML reference > -- > > Key: ODFTOOLKIT-38 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-38 > Project: ODF Toolkit > Issue Type: Improvement > Components: codegen >Affects Versions: simple-odfdom-0.8 > Environment: Operating System: All > Platform: All >Reporter: Svante Schubert >Assignee: Svante Schubert >Priority: Minor > > We already have a prototype of an attribute/element ODF XML reference in > XHTML from Christian Lippka, based on the first community draft 02: > http://odftoolkit.org/downloads/odfdom/OpenDocument-v1.2-draft/OdfReference.html > @Hans-Peter: > As discussed on phone could you assist Christian Lippka to integrate the > sources of the creation of that tool and improve it a little more? > - Svante -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ODFTOOLKIT-422) PERFORMANCE ISSUE: 'format load', 'put data' & (!) "APPEND SHEET" (!)
[
https://issues.apache.org/jira/browse/ODFTOOLKIT-422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15926120#comment-15926120
]
Svante Schubert commented on ODFTOOLKIT-422:
I have not included your patch in the upcoming JDK 6 based release, as with
JDK8 there are further JDK tools for profiling available and I did not wanted
to open pandoras box before not having the right tools at hand. Especially,
when release processing took most of my time.
PS: In any case sorry for the delay in response, had been a stormy time for me,
when you dispatched this issue, but I am back..
> PERFORMANCE ISSUE: 'format load', 'put data' & (!) "APPEND SHEET" (!)
> --
>
> Key: ODFTOOLKIT-422
> URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-422
> Project: ODF Toolkit
> Issue Type: Bug
> Components: performance
>Affects Versions: 0.6.2-incubating
> Environment: Windows & Linux
>Reporter: Kakha Kheladze
>Assignee: Svante Schubert
> Labels: performance
> Attachments: odftoolkit-performance-test.zip
>
>
> Dear Sir,
> We are using ODFTOOLKIT for 3 main functions:
> 1. "Format Load" - Loading format into spreadsheet
> 2. "Put Data" - population table into spreadsheet , it could be table with
> 5,000 rows and 20 columns.
> 3. "Append Sheet" - Appending several sheets and assembling workbook. (up to
> 150 sheets)
> We have a serious issue with performance, these 3 steps for 150 sheets with
> 5000x20 dimension may take more then 1h.
> See some code below.
> Any help or idea will be highly appreciated.
> Kakha
> ---
> @Override
> public void setCellValue(int colIndex, int rowIndex, double value) {
> try {
> Cell cell = currentSheet.getCellByPosition(colIndex, rowIndex);
> String valueType = cell.getValueType();
> if (valueType != null) {
> switch (valueType) {
> case "percentage":
> cell.setPercentageValue(value);
> break;
> default:
> cell.setDoubleValue(value);
> }
> } else {
> cell.setDoubleValue(value);
> }
> } catch (Throwable t) {
> log.error(t.getMessage(), t);
> }
> }
>
>
>
> -
>try (ByteArrayInputStream in = new ByteArrayInputStream(content)) {
> spreadsheetDocument = SpreadsheetDocument.loadDocument(in);
> }
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ODFTOOLKIT-403) ODF decryption errors
[
https://issues.apache.org/jira/browse/ODFTOOLKIT-403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15926035#comment-15926035
]
Svante Schubert commented on ODFTOOLKIT-403:
Hi Damjan,
sorry for the long delay, work occupied me and obvious others. I am back at the
ODF Toolkit and would love to have a regression test. Afterwards, I would work
myself into your further questions.
At the beginning of the week, I fixed the ordering of two encryption related
elements in the manifest.xml so the ODF document is valid again.
Thanks for your help so far and again my apologies for the long absense (the
latter part one year parental absence!)
Svante
> ODF decryption errors
> -
>
> Key: ODFTOOLKIT-403
> URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-403
> Project: ODF Toolkit
> Issue Type: Bug
> Components: odfdom
>Reporter: Damjan Jovanovic
> Attachments: decryption.patch
>
>
> Patching my way through ODFTOOLKIT-401 and ODFTOOLKIT-402, I now get one of
> these errors when it come to decrypting the file:
> {quote}
> Aug 02, 2015 10:51:12 AM org.odftoolkit.odfdom.pkg.OdfPackage decryptData
> SEVERE: null
> java.security.InvalidAlgorithmParameterException: Wrong IV length: must be 8
> bytes long
> at com.sun.crypto.provider.CipherCore.init(CipherCore.java:430)
> at
> com.sun.crypto.provider.BlowfishCipher.engineInit(BlowfishCipher.java:222)
> at javax.crypto.Cipher.implInit(Cipher.java:796)
> at javax.crypto.Cipher.chooseProvider(Cipher.java:854)
> at javax.crypto.Cipher.init(Cipher.java:1374)
> at javax.crypto.Cipher.init(Cipher.java:1308)
> at
> org.odftoolkit.odfdom.pkg.OdfPackage.decryptData(OdfPackage.java:1897)
> at org.odftoolkit.odfdom.pkg.OdfPackage.getBytes(OdfPackage.java:1729)
> at
> org.odftoolkit.odfdom.pkg.OdfPackage.getInputStream(OdfPackage.java:2018)
> at org.odftoolkit.odfdom.pkg.OdfFileDom.initialize(OdfFileDom.java:210)
> at
> org.odftoolkit.odfdom.dom.OdfContentDom.initialize(OdfContentDom.java:60)
> at org.odftoolkit.odfdom.pkg.OdfFileDom.(OdfFileDom.java:105)
> at org.odftoolkit.odfdom.dom.OdfContentDom.(OdfContentDom.java:50)
> at org.odftoolkit.odfdom.pkg.OdfFileDom.newFileDom(OdfFileDom.java:157)
> at
> org.odftoolkit.odfdom.pkg.OdfPackageDocument.getFileDom(OdfPackageDocument.java:323)
> at
> org.odftoolkit.odfdom.dom.OdfSchemaDocument.getFileDom(OdfSchemaDocument.java:405)
> at
> org.odftoolkit.odfdom.dom.OdfSchemaDocument.getContentDom(OdfSchemaDocument.java:206)
> at org.odftoolkit.simple.Document.getContentRoot(Document.java:870)
> at
> org.odftoolkit.simple.TextDocument.getContentRoot(TextDocument.java:327)
> at
> org.odftoolkit.simple.TextDocument.getContentRoot(TextDocument.java:114)
> at local.Main.main(Main.java:22)
> Exception in thread "main" java.lang.NullPointerException
> at org.odftoolkit.simple.Document.getContentRoot(Document.java:872)
> at
> org.odftoolkit.simple.TextDocument.getContentRoot(TextDocument.java:327)
> at
> org.odftoolkit.simple.TextDocument.getContentRoot(TextDocument.java:114)
> at local.Main.main(Main.java:22)
> {quote}
> or this one (when the password is wrong):
> {quote}
> Aug 02, 2015 10:56:21 AM org.odftoolkit.odfdom.pkg.OdfPackage decryptData
> SEVERE: null
> org.odftoolkit.odfdom.pkg.OdfDecryptedException: The given password is wrong,
> please check it.
> at
> org.odftoolkit.odfdom.pkg.OdfPackage.decryptData(OdfPackage.java:1914)
> at org.odftoolkit.odfdom.pkg.OdfPackage.getBytes(OdfPackage.java:1729)
> at
> org.odftoolkit.odfdom.pkg.OdfPackage.getInputStream(OdfPackage.java:2018)
> at org.odftoolkit.odfdom.pkg.OdfFileDom.initialize(OdfFileDom.java:210)
> at
> org.odftoolkit.odfdom.dom.OdfContentDom.initialize(OdfContentDom.java:60)
> at org.odftoolkit.odfdom.pkg.OdfFileDom.(OdfFileDom.java:105)
> at org.odftoolkit.odfdom.dom.OdfContentDom.(OdfContentDom.java:50)
> at org.odftoolkit.odfdom.pkg.OdfFileDom.newFileDom(OdfFileDom.java:157)
> at
> org.odftoolkit.odfdom.pkg.OdfPackageDocument.getFileDom(OdfPackageDocument.java:323)
> at
> org.odftoolkit.odfdom.dom.OdfSchemaDocument.getFileDom(OdfSchemaDocument.java:405)
> at
> org.odftoolkit.odfdom.dom.OdfSchemaDocument.getContentDom(OdfSchemaDocument.java:206)
> at org.odftoolkit.simple.Document.getContentRoot(Document.java:870)
> at
> org.odftoolkit.simple.TextDocument.getContentRoot(TextDocument.java:327)
> at
> org.odftoolkit.simple.TextDocument.getContentRoot(TextDocument.java:114)
> at local.Main.main(Main.java:22)
> Exception in thread "main" java.lang.NullPointerException
> at org.odftoolkit.simple.Document.getContentRoot(Document.java:872)
>
[jira] [Resolved] (ODFTOOLKIT-375) odftoolkit-0.6 does not work in my environment
[
https://issues.apache.org/jira/browse/ODFTOOLKIT-375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svante Schubert resolved ODFTOOLKIT-375.
Resolution: Workaround
Try a new version as 0.6.1 or there is a release coming soon for JDK 6.
For infos of the release candidate, see
http://mail-archives.apache.org/mod_mbox/incubator-odf-dev/201703.mbox/%3CCAHNbw8%3DojgmkGyucCByEVzUV%3DCnJF6TVvMEPESLCyQTi-VLn_w%40mail.gmail.com%3E
> odftoolkit-0.6 does not work in my environment
> --
>
> Key: ODFTOOLKIT-375
> URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-375
> Project: ODF Toolkit
> Issue Type: Bug
> Components: odfdom, simple api, xslt-runner, xslt-runner-task
>Affects Versions: 0.6-incubating
> Environment: Java 1.6, Windows 7, 64 bits
>Reporter: Guzman Rejon
>Assignee: Svante Schubert
> Labels: Error
>
> I'm doing a program to read/modify metadata of ODF documents, the program
> works correctly with version odftoolkit-0.5 but not with odftoolkit-0.6
> version, running the first line jumps to the finally block directly without
> giving any kind of error, this is my code:
> try {
>doc = (TextDocument) TextDocument.loadDocument(new
> File("OdfTextDocument.odt"));
>OdfFileDom metadom = doc.getMetaDom();
>Meta metadata = new Meta(metadom);
>...
> } finally {
>if(doc != null)
> doc.close();
> }
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (ODFTOOLKIT-375) odftoolkit-0.6 does not work in my environment
[
https://issues.apache.org/jira/browse/ODFTOOLKIT-375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svante Schubert closed ODFTOOLKIT-375.
--
closing issue as there is a valid work around
> odftoolkit-0.6 does not work in my environment
> --
>
> Key: ODFTOOLKIT-375
> URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-375
> Project: ODF Toolkit
> Issue Type: Bug
> Components: odfdom, simple api, xslt-runner, xslt-runner-task
>Affects Versions: 0.6-incubating
> Environment: Java 1.6, Windows 7, 64 bits
>Reporter: Guzman Rejon
>Assignee: Svante Schubert
> Labels: Error
> Fix For: 0.6.2-incubating
>
>
> I'm doing a program to read/modify metadata of ODF documents, the program
> works correctly with version odftoolkit-0.5 but not with odftoolkit-0.6
> version, running the first line jumps to the finally block directly without
> giving any kind of error, this is my code:
> try {
>doc = (TextDocument) TextDocument.loadDocument(new
> File("OdfTextDocument.odt"));
>OdfFileDom metadom = doc.getMetaDom();
>Meta metadata = new Meta(metadom);
>...
> } finally {
>if(doc != null)
> doc.close();
> }
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (ODFTOOLKIT-375) odftoolkit-0.6 does not work in my environment
[
https://issues.apache.org/jira/browse/ODFTOOLKIT-375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svante Schubert updated ODFTOOLKIT-375:
---
Fix Version/s: 0.6.2-incubating
> odftoolkit-0.6 does not work in my environment
> --
>
> Key: ODFTOOLKIT-375
> URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-375
> Project: ODF Toolkit
> Issue Type: Bug
> Components: odfdom, simple api, xslt-runner, xslt-runner-task
>Affects Versions: 0.6-incubating
> Environment: Java 1.6, Windows 7, 64 bits
>Reporter: Guzman Rejon
>Assignee: Svante Schubert
> Labels: Error
> Fix For: 0.6.2-incubating
>
>
> I'm doing a program to read/modify metadata of ODF documents, the program
> works correctly with version odftoolkit-0.5 but not with odftoolkit-0.6
> version, running the first line jumps to the finally block directly without
> giving any kind of error, this is my code:
> try {
>doc = (TextDocument) TextDocument.loadDocument(new
> File("OdfTextDocument.odt"));
>OdfFileDom metadom = doc.getMetaDom();
>Meta metadata = new Meta(metadom);
>...
> } finally {
>if(doc != null)
> doc.close();
> }
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (ODFTOOLKIT-375) odftoolkit-0.6 does not work in my environment
[
https://issues.apache.org/jira/browse/ODFTOOLKIT-375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svante Schubert reassigned ODFTOOLKIT-375:
--
Assignee: Svante Schubert
> odftoolkit-0.6 does not work in my environment
> --
>
> Key: ODFTOOLKIT-375
> URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-375
> Project: ODF Toolkit
> Issue Type: Bug
> Components: odfdom, simple api, xslt-runner, xslt-runner-task
>Affects Versions: 0.6-incubating
> Environment: Java 1.6, Windows 7, 64 bits
>Reporter: Guzman Rejon
>Assignee: Svante Schubert
> Labels: Error
>
> I'm doing a program to read/modify metadata of ODF documents, the program
> works correctly with version odftoolkit-0.5 but not with odftoolkit-0.6
> version, running the first line jumps to the finally block directly without
> giving any kind of error, this is my code:
> try {
>doc = (TextDocument) TextDocument.loadDocument(new
> File("OdfTextDocument.odt"));
>OdfFileDom metadom = doc.getMetaDom();
>Meta metadata = new Meta(metadom);
>...
> } finally {
>if(doc != null)
> doc.close();
> }
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (ODFTOOLKIT-304) Update ODF 1.2 schema to OpenDocument-v1.2 final version
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Svante Schubert closed ODFTOOLKIT-304. -- all work done -> closed > Update ODF 1.2 schema to OpenDocument-v1.2 final version > > > Key: ODFTOOLKIT-304 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-304 > Project: ODF Toolkit > Issue Type: Improvement > Components: odfdom >Affects Versions: odfdom-0.8.8 >Reporter: Devin Han >Assignee: Svante Schubert > Labels: ODF1.2 > Fix For: 0.6.2-incubating > > > The final ODF 1.2 schemas were published last month, see: > http://lists.oasis-open.org/archives/tc-announce/201201/msg1.html > And we just updated the code generator to support mainfest and data dignature > element/attribute in issue ODFTOOLKIT-199. > So I think it is time to update to the newest schemas for ODFDOM. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (ODFTOOLKIT-304) Update ODF 1.2 schema to OpenDocument-v1.2 final version
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Svante Schubert resolved ODFTOOLKIT-304. Resolution: Fixed Assignee: Svante Schubert (was: Devin Han) Looking through the issues, I realized that I have fixed this one long ago... > Update ODF 1.2 schema to OpenDocument-v1.2 final version > > > Key: ODFTOOLKIT-304 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-304 > Project: ODF Toolkit > Issue Type: Improvement > Components: odfdom >Affects Versions: odfdom-0.8.8 >Reporter: Devin Han >Assignee: Svante Schubert > Labels: ODF1.2 > Fix For: 0.6.2-incubating > > > The final ODF 1.2 schemas were published last month, see: > http://lists.oasis-open.org/archives/tc-announce/201201/msg1.html > And we just updated the code generator to support mainfest and data dignature > element/attribute in issue ODFTOOLKIT-199. > So I think it is time to update to the newest schemas for ODFDOM. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ODFTOOLKIT-304) Update ODF 1.2 schema to OpenDocument-v1.2 final version
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Svante Schubert updated ODFTOOLKIT-304: --- Fix Version/s: 0.6.2-incubating > Update ODF 1.2 schema to OpenDocument-v1.2 final version > > > Key: ODFTOOLKIT-304 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-304 > Project: ODF Toolkit > Issue Type: Improvement > Components: odfdom >Affects Versions: odfdom-0.8.8 >Reporter: Devin Han >Assignee: Devin Han > Labels: ODF1.2 > Fix For: 0.6.2-incubating > > > The final ODF 1.2 schemas were published last month, see: > http://lists.oasis-open.org/archives/tc-announce/201201/msg1.html > And we just updated the code generator to support mainfest and data dignature > element/attribute in issue ODFTOOLKIT-199. > So I think it is time to update to the newest schemas for ODFDOM. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ODFTOOLKIT-397) DataSet cannot set values from spreadsheet if there are repeated rows before data rows
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Svante Schubert updated ODFTOOLKIT-397: --- Fix Version/s: (was: 0.6.2-incubating) > DataSet cannot set values from spreadsheet if there are repeated rows before > data rows > -- > > Key: ODFTOOLKIT-397 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-397 > Project: ODF Toolkit > Issue Type: Bug > Components: simple api >Affects Versions: 0.6.1-incubating >Reporter: Stefan Szpikowski >Assignee: Svante Schubert > Labels: easyfix, patch, test > Attachments: ODFTOOLKIT-397-patch.txt > > > setValues method of DataSet produces exception when sheet table contains > repeated-row in form > > before rows with data. > Currently code assumes each row has it's own element whitch is not true and > cannot get proper element from NodeList. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (ODFTOOLKIT-367) Paragraph.getTextContent sometimes failed to replace text:s with spaces
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Svante Schubert closed ODFTOOLKIT-367. -- fixed in upcoming release > Paragraph.getTextContent sometimes failed to replace text:s with spaces > --- > > Key: ODFTOOLKIT-367 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-367 > Project: ODF Toolkit > Issue Type: Bug > Components: simple api >Reporter: Alain Fagot Béarez >Assignee: Svante Schubert >Priority: Critical > Fix For: 0.6.2-incubating > > > When the paragraph has exactly 2 spaces between words, the underlying markup > has a element with no attribute. > The current implementation reads the number of spaces from the c attribute, > which is set only for values greater than 1. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ODFTOOLKIT-367) Paragraph.getTextContent sometimes failed to replace text:s with spaces
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Svante Schubert updated ODFTOOLKIT-367: --- Summary: Paragraph.getTextContent sometimes failed to replace text:s with spaces (was: Paragraph.getTextContent throws NullPointerException with exactly 2 spaces between words) > Paragraph.getTextContent sometimes failed to replace text:s with spaces > --- > > Key: ODFTOOLKIT-367 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-367 > Project: ODF Toolkit > Issue Type: Bug > Components: simple api >Reporter: Alain Fagot Béarez >Assignee: Svante Schubert >Priority: Critical > Fix For: 0.6.2-incubating > > > When the paragraph has exactly 2 spaces between words, the underlying markup > has a element with no attribute. > The current implementation reads the number of spaces from the c attribute, > which is set only for values greater than 1. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ODFTOOLKIT-367) Paragraph.getTextContent throws NullPointerException with exactly 2 spaces between words
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Svante Schubert updated ODFTOOLKIT-367: --- Fix Version/s: 0.6.2-incubating > Paragraph.getTextContent throws NullPointerException with exactly 2 spaces > between words > > > Key: ODFTOOLKIT-367 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-367 > Project: ODF Toolkit > Issue Type: Bug > Components: simple api >Reporter: Alain Fagot Béarez >Assignee: Svante Schubert >Priority: Critical > Fix For: 0.6.2-incubating > > > When the paragraph has exactly 2 spaces between words, the underlying markup > has a element with no attribute. > The current implementation reads the number of spaces from the c attribute, > which is set only for values greater than 1. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (ODFTOOLKIT-447) Encrypted documents invalid due to misordered manifest XML elements
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Svante Schubert closed ODFTOOLKIT-447. -- closing issue for upcoming release > Encrypted documents invalid due to misordered manifest XML elements > --- > > Key: ODFTOOLKIT-447 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-447 > Project: ODF Toolkit > Issue Type: Bug > Components: odfdom >Reporter: Svante Schubert >Assignee: Svante Schubert > Fix For: 0.6.2-incubating > > > Currently an encyrpted file entry in the manifest.xml looks like: > manifest:media-type="text/xml" manifest:size="2823"> >manifest:checksum="mIDl6gHPgZTfq24AolQzqe60s88=" > manifest:checksum-type="SHA1/1K"> >manifest:initialisation-vector="uBM1fdR60k4="/> >manifest:key-derivation-name="PBKDF2" > manifest:salt="FVyq8eGe1o5Pz80P9ZEAAw=="/> >manifest:start-key-generation-name="SHA1"/> > > > The package manifest schema reads like: > > > > > > > > > > > see > http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-manifest-schema.rng > The latter two child elements of have to be > switched. > Validated using the ODF online validator > http://odf-validator.rhcloud.com/ > based on our ODF validator project. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ODFTOOLKIT-447) Encrypted documents invalid due to misordered manifest XML elements
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Svante Schubert updated ODFTOOLKIT-447: --- Fix Version/s: 0.6.2-incubating > Encrypted documents invalid due to misordered manifest XML elements > --- > > Key: ODFTOOLKIT-447 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-447 > Project: ODF Toolkit > Issue Type: Bug > Components: odfdom >Reporter: Svante Schubert >Assignee: Svante Schubert > Fix For: 0.6.2-incubating > > > Currently an encyrpted file entry in the manifest.xml looks like: > manifest:media-type="text/xml" manifest:size="2823"> >manifest:checksum="mIDl6gHPgZTfq24AolQzqe60s88=" > manifest:checksum-type="SHA1/1K"> >manifest:initialisation-vector="uBM1fdR60k4="/> >manifest:key-derivation-name="PBKDF2" > manifest:salt="FVyq8eGe1o5Pz80P9ZEAAw=="/> >manifest:start-key-generation-name="SHA1"/> > > > The package manifest schema reads like: > > > > > > > > > > > see > http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-manifest-schema.rng > The latter two child elements of have to be > switched. > Validated using the ODF online validator > http://odf-validator.rhcloud.com/ > based on our ODF validator project. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Reopened] (ODFTOOLKIT-447) Encrypted documents invalid due to misordered manifest XML elements
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Svante Schubert reopened ODFTOOLKIT-447: opening issue, as again the fixed version is not set.. :/ > Encrypted documents invalid due to misordered manifest XML elements > --- > > Key: ODFTOOLKIT-447 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-447 > Project: ODF Toolkit > Issue Type: Bug > Components: odfdom >Reporter: Svante Schubert >Assignee: Svante Schubert > Fix For: 0.6.2-incubating > > > Currently an encyrpted file entry in the manifest.xml looks like: > manifest:media-type="text/xml" manifest:size="2823"> >manifest:checksum="mIDl6gHPgZTfq24AolQzqe60s88=" > manifest:checksum-type="SHA1/1K"> >manifest:initialisation-vector="uBM1fdR60k4="/> >manifest:key-derivation-name="PBKDF2" > manifest:salt="FVyq8eGe1o5Pz80P9ZEAAw=="/> >manifest:start-key-generation-name="SHA1"/> > > > The package manifest schema reads like: > > > > > > > > > > > see > http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-manifest-schema.rng > The latter two child elements of have to be > switched. > Validated using the ODF online validator > http://odf-validator.rhcloud.com/ > based on our ODF validator project. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (ODFTOOLKIT-447) Encrypted documents invalid due to misordered manifest XML elements
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Svante Schubert resolved ODFTOOLKIT-447. Resolution: Fixed > Encrypted documents invalid due to misordered manifest XML elements > --- > > Key: ODFTOOLKIT-447 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-447 > Project: ODF Toolkit > Issue Type: Bug > Components: odfdom >Reporter: Svante Schubert >Assignee: Svante Schubert > Fix For: 0.6.2-incubating > > > Currently an encyrpted file entry in the manifest.xml looks like: > manifest:media-type="text/xml" manifest:size="2823"> >manifest:checksum="mIDl6gHPgZTfq24AolQzqe60s88=" > manifest:checksum-type="SHA1/1K"> >manifest:initialisation-vector="uBM1fdR60k4="/> >manifest:key-derivation-name="PBKDF2" > manifest:salt="FVyq8eGe1o5Pz80P9ZEAAw=="/> >manifest:start-key-generation-name="SHA1"/> > > > The package manifest schema reads like: > > > > > > > > > > > see > http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-manifest-schema.rng > The latter two child elements of have to be > switched. > Validated using the ODF online validator > http://odf-validator.rhcloud.com/ > based on our ODF validator project. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (ODFTOOLKIT-200) Enable password encryption and encryption manifest handling to ODFDOM
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Svante Schubert closed ODFTOOLKIT-200. -- closed for upcoming release > Enable password encryption and encryption manifest handling to ODFDOM > - > > Key: ODFTOOLKIT-200 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-200 > Project: ODF Toolkit > Issue Type: Improvement > Components: java >Affects Versions: odfdom-0.8.8 > Environment: Operating System: All > Platform: All >Reporter: devin >Assignee: Svante Schubert >Priority: Critical > Fix For: 0.6.2-incubating > > Attachments: ASF.LICENSE.NOT.GRANTED--bug351.patch, > ASF.LICENSE.NOT.GRANTED--bug352-20110728.patch > > > Create this issue to track the process of ODFDOM security feature. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (ODFTOOLKIT-200) Enable password encryption and encryption manifest handling to ODFDOM
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Svante Schubert resolved ODFTOOLKIT-200. Resolution: Fixed Renamed issue as signature support was split off this issue later. > Enable password encryption and encryption manifest handling to ODFDOM > - > > Key: ODFTOOLKIT-200 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-200 > Project: ODF Toolkit > Issue Type: Improvement > Components: java >Affects Versions: odfdom-0.8.8 > Environment: Operating System: All > Platform: All >Reporter: devin >Assignee: Svante Schubert >Priority: Critical > Fix For: 0.6.2-incubating > > Attachments: ASF.LICENSE.NOT.GRANTED--bug351.patch, > ASF.LICENSE.NOT.GRANTED--bug352-20110728.patch > > > Create this issue to track the process of ODFDOM security feature. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ODFTOOLKIT-200) Enable password encryption and encryption manifest handling to ODFDOM
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Svante Schubert updated ODFTOOLKIT-200: --- Summary: Enable password encryption and encryption manifest handling to ODFDOM (was: Supply signature and manifest features to ODFDOM) > Enable password encryption and encryption manifest handling to ODFDOM > - > > Key: ODFTOOLKIT-200 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-200 > Project: ODF Toolkit > Issue Type: Improvement > Components: java >Affects Versions: odfdom-0.8.8 > Environment: Operating System: All > Platform: All >Reporter: devin >Assignee: Svante Schubert >Priority: Critical > Fix For: 0.6.2-incubating > > Attachments: ASF.LICENSE.NOT.GRANTED--bug351.patch, > ASF.LICENSE.NOT.GRANTED--bug352-20110728.patch > > > Create this issue to track the process of ODFDOM security feature. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Reopened] (ODFTOOLKIT-200) Supply signature and manifest features to ODFDOM
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Svante Schubert reopened ODFTOOLKIT-200: Reopen issue to rename misleading title > Supply signature and manifest features to ODFDOM > > > Key: ODFTOOLKIT-200 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-200 > Project: ODF Toolkit > Issue Type: Improvement > Components: java >Affects Versions: odfdom-0.8.8 > Environment: Operating System: All > Platform: All >Reporter: devin >Assignee: Svante Schubert >Priority: Critical > Fix For: 0.6.2-incubating > > Attachments: ASF.LICENSE.NOT.GRANTED--bug351.patch, > ASF.LICENSE.NOT.GRANTED--bug352-20110728.patch > > > Create this issue to track the process of ODFDOM security feature. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (ODFTOOLKIT-447) Encrypted documents invalid due to misordered manifest XML elements
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Svante Schubert closed ODFTOOLKIT-447. -- closed for upcoming release > Encrypted documents invalid due to misordered manifest XML elements > --- > > Key: ODFTOOLKIT-447 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-447 > Project: ODF Toolkit > Issue Type: Bug > Components: odfdom >Reporter: Svante Schubert >Assignee: Svante Schubert > > Currently an encyrpted file entry in the manifest.xml looks like: > manifest:media-type="text/xml" manifest:size="2823"> >manifest:checksum="mIDl6gHPgZTfq24AolQzqe60s88=" > manifest:checksum-type="SHA1/1K"> >manifest:initialisation-vector="uBM1fdR60k4="/> >manifest:key-derivation-name="PBKDF2" > manifest:salt="FVyq8eGe1o5Pz80P9ZEAAw=="/> >manifest:start-key-generation-name="SHA1"/> > > > The package manifest schema reads like: > > > > > > > > > > > see > http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-manifest-schema.rng > The latter two child elements of have to be > switched. > Validated using the ODF online validator > http://odf-validator.rhcloud.com/ > based on our ODF validator project. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (ODFTOOLKIT-447) Encrypted documents invalid due to misordered manifest XML elements
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Svante Schubert resolved ODFTOOLKIT-447. Resolution: Fixed Fixed XML ordering in manifest.xml for upcoming release (including typo in validator) > Encrypted documents invalid due to misordered manifest XML elements > --- > > Key: ODFTOOLKIT-447 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-447 > Project: ODF Toolkit > Issue Type: Bug > Components: odfdom >Reporter: Svante Schubert >Assignee: Svante Schubert > > Currently an encyrpted file entry in the manifest.xml looks like: > manifest:media-type="text/xml" manifest:size="2823"> >manifest:checksum="mIDl6gHPgZTfq24AolQzqe60s88=" > manifest:checksum-type="SHA1/1K"> >manifest:initialisation-vector="uBM1fdR60k4="/> >manifest:key-derivation-name="PBKDF2" > manifest:salt="FVyq8eGe1o5Pz80P9ZEAAw=="/> >manifest:start-key-generation-name="SHA1"/> > > > The package manifest schema reads like: > > > > > > > > > > > see > http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-manifest-schema.rng > The latter two child elements of have to be > switched. > Validated using the ODF online validator > http://odf-validator.rhcloud.com/ > based on our ODF validator project. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (ODFTOOLKIT-447) Encrypted documents invalid due to misordered manifest XML elements
Svante Schubert created ODFTOOLKIT-447: -- Summary: Encrypted documents invalid due to misordered manifest XML elements Key: ODFTOOLKIT-447 URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-447 Project: ODF Toolkit Issue Type: Bug Components: odfdom Reporter: Svante Schubert Assignee: Svante Schubert Currently an encyrpted file entry in the manifest.xml looks like: The package manifest schema reads like: see http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-manifest-schema.rng The latter two child elements of have to be switched. Validated using the ODF online validator http://odf-validator.rhcloud.com/ based on our ODF validator project. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (ODFTOOLKIT-446) Receiving encrypted file without password should be not NULL
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Svante Schubert closed ODFTOOLKIT-446. -- closing issue for upcoming release > Receiving encrypted file without password should be not NULL > > > Key: ODFTOOLKIT-446 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-446 > Project: ODF Toolkit > Issue Type: Bug > Components: odfdom >Affects Versions: 0.6.1-incubating >Reporter: Svante Schubert >Assignee: Svante Schubert >Priority: Minor > Fix For: 0.6.2-incubating > > > Receiving an encrypted file like the content.xml file without (or the wrong > password) currently returns NULL, but should be in fact the encrypted file to > be handled on will be user. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (ODFTOOLKIT-446) Receiving encrypted file without password should be not NULL
[ https://issues.apache.org/jira/browse/ODFTOOLKIT-446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Svante Schubert resolved ODFTOOLKIT-446. Resolution: Fixed Fix Version/s: 0.6.2-incubating Fixed for upcoming release.. Extended regression test PackageTest.testPackagePassword() to load a package with wrong and correct password. > Receiving encrypted file without password should be not NULL > > > Key: ODFTOOLKIT-446 > URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-446 > Project: ODF Toolkit > Issue Type: Bug > Components: odfdom >Affects Versions: 0.6.1-incubating >Reporter: Svante Schubert >Assignee: Svante Schubert >Priority: Minor > Fix For: 0.6.2-incubating > > > Receiving an encrypted file like the content.xml file without (or the wrong > password) currently returns NULL, but should be in fact the encrypted file to > be handled on will be user. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (ODFTOOLKIT-446) Receiving encrypted file without password should be not NULL
Svante Schubert created ODFTOOLKIT-446: -- Summary: Receiving encrypted file without password should be not NULL Key: ODFTOOLKIT-446 URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-446 Project: ODF Toolkit Issue Type: Bug Components: odfdom Affects Versions: 0.6.1-incubating Reporter: Svante Schubert Assignee: Svante Schubert Priority: Minor Receiving an encrypted file like the content.xml file without (or the wrong password) currently returns NULL, but should be in fact the encrypted file to be handled on will be user. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
