Hi, 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? Dominik. 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 > >
