poi-filter branch with initial OOXML/.xlsx export filter

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

poi-filter branch with initial OOXML/.xlsx export filter

Damjan Jovanovic
Hi

I've put together my previous work on an OOXML export filter for
spreadsheets, and pushed it into a branch called poi-filter.

So far it builds successfully, gets packaged, appears in the "Save" dialog,
loads, has all the right methods called, and gets to traversing and saving
the document, but fails with an exception because java.net.URLClassLoader
can't find the POI jars I jerryrigged.

To test:
1. Download poi-4.1.2.zip and extract it.
2. Copy all its jar files into $JAVA_HOME/jre/lib/ext as one flat directory
structure, eg. the jars in lib/ go into $JAVA_HOME/jre/lib/ext not
$JAVA_HOME/jre/lib/ext/lib. However, DON'T copy the junit jar, as it breaks
the build due to missing hamcrest. (Yes this is bad, but it's only
temporary.)
3. Build AOO as usual.
4. You should see a poi-filter.jar in
main/instsetoo_native/unxfbsdx/Apache_OpenOffice/installed/install/en-US/openoffice4/program/classes
:).
5. Start AOO.
6. Make a spreadsheet.
7. Type text and numbers.
8. Save, and choose "Microsoft Excel 2007 XML (.xlsx)"  :) :).
9. Click "Save" and confirm you don't want ODF.
10. It will error out but print log message to the console showing POI
wasn't found:

Asked to create org.apache.openoffice.poi.filter.ExcelFilter
Returning com.sun.star.lib.uno.helper.Factory@2b8a87fc
setSourceDocument()
filter!!!
Starting
java.lang.NoClassDefFoundError: org/apache/poi/xssf/streaming/SXSSFWorkbook
at org.apache.openoffice.poi.filter.ExcelFilter.filter(ExcelFilter.java:123)
Caused by: java.lang.ClassNotFoundException:
org.apache.poi.xssf.streaming.SXSSFWorkbook
at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:471)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:589)
at
java.base/java.net.FactoryURLClassLoader.loadClass(URLClassLoader.java:899)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
... 1 more

Once we correctly integrate POI into the build instead of using
$JAVA_HOME/jre/lib/ext, and it can be found, it should start writing
successfully (it did before). I tried making a fat jar with all the POI
jars and poi-filter.jar combined into one file, but that failed even
earlier.

How we integrate it into the build is an interesting question. All our
current external dependencies are downloaded as source, possibly patched,
and built ourselves. Building POI requires the whole of Gradle, which
usually needs Internet access to run. If we make an exception to that rule
and use the binaries directly, there are still 19 of them to deal with.
Maybe those who know POI better can help with this.

The code is in main/poi-filter. It's only a few hundred lines of Java at
this stage. It uses SXSSF already, and saves cells with strings and
numbers. I've cleaned it up to use the newer ComponentContext APIs instead
of ServiceManager, to use the new Java APIs for component registration,
etc. It's not clear to me whether we are integrating correctly, eg. I lie
we are also an import filter because otherwise we don't appear in the
"Save" dialog - write-only filters go to the File -> Export dialog instead.

A new filter, integrated overnight. Claims of our demise were greatly
exaggerated ;).
Damjan
Reply | Threaded
Open this post in threaded view
|

Re: poi-filter branch with initial OOXML/.xlsx export filter

Carl Marcum
Hi Damjan,

On 10/17/20 4:00 AM, Damjan Jovanovic wrote:

> Hi
>
> I've put together my previous work on an OOXML export filter for
> spreadsheets, and pushed it into a branch called poi-filter.
>
> So far it builds successfully, gets packaged, appears in the "Save" dialog,
> loads, has all the right methods called, and gets to traversing and saving
> the document, but fails with an exception because java.net.URLClassLoader
> can't find the POI jars I jerryrigged.
>
> To test:
> 1. Download poi-4.1.2.zip and extract it.
> 2. Copy all its jar files into $JAVA_HOME/jre/lib/ext as one flat directory
> structure, eg. the jars in lib/ go into $JAVA_HOME/jre/lib/ext not
> $JAVA_HOME/jre/lib/ext/lib. However, DON'T copy the junit jar, as it breaks
> the build due to missing hamcrest. (Yes this is bad, but it's only
> temporary.)
> 3. Build AOO as usual.
> 4. You should see a poi-filter.jar in
> main/instsetoo_native/unxfbsdx/Apache_OpenOffice/installed/install/en-US/openoffice4/program/classes
> :).
> 5. Start AOO.
> 6. Make a spreadsheet.
> 7. Type text and numbers.
> 8. Save, and choose "Microsoft Excel 2007 XML (.xlsx)"  :) :).
> 9. Click "Save" and confirm you don't want ODF.
> 10. It will error out but print log message to the console showing POI
> wasn't found:
>
> Asked to create org.apache.openoffice.poi.filter.ExcelFilter
> Returning com.sun.star.lib.uno.helper.Factory@2b8a87fc
> setSourceDocument()
> filter!!!
> Starting
> java.lang.NoClassDefFoundError: org/apache/poi/xssf/streaming/SXSSFWorkbook
> at org.apache.openoffice.poi.filter.ExcelFilter.filter(ExcelFilter.java:123)
> Caused by: java.lang.ClassNotFoundException:
> org.apache.poi.xssf.streaming.SXSSFWorkbook
> at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:471)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:589)
> at
> java.base/java.net.FactoryURLClassLoader.loadClass(URLClassLoader.java:899)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
> ... 1 more
>
> Once we correctly integrate POI into the build instead of using
> $JAVA_HOME/jre/lib/ext, and it can be found, it should start writing
> successfully (it did before). I tried making a fat jar with all the POI
> jars and poi-filter.jar combined into one file, but that failed even
> earlier.
>
> How we integrate it into the build is an interesting question. All our
> current external dependencies are downloaded as source, possibly patched,
> and built ourselves. Building POI requires the whole of Gradle, which
> usually needs Internet access to run. If we make an exception to that rule
> and use the binaries directly, there are still 19 of them to deal with.
> Maybe those who know POI better can help with this.
>
> The code is in main/poi-filter. It's only a few hundred lines of Java at
> this stage. It uses SXSSF already, and saves cells with strings and
> numbers. I've cleaned it up to use the newer ComponentContext APIs instead
> of ServiceManager, to use the new Java APIs for component registration,
> etc. It's not clear to me whether we are integrating correctly, eg. I lie
> we are also an import filter because otherwise we don't appear in the
> "Save" dialog - write-only filters go to the File -> Export dialog instead.
>
> A new filter, integrated overnight. Claims of our demise were greatly
> exaggerated ;).
> Damjan
>

