In short: The hack is no long longer required. Since 6.6.1 POI can be used in a project without any library conflicts at runtime. ---------- **Axon.ivy 6.6.1 and younger** These kinds of JAR hell issues are gone from 6.6.1 upwards. In the **Designer** many libraries were removed from the Axon.ivy Classpath container. Practically this means that `Webservice Process (CXF)` and `Webservice Call (AXIS2)` libraries are no longer on the classpath of the project. And as xmlbeans is a dependency of CXF, the conflict with POI is gone. These old libraries can be added to classpath manually in the preferences, if anyone used them to patch AXIS stubs or by accident. http://developer.axonivy.com/doc/latest/DesignerGuideHtml/ivy.processmodeling.html#ivy.project.preferences.java The **Engine** is now also delivered as OSGI version. This means that the proper ClassLoader isolation per Bundle behaves as it does in the Designer. So a huge runtime behavior difference is gone since 6.6.1. The OSGI Engine will become the default version of the Engine. We do not plan to support the OS specific packages any longer due its classloading shortcomings. But for a short time we still release the alternative packages that can be used if you face migration issues. ---------- **Axon.ivy 6.5.0 and older** The ugly workaround is still required. - Designer: manually patch the JAR in the plugins directory. - Engine: rename the /lib/shared/xmlbeans_2.4.0.jar to somethink like xmlbeans_2.4.0.jar.deactivated

In short: The hack is no long required. Since 6.6.1 POI can be used in a project without any library conflicts at runtime. ---------- **Axon.ivy 6.6.1 and younger** These kinds of JAR hell issues are gone from 6.6.1 upwards. In the **Designer** many libraries which are not essentially required were removed from the Axon.ivy Classpath container. Practically this means that `Webservice Process (CXF)` and `Webservice Call (AXIS2)` libraries are no longer on the classpath of the project. And as xmlbeans is a dependency of CXF - CXF, the conflict with POI is gone. If anyone still needs the These old libraries as they were used to patch AXIS stubs or by accident. These libraries can be added to classpath manually in the preferences preferences, if anyone used them to patch AXIS stubs or by accident. http://developer.axonivy.com/doc/latest/DesignerGuideHtml/ivy.processmodeling.html#ivy.project.preferences.java The **Engine** is now also delivered as OSGI version. This means that the proper ClassLoader isolation per Bundle behaves as it does in the Designer. So a huge runtime behavior difference is gone since 6.6.1. The OSGI Engine will become the default version of the Engine. We do not plan to support the OS specific packages any longer due its classloading shortcomings. But for a short time we still release the alternative packages that can be used if you face migration issues. ---------- **Axon.ivy 6.5.0 and older** The ugly workaround is still required. - Designer: manually patch the JAR in the plugins directory. - Engine: rename the /lib/shared/xmlbeans_2.4.0.jar to somethink like xmlbeans_2.4.0.jar.deactivated

In short: The hack is no long required. Since 6.6.1 POI can be used in a project without any library conflicts at runtime. ---------- **Axon.ivy 6.6.1 and younger** These kinds of JAR hell issues are gone from 6.6.1 upwards. In the **Designer** many libraries which are not essentially required were removed from the Axon.ivy Classpath container. Practically this means that `Webservice Process (CXF)` and `Webservice Call (AXIS2)` libraries are no longer on the classpath of the project. And as xmlbeans is a dependency of CXF - the conflict with POI is gone. If anyone still needs the old libraries as they were used to patch AXIS stubs or by accident. These libraries can be added to classpath manually in the preferences http://developer.axonivy.com/doc/latest/DesignerGuideHtml/ivy.processmodeling.html#ivy.project.preferences.java The **Engine** is now also delivered as OSGI version. This means that the proper ClassLoader isolation per Bundle behaves as it does in the Designer. So a huge runtime behavior difference is gone since 6.6.1. The OSGI Engine will become the default version of the Engine. We do not plan to support the OS specific packages any longer due its classloading shortcomings. But for a short time we still release the alternative packages that can be used if you face migration issues. ---------- **Axon.ivy 6.5.0 and older** The ugly workaround is still required. You - Designer: manually need to patch the JAR in the plugins directory. - Engine: rename the /lib/shared/xmlbeans_2.4.0.jar to somethink like xmlbeans_2.4.0.jar.deactivated

Yes I think nobody raised the pressure on this issue. So it's still the workaround that you need... Meanwhile we're working on a better classloader isolation In short: The hack is no long required. Since 6.6.1 POI can be used in a project without any library conflicts at runtime. ---------- **Axon.ivy 6.6.1 and modularity architecture so that these younger** These kinds of jar JAR hell issues are gone from 6.6.1 upwards. In the **Designer** many libraries which are not essentially required were removed from the Axon.ivy Classpath container. Practically this means that `Webservice Process (CXF)` and `Webservice Call (AXIS2)` libraries are no longer on the classpath of the project. And as xmlbeans is a dependency of CXF - the conflict with POI is gone. If anyone still needs the old libraries as they were used to patch AXIS stubs or by accident. These libraries can be avoided added to classpath manually in the future...preferences http://developer.axonivy.com/doc/latest/DesignerGuideHtml/ivy.processmodeling.html#ivy.project.preferences.java The **Engine** is now also delivered as OSGI version. This means that the proper ClassLoader isolation per Bundle behaves as it does in the Designer. So a huge runtime behavior difference is gone since 6.6.1. The OSGI Engine will become the default version of the Engine. We do not plan to support the OS specific packages any longer due its classloading shortcomings. But for a short time we still release the alternative packages that can be used if you face migration issues. ---------- **Axon.ivy 6.5.0 and older** The ugly workaround is still required. You manually need to patch plugins directory.

Yes I think nobody raised the pressure on this issue. So it's still the workaround that you need... Meanwhile we're working on a better classloader isolation and modularity architecture so that these kinds of jar hell issues can be avoided in the future...