stevedlawrence commented on code in PR #1057:
URL: https://github.com/apache/daffodil/pull/1057#discussion_r1340036645
##########
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:
Oof, I didn't notice it that change is two years old without a release. I
guess we could just do this in that case to just fix the issue:
```scala
xjcLibs += "javax.activation" % "activation" % "1.1.1",
```
Keeps things a little less verbose. And I doubt we have to worry about he
plugin being updated and breaking things. Doubt there will be another release
anytime soon.
Alternatively, has anyone looked at
[scalaxb](https://github.com/eed3si9n/scalaxb)? It looks like it's created by
the main SBT maintainer, so imagine it will continue to be maintained for a
while and with SBT best practices.
I made changes this PR to use scalaxb instead of xjc and it was pretty
straightforward. This was all I had to change to this PR:
```scala
lazy val tdmlLib = Project("daffodil-tdml-lib", file("daffodil-tdml-lib"))
.enablePlugins(ScalaxbPlugin)
.dependsOn(macroLib % "compile-internal", lib, io, io % "test->test",
slf4jLogger % "test")
.settings(commonSettings)
.settings(scalaxbSettings)
lazy val scalaxbSettings = Seq(
Compile / scalaxb / scalaxbPackageName :=
"org.apache.daffodil.tdml.scalaxb",
Compile / scalaxb / sources := Seq(
(lib / Compile / resourceDirectory).value /
"org/apache/daffodil/xsd/tdml-core.xsd",
)
)
```
Nicely, it doesn't auto enable so it can be enabled for only the one project
we need without the `sources := Seq()` hack.
The only issue I ran into is the generator adds imports that aren't used,
which Daffodil treats as an error. But disabling fatal warnings, the generated
code compiles fine. There's probably a way to fix this without disabling
warnings. And if not, I imagine scalaxb would accept a patch and get a release
out quickly.
I also noticed it generates immuatable case classes. But it does have a
`scalaxbGenerateMutable` setting to make the case members `var`s if that's
preferred
Plus, I imagine it is probably more straightforward to move our existing
TDML runner functionality into those generated classes since it's already scala
code, which would be nice. It would probably reduce boilerplate in our existing
TDML runner lib, and make it so you could run tests without having to serialize
wih saxb and then reload with the TDML runner. That's a far off goal, but
scalaxb makes that more possible I think.
--
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]
