IDEMPIERE-6117:POI: WorkbookFactory.create cannot be used to open XLS…

[hieplq]

IDEMPIERE-6117

Pull Request Checklist

• My code follows the code guidelines of this project
• My code follows the best practices of this project
• I have performed a self-review of my own code
• My code is easy to understand and review.
• I have checked my code and corrected any misspellings
• In hard-to-understand areas, I have commented my code.
• My changes generate no new warnings

Tests

• I have tested the direct scenario that my code is solving
• I checked all collaterals that can be affected by my changes, and tested other potential affected scenarios
• New and existing unit tests pass locally with my changes
• I have added unit tests that prove my fix is effective or that my feature works

Documentation

• I have made corresponding changes to the documentation as follows:
• • New feature (non-breaking change which adds functionality): I have created the New Feature page in the project wiki explaining the functionality and how to use it. If relevant, I have committed sample data to the core seed to have usable examples in GardenWorld.
• • Breaking change (fix or feature that would cause existing functionality to not work as expected): I have documented the change in a clear way that everyone in the community can understand the impact of the change.
• • Improvement (improves and existing functionality): This documentation is needed if the improvement changes the way the user interacts with the system or the outcome of a process/task changes. If it is just, for instance, a performance improvement, documentation might not be needed.
• The changed/added documentation is in the project wiki (not privately-hosted pdf files or links pointing to a company website) and is complete and self-explanatory.

[hengsin]

this is unnecessary, just add the test xlsx to test project. it is just 1 file and I don't expect we need to make frequent update of it either.

[hieplq]

In addition to the XLSX file, I also have two JAR files for testing case updates and multi-version installation.

[hengsin]

The 2 jar files: but that's not what iDempiere core is using, we shouldn't add test here that's for your project work.

[hengsin]

Also, for multi version, AFAIU, if you don't limit the import version in MANIFEST.MF, the resolver should always resolve to the latest version.

[hieplq]

2 jar test for this condition (it's not my case)

1. hot server updates using update.sh and new release has update of POI
2. some one has plugin that require other version of POI

[hengsin]

The test above doesn't test anything for multi version of POI. You install a different version and unless your bundle specifically import only that version, the OSGi resolver will just resolve to the latest version install.

[hengsin]

The example at https://github.com/apache/poi/blob/trunk/osgi/src/main/java/org/apache/poi/osgi/Activator.java just add the provider in activator, why do we need to use bundle tracker here ?

[hieplq]

example for case merger POI and POI-OOXML into a single bundle

In Idempiere, I need the Bundle Tracker to ensure that both the wrapper bundle already resolved

[hengsin]

but that's not how it is configure in iDempiere core.

[hengsin]

Unless there's compelling reason for doing so, I would prefer the simple approach in the link example above and don't have to depends on hard coded bundle name check as well.

[hieplq]

I'd like a straightforward approach, similar to sample, but need to merged JARs for POI and POI-OOXML for deployment on the idempiere/binary.file

[hengsin]

If a plugin need a different version of POI, that should be managed in that plugin/bundle, it is not the core's responsibility to do that. Also, it is not alright for us to integrate something that we can't test properly.

[CarlosRuiz-globalqss]

replaced by #2357