stevedlawrence commented on code in PR #1108: URL: https://github.com/apache/daffodil/pull/1108#discussion_r1410965653
########## daffodil-test-integration/src/test/scala/org/apache/daffodil/cliTest/TestCLIDebugger.scala: ########## @@ -22,19 +22,72 @@ import java.nio.file.Files import org.apache.daffodil.cli.Main.ExitCode import org.apache.daffodil.cli.cliTest.Util._ +import org.apache.daffodil.lib.Implicits._ import net.sf.expectit.matcher.Matchers.regexp import org.junit.Test +/** + * Tests specific to the CLI debugger + * + * Note that all tests set "fork = true" because SBT creates a class loader with two versions of Review Comment: > Also, why did the change of jline version cause all this need? When SBT runs tests it makes two different versions of jline available via its class loader--one is the version we depend on and the other is what SBT uses for its console stuff, which lags behind the version we use. In some cases, the SBT test class loader finds one class from one jline version but a different class from the other version. And jline made changes to one of the classes so that the different versions can't be used together. I think we were just lucky in the past and the different classes were compatible. By forking, SBT's jline is no longer on the classpath, so this issue doesn't show up. It seems like a pretty clear bug that SBT is putting its version of jline on the classpath, but we've reported it and they don't seem inclined to fix it. We've had similar issues with things like test IBM DFDL, where we ended up with two different versions of ICU4J on the classpath, one needed by Daffodil and one needed by IBM DFDL. Java's classpath issues strike again. > Why is this only an issue for CLI debugger tests? The CLI debugger is the only thing in Daffodil that uses jline. If the debugger is never triggered by a test, then the class loader never tries to find, load, and use those incompatible classes from different jars. I'll update the comment to make this issue a bit more clear. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
