Hi - I have some “meta” questions to ask here. Not really technical but more about the relationship between IBM DFDL and Apache Daffodil (Incubating).
(1) That IBM DFDL is on an old version of ICU is concerning. Is IBM DFDL still being maintained? (2) If it is then is there any contact between those maintainers and the Daffodil podling? (3) Assuming that there is contact then what are their plans for the next version? (4) If the goal is for people who want to use Apache Daffodil to get away from IBM DFDL then what is the best model to get people to switch and join this community? It is important for this project to think about how to grow the community … that is the challenge to graduating from the Incubator. Regards, Dave > On Nov 2, 2018, at 9:25 AM, Steve Lawrence <slawre...@apache.org> wrote: > > We can still do cross validation of tests, it just requires one to run a > command to switch between different implementations. As I see it, that's > really the only downside. > > The upsides I see related with this are: > > 1) Makes it explicit and very clear which implementation is being used. > With the current design, it's not clear which implementations are used > for which tests without looking at TDML files. > > 2) Allows one to easily see how many tests passed/failed/skipped with a > particular implementation. Right now, you can't know. You either know a > test passed with all the listed implementations, or failed with at least > one of the listed implementations. If you forgot to add a class to the > implementations list, you won't know that a test wasn't run against it. > To me, this is the biggest reason. Being able to say X% of our test run > and pass against IBM is nice. Right now, you don't know that number > without inspecting all the TDML files to see which have the > implementation listed. > > 3) I believe it removes the complexity related to dependency conflicts > > 4) Doesn't need anything like TestsWorkingOn_IBM_DAF.scala. Tests just > go in the scala or tdml file related to the feature as normal. Then > select an implementation and run tests as normal. Any tests that don't > work with that implementation will be skipped, all other tests will be > run with pass/fail. > > 5) Removes the concept of scala-debug. Tests that are expected to fail > with a particular implementation just don't list that implementation in > the attribute. If a tests fails against all implementations, then it's > implementations attribute will be empty. > > 6) Can simplify the list that goes in the implementations attribute-- > doesn't necessarily need to be a fully qualified class name. > > > On 11/2/18 11:36 AM, Mike Beckerle wrote: >> I agree we should not backport to icu 51.1. >> >> >> But I don't like the idea of not being able to run multiple DFDL >> implementations side-by-side. A primary usage mode for this is to do >> cross-validation tests, where the outer-loop of the task is tests, and the >> inner-loop is running them against each implementation to see that each test >> works the same on all of them. >> >> >> I envision projects with test directories like this: >> >> >> src/test/scala/ >> >> >> TestsWorkingOn_IBM_Daf.scala >> >> TestsWorkingOnlyOn_IBM.scala >> >> TestsWorkingOnlyOn_Daf.scala >> >> TestsFailingOn_IBM.scala >> >> TestsFailingOn_Daf.scala >> >> >> and so on. >> >> >> That all said. It does appear that software component modules which have >> isolated dependencies, but are otherwise linked together, seems beyond >> today's state-of-practice. The recipe may be ultimately simple, but it sure >> doesn't appear to be well-applied standard practice. >> >> >> I did find some ideas online with more searching about Child First Class >> Loader (aka Parent Last Class Loader). This may be sufficient, though I'm >> not yet convinced. >> >> >> >> >> ________________________________ >> From: Steve Lawrence <slawre...@apache.org> >> Sent: Friday, November 2, 2018 7:45:51 AM >> To: dev@daffodil.apache.org; Mike Beckerle >> Subject: Re: ICU version incompatible between IBM DFDL and Daffodil >> >> 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? >>> >>> >>> >>> >>> >>> >>> >> >> >
