stevedlawrence commented on code in PR #1057:
URL: https://github.com/apache/daffodil/pull/1057#discussion_r1340461983
##########
build.sbt:
##########
@@ -211,6 +212,43 @@ lazy val testStdLayout =
Project("daffodil-test-stdLayout", file("test-stdLayout
.dependsOn(tdmlProc % "test")
.settings(commonSettings, nopublish)
+/* Workaround: certain reflection (used by JAXB) isn't allowed by default in
JDK 17:
+ *
https://docs.oracle.com/en/java/javase/17/migrate/migrating-jdk-8-later-jdk-releases.html#GUID-7BB28E4D-99B3-4078-BDC4-FC24180CE82B
+ *
+ * While we can handle this JVM quirk at build time, at runtime we won't know
+ * a user's JVM version. We'll provide documentation and an extension setting
+ * to add these flags to the extension-launched debugger backend.
+ */
+lazy val extraJvmOptions: Seq[String] =
+ if (scala.util.Properties.isJavaAtLeast("17"))
+ Seq(
+ "--add-opens",
+ "java.base/java.lang=ALL-UNNAMED",
+ )
+ else Seq()
+
+lazy val xjcSettings =
+ Seq(
+ libraryDependencies ++= Seq(
+ "com.sun.xml.bind" % "jaxb-impl" % "2.2.11",
+ "javax.activation" % "activation" % "1.1.1",
+ "org.glassfish.jaxb" % "jaxb-xjc" % "2.2.11",
+ ),
+ xjcCommandLine += "-nv",
+ xjcCommandLine += "-p",
+ xjcCommandLine += "org.apache.daffodil.tdml",
+ xjcLibs := Seq(
+ "org.glassfish.jaxb" % "jaxb-xjc" % "2.2.11",
Review Comment:
I see, thanks for the explanation. Sounds like the tdml-core split is a
better solution.
If we did integrate the TDMLRunner into the JAXB bindings, I'm not sure we
would even want bindings for the stuff we ignore now. For example, embedded
DFDL schemas just want to be treated as raw strings or XML nodes or something.
Those schemas are just written to a file and compiled with Daffodil, so
converting them to JAXB bindings just to serialize back to XML is probably
unnecessary.
But I don't think there's a plan to integrate the TDML runner into these
bindings, at least in the near term, so whatever the solution is for duplicate
identifiers, it can be dealt with then.
--
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]
