stevedlawrence commented on code in PR #1057:
URL: https://github.com/apache/daffodil/pull/1057#discussion_r1327458858
##########
build.sbt:
##########
@@ -211,6 +214,67 @@ 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",
+ xjcBindings += "daffodil-tdml-lib/src/main/resources/bindings.xjb",
+ xjcLibs := Seq(
+ "org.glassfish.jaxb" % "jaxb-xjc" % "2.2.11",
+ "com.sun.xml.bind" % "jaxb-impl" % "2.2.11",
+ "javax.activation" % "activation" % "1.1.1",
+ ),
+ xjcJvmOpts ++= extraJvmOptions,
+ Compile / xjc / sources := Seq(
+ // Need to refer to the individual files because we do not want
XMLSchema to go through the JAXB compliation
Review Comment:
The content of defineSchema is used for testing schemas emedded in the TDML
file itself.
I guess excluding that from jaxb would be fine if the extension only
supports external schemas, which is how most real schema projects are used. So
maybe that's a fine limitation? Same probably goes for he defineConfig section?
The most important stuff is probably the test cases with inputs and expected
outputs.
Is there a plan so we don't have to maintain two separate tdml.xsd files
that are 90% the same except for this small patch?
--
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]
