Not with the current approach as far as I see. It injects a custom
classloader before running all unit-tests. This classloader records all
loaded classes from the -schemas jar and so it only can see classes which
are actually used during execution time, not compile time.

If type-erasure removes usage of a type completely it will be missing,
because POI itself will really not require the type as far as code tested
by unit-test is concerned.

One idea: Shouldn't we be able to at least find all such missing classes by
compiling POI itself including the tests without the full -schema jar, but
only with the reduced jar. Wouldn't then the compiler flag all these
classes as missing during compilation?


On Tue, Jul 10, 2018 at 6:46 PM, pj.fanning <fannin...@yahoo.com> wrote:

> I'm seeing some issues with poi-ooxml-schemas where it is missing inner
> classes that implement Lists.
> An example is this:
> java.lang.NoClassDefFoundError:
> org/openxmlformats/schemas/spreadsheetml/x2006/main/impl/
> CTSheetDataImpl$1RowList
>         at
> org.openxmlformats.schemas.spreadsheetml.x2006.main.impl.
> CTSheetDataImpl.getRowList(Unknown
> Source)
> Traditionally, we've tended to use CTSheetData#getRowArray() instead of
> CTSheetData#getRowList() but the former is deprecated.
> The problem appears to be that type erasure on the List<CTRow> that is
> returned by CTSheetData#getRowList() means that the OoxmlLite class does
> not
> necessarily recognise that we need the
> CTSheetDataImpl$1RowList class to be included in poi-ooxml-schemas.
> Would it be feasible to modify OoxmlLite to include all inner classes of
> any
> class it chooses to include in poi-ooxml-schemas?
> --
> Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
> For additional commands, e-mail: dev-h...@poi.apache.org

Reply via email to