Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change enums to match new Apache POI #142

Open
colearendt opened this issue Dec 25, 2019 · 2 comments
Open

Change enums to match new Apache POI #142

colearendt opened this issue Dec 25, 2019 · 2 comments

Comments

@colearendt
Copy link
Owner

There have been requests to bump the POI version to get access to (1) bug fixes and (2) new features (?). Unfortunately, a first pass at this suggested that there were many breaking changes to POI in how it handles enums. Where xlsx has integers (1,2,3,4) and passes those as-is, the new version of POI expects those values to be typed into enums.

This is not a "beginner" issue, so to speak, but one that should be pretty straightforward if you have the ability to monkey with Java enums at all 😄

Reference xlsxjars PR that this needs to integrate with: colearendt/xlsxjars#1

Discussed in #137

@mac471
Copy link

mac471 commented Jan 29, 2022

Instead of updating the existing xlsx package and potentially creating new problems for existing users, what about creating a "new" package (e.g., xlsx2) that has the same function bindings (where possible)? This way, you don't have to strictly worry about backward compatibility - whatever works today will still work. Whatever doesn't work because of the outdated POIs will still not work. No better, no worse for existing users.

But for users who want features that come with the new POI, they make the code switch to "xlsx2". Over time, new users will use xlsx2.

@colearendt
Copy link
Owner Author

colearendt commented Jan 29, 2022

Thanks for sending this! Your message was well timed 😄

In any case, I would love to avoid an xlsx2 if possible. The pain that comes from porting things in that way and the fracture it can create in the user base is best to be avoided if possible. I think things are designed sufficiently well that we can avoid too many painful changes with upgrading and tracing enums carefully. If you'd like to start giving my (very early) pass at fixing this a shot, I have the cell styles tests passing. (Admittedly, our test coverage is not great though)

remotes::install_github("colearendt/xlsxjars@bump-poi")
remotes::install_github("colearendt/xlsx@bump-poi")

Unfortunately, things have fallen into a bit of disrepair (I do not use this package hardly at all any more), so extra sets of eyes on testing / verifying would be much appreciated!

For instance, it looks like password protected workbooks are now broken b/c the underlying API has changed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants