Thanks Dave. There are pros and cons to poi-ooxml-lite. I think most users could live with using poi-ooxml-full but we do get some users who seem to want to use POI with constrained memory. In theory, the best solution for those users would be to have tooling that produces a custom lite jar. For instance, if you just want to support Excel, you don't need the Word or Powerpoint classes. My gut feeling is that we should keep poi-ooxml-lite as is, at least for the time being. We could start by trying to make our build simpler and faster by making the poi-ooxml-full and poi-ooxml-lite builds optional. Something like my original proposal but there could be other ways to achieve this. Maybe we could change our Maven dependencies to default to poi-ooxml-full just to see what level of complaint we get from people who are affected by the change. poi-ooxml-lite would still be there for them to use, they would just need to modify their own builds to get that jar instead.
On Wed, 27 Aug 2025 at 20:34, Dave Fisher <w...@apache.org> wrote: > > Hi - > > > On Aug 27, 2025, at 9:47 AM, PJ Fanning <fannin...@apache.org> wrote: > > > > Hi everyone, > > poi-ooxml-full is made up of generated classes. XMLBeans is used to > > generate code based on many XML schemas. This doesn't change much. The > > code generation is slow and the compilation is slow. We are wasting > > developer time and machine time constantly rebuilding it. > > We used to ship this as an ooxml-schemas jar that had its own release > > cycle. I think it was a mistake to switch away from this. > > I propose this: > > * Create a new git repo for poi-ooxml-full build > > * We create a way to generate a source release for this repo > > (basically creating a tar.gz with the contents of the git repo at a > > point in time). > > * We release a poi-ooxml-full 5.5.0 source release and jar. > > * We base all poi 5.5.x releases on poi-ooxml-full 5.5.0 jar. > > * We end up with having separate votes for poi-ooxml-full releases > > (separate to the main POI ones). > > +1! > > > > > At some point in the future, we can discuss the possibilities around > > moving poi-ooxml-lite to the the poi-ooxml-full release schedule. This > > is also an expensive part of the POI build that doesn't need to be > > rerun so often. > > This would involve small tweaks to the existing poi build. > > * The poi-ooxml test run would publish a list of xsb and class files > > that we need (it basically does this already) > > * We can copy those list files to the poi-ooxml-full repo and its > > build is modified to also generate a pi-ooxml-lite jar with the subset > > of the poi-ooxml-full xsb and class files. > > It may be feasible to do this poi-ooxml-lite work before a first > > poi-ooxml-full release. > > It was at Apachecon NA 2009 Oakland when Jukka from Apache Tika approached > Nick, Yegor, and I while we were hacking on POI with an issue that POI’s > OOXML was great but a 13 MB jar was too big for Tika. Yegor created the OOXML > Lite approach which made for a much smaller JAR. > > The OOXML full jar is about 20 MB now and OOXML Lite is slightly smaller than > 10MB. In our modern world this difference in size is inconsequential. > > I think that we should stop producing the OOXML Lite. > > > > > What do people think? > > Great discussion! > > Best, > Dave > > > > > > Thanks, > > PJ > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > > For additional commands, e-mail: dev-h...@poi.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > For additional commands, e-mail: dev-h...@poi.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
