Ask Questions and Find Answers

For the record, it is not always so easy to just copy someone else's solution...


These exclusions, well they just exclude the packages from being imported, but they do not address whether your code or more importantly whether POI is going to need them or not based upon the file that is being opened or created.

For example, I'm not sure what role BouncyCastle would play, but since BouncyCastle is related to encryption, it could be required if you are reading an encrypted sheet or writing an encrypted cell or something. I certainly don't know, but the point is that you'll need to know in order to decide if BouncyCastle needs to be included or whether the exclusion shown here will work.

And that's really the key for all of the transitive dependencies. Maybe they're needed, maybe they're not, but as the developer it will really be up to you to decide when they should be included or excluded. It's really the core of the issue why OSGi forces resolution even on optional packages, it just can't know whether the transitive dependencies will be required or not, and it expects that you, the developer, will have enough information to make the correct judgements.

I am using LIferay 7.3 and these are my dependencies

In bnd.bnd file

Include-Resource:\
    @poi-4.1.2.jar,\
    @poi-ooxml-4.1.2.jar,\
    @poi-ooxml-schemas-4.1.2.jar,\
    @commons-collections4-4.4.jar,\
    @commons-compress-1.19.jar,\
    @commons-lang3-3.9.jar,\
    @xmlbeans-3.1.0.jar
    
 Import-Package: \
    !com.sun.*,\
    !junit*,\
    !org.apache.avalon.framework.logger,\
    !org.apache.crimson.jaxp,\
    !org.apache.jcp.xml.dsig.internal.dom,\
    !org.apache.log,\
    !org.apache.xml.resolver*,\
    !org.bouncycastle.*,\
    !org.gjt.xpp,\
    !org.junit*,\
    !org.relaxng.datatype,\
    !org.xmlpull.v1,\
    !com.microsoft.schemas.office.*,\
    !com.zaxxer.sparsebits,\
    !org.apache.batik.*,\
    !com.graphbuilder*,\
    !org.etsi.uri.x01903.v14,\
    !org.openxmlformats.schemas.officeDocument.x2006.*,\
    !org.openxmlformats.schemas.schemaLibrary.x2006.main,\
    !net.sf.saxon.*,\
    !org.apache.commons.codec.binary,\
    !org.apache.commons.codec.digest,\
    !org.apache.commons.math3.*,\
    !com.github.luben.*,\
    !org.brotli.*,\
    !org.tukaani.xz,\
    *

And in gradle.properties

dependencies {
    compileOnly group: "com.liferay.portal", name: "release.dxp.api"

    cssBuilder group: "com.liferay", name: "com.liferay.css.builder", version: "3.0.2"
    
    compileOnly group: "com.liferay",name:"com.liferay.application.list.api"
    compileOnly group: "org.apache.poi", name: "poi"
    compileOnly group: "org.apache.poi", name: "poi-ooxml"
    compileOnly group: "org.apache.poi", name: "poi-ooxml-schemas"
    compileOnly group: "org.apache.xmlbeans", name: "xmlbeans"
    compileOnly group: "org.apache.commons", name: "commons-collections4"    
    compileOnly group: "org.apache.commons", name: "commons-lang3"
    compileOnly group: "org.apache.commons", name: "commons-compress"
    compile project(":modules:common:vendor:vendor-api")
    compile project(":modules:common:product:product-api")
    
    compileOnly group: 'jakarta.mail', name: 'jakarta.mail-api', version: '1.6.6'
    
}

 

This works fine for me :)

    

I feel like there has to be a better solution for using POI in OSGI portlets.  I'm attempting to use it in JSF Thin Portlets and it's been a nightmare.