I don't think it's worth backporting to ICU 51.1. There were a handful of bugs that were fixed by that upgrade.
To me, this sounds like another good reason to switch the TDML runner to work how I mentioned in a review comment: https://github.com/apache/incubator-daffodil/pull/129#discussion_r229054897 The idea of that comment is that we change the TDML runner so it only ever runs with a single TMLDDFDLPRocessorFactory, and one must select which implementation to run. It then runs all tests, but skips tests using the junit "assunTrue" function if they are not marked as working for that implementation. We could then create a new sbt task that takes whatever steps are necessary to switch to a different factory. So for example: $ sbt > tdmlImplemenation com.ibm.IBMTDMLDFDLProcessorFactory /path/to/ibm/jars/ > test This task could set some environment variable to "com.ibm.IBMTDMLDFDLProcessorFactory", which the TDML runner could use to dynamically load the IBM factory instead of the default Daffodil one, and it could also modify the sbt test:fullClasspath setting to remove most all dependencies except for the minimum needed to execute the TDML runner (maybe just removes everything from lib_managed and lib), and add the path provided. I imagine there's a way to set an enviroment variable and manually modify the classpath in eclipse for a non-sbt solution. This avoids having to worry about dependency class/class loaders/OSGI/etc and keeps things fairly simple. Also makes it very explicit about which TDML factory. Also means we don't have to put things unrelated to Daffodil in the libs folder to add unmanaged dependencies. Thoughts? On 11/1/18 4:58 PM, Mike Beckerle wrote: > Daffodil 2.2.0 uses ICU4J 62.1 > > IBM DFDL uses ICU4J 51.1 > > > These are not compatible. Hence, annotating some of the tests in Daffodil, so > that they will try to also run the test under IBM DFDL if it is found on the > classpath.... doesn't work. > > > I tried backing out daffodil's dependency to 51.1, but I get test failures. > > > When I try to run tests within Daffodil that dynamically load the IBM DFDL > runner, it fails because the IBM DFDL runner calls methods in the ICU library > that don't exist in version 62.1 of ICU. > > > Specifically the com.ibm.icu.impl.ICUBinary.readHeader(...) method. Fails > with NoSuchMethodError > > > I'm not finding a clear, simple solution to this by web searching. > > > Isolating the IBM_DFDL class so that it can have it's own separate > incompatible ICU library version requires use of a second java classLoader to > load the dynamically-loaded module. > > > Good examples of how to do this on the web seem to be lacking however. I know > OGSI modules are supposedly the solution to such problems, but those seem to > require buying into an extensive framework. > > > It sure seems to me I should be able to add one line to the > ibmTDMLCrossTester module's build.sbt indicating that it is to use an > isolated classpath loader for its dependencies. That should be all that is > needed information-wise to solve this. > > > Any suggestions? > > > > > > >
