Yeah, it looks like FileDocumentPart had this same behavior of returning
-1 for files in jars as far back as I can find. So likely at somepoint
we just started requiring a length. That's a bit harder to find where we
did that, but ideally we can get rid of this -1 thing and get lengths of
This means when using IntelliJ IDEA, running tests, the TDML runner is NOT
doing the jar export and then looking inside them.
Ok. I guess I believe that.
A TDML runner change must have happened between 3.0.0 and 3.1.0 creating
this vulnerability, because it doesn't happen in 3.0.0.
There are a
Using EDIFACT, modifying the build.sbt to have exportJars := true.
Java 17, sbt 1.6.2,
Using daffodil 2.6.0
sbt clean test - all works
Using daffodil 3.0.0
sbt clean test - all works
Using daffodil 3.1.0 (or seemingly anything newer)
sbt clean test - fails Abort: Usage error:
Hmm, I think this is just a bug in the Daffodil TDML runner related to
documentPart's with type="file":
https://github.com/apache/daffodil/blob/main/daffodil-tdml-lib/src/main/scala/org/apache/daffodil/tdml/TDMLRunner.scala#L2249-L2262
When exportJars is true, findTDMLResource for the file
I was also able to recreate this error in the CSV repo by adding the
"exportJars := true" (note: false doesn't cause this error),
and updating the Daffodil version to the last commit before the RC
commit (i.e 613c2b0c077f56dbb425e7ebab1a2d154cbdbd06).
so:
exportJars :=true
I tried many things, including clean git clones of all related repos. This
problem is a very bizarre interaction.
The fact that the tests ran flawlessly under intelliJ IDEA, but failed
running sbt from the command line
I searched for sbt bugs related to exportJars. I did find
I can confirm that at least sbt clean does not resolve the issue. Didn't try a
got clean, although I had just cloned the repo in question so I don't think it
had gotten dirty in anyway either.
Josh
On Mar 18, 2022 1:22 PM, Steve Lawrence wrote:
That's surprising to me. All that exportJars is
That's surprising to me. All that exportJars is supposed to to do is
include or not include certains files on the class path and use packages
jars instead.
And that assertion that is failing is beacuase the length of test data
is negative, which should never happen and I don't know how
We noticed that only when running "sbt test" in schema projects with the
exportJar setting, the error below was generated resulting in failure of
all the tests. Note that running the same tests via IntelliJ/Junit
didn't reproduce this error, and the error was isolated to using sbt to
run the