Thanks a lot !
I'll check it out.

Best regards,
Carl


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: poi-filter branch with initial OOXML/.xlsx export filter

Dave Fisher-2
In reply to this post by Damjan Jovanovic


> On Oct 17, 2020, at 1:00 AM, Damjan Jovanovic <[hidden email]> wrote:
>
> Hi
>
> I've put together my previous work on an OOXML export filter for
> spreadsheets, and pushed it into a branch called poi-filter.
>
> So far it builds successfully, gets packaged, appears in the "Save" dialog,
> loads, has all the right methods called, and gets to traversing and saving
> the document, but fails with an exception because java.net.URLClassLoader
> can't find the POI jars I jerryrigged.
>
> To test:
> 1. Download poi-4.1.2.zip and extract it.
> 2. Copy all its jar files into $JAVA_HOME/jre/lib/ext as one flat directory
> structure, eg. the jars in lib/ go into $JAVA_HOME/jre/lib/ext not
> $JAVA_HOME/jre/lib/ext/lib. However, DON'T copy the junit jar, as it breaks
> the build due to missing hamcrest. (Yes this is bad, but it's only
> temporary.)
> 3. Build AOO as usual.
> 4. You should see a poi-filter.jar in
> main/instsetoo_native/unxfbsdx/Apache_OpenOffice/installed/install/en-US/openoffice4/program/classes
> :).
> 5. Start AOO.
> 6. Make a spreadsheet.
> 7. Type text and numbers.
> 8. Save, and choose "Microsoft Excel 2007 XML (.xlsx)"  :) :).
> 9. Click "Save" and confirm you don't want ODF.
> 10. It will error out but print log message to the console showing POI
> wasn't found:
>
> Asked to create org.apache.openoffice.poi.filter.ExcelFilter
> Returning com.sun.star.lib.uno.helper.Factory@2b8a87fc
> setSourceDocument()
> filter!!!
> Starting
> java.lang.NoClassDefFoundError: org/apache/poi/xssf/streaming/SXSSFWorkbook
> at org.apache.openoffice.poi.filter.ExcelFilter.filter(ExcelFilter.java:123)
> Caused by: java.lang.ClassNotFoundException:
> org.apache.poi.xssf.streaming.SXSSFWorkbook
> at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:471)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:589)
> at
> java.base/java.net.FactoryURLClassLoader.loadClass(URLClassLoader.java:899)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
> ... 1 more
>
> Once we correctly integrate POI into the build instead of using
> $JAVA_HOME/jre/lib/ext, and it can be found, it should start writing
> successfully (it did before). I tried making a fat jar with all the POI
> jars and poi-filter.jar combined into one file, but that failed even
> earlier.


>
> How we integrate it into the build is an interesting question. All our
> current external dependencies are downloaded as source, possibly patched,
> and built ourselves. Building POI requires the whole of Gradle, which
> usually needs Internet access to run. If we make an exception to that rule
> and use the binaries directly, there are still 19 of them to deal with.
> Maybe those who know POI better can help with this.

The trunk version of POI has a maven build for an OSGI bundle with an uber Jar.

http://svn.apache.org/viewvc?view=revision&revision=1881771


>
> The code is in main/poi-filter. It's only a few hundred lines of Java at
> this stage. It uses SXSSF already, and saves cells with strings and
> numbers. I've cleaned it up to use the newer ComponentContext APIs instead
> of ServiceManager, to use the new Java APIs for component registration,
> etc. It's not clear to me whether we are integrating correctly, eg. I lie
> we are also an import filter because otherwise we don't appear in the
> "Save" dialog - write-only filters go to the File -> Export dialog instead.
>
> A new filter, integrated overnight. Claims of our demise were greatly
> exaggerated ;).

+1000

Regards,
Dave

> Damjan


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]