stevedlawrence commented on code in PR #1057:
URL: https://github.com/apache/daffodil/pull/1057#discussion_r1342630389
##########
build.sbt:
##########
@@ -211,6 +214,43 @@ lazy val testStdLayout =
Project("daffodil-test-stdLayout", file("test-stdLayout
.dependsOn(tdmlProc % "test")
.settings(commonSettings, nopublish)
+lazy val xjcSettings =
+ Seq(
+ libraryDependencies ++= Dependencies.xjc,
+ xjcCommandLine ++= Seq(
+ "-nv",
+ "-p", "org.apache.daffodil.tdml",
+ "-no-header"),
+ xjcLibs ++= Dependencies.xjc,
+ xjcJvmOpts ++=
+ /* 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 need to provide documentation about this.
+ */
+ (if (scala.util.Properties.isJavaAtLeast("17"))
+ Seq(
+ "--add-opens",
+ "java.base/java.lang=ALL-UNNAMED",
+ )
+ else Seq()),
+ Compile / xjc / sources := Seq(
+
file("daffodil-lib/src/main/resources/org/apache/daffodil/xsd/tdml-core.xsd"),
+ ),
+ // Auto-generated Java files have invalid Scaladoc :(
+ Compile / doc / sources ~= (_ filterNot (_.getName endsWith ".java")),
+ // Tests use JAXB, which uses reflection, which has restrictions above JVM
17.
+ Test / fork := true,
Review Comment:
I'm generally not a fan of forking tests, we've seen forking cause things to
go much slower. But I guess in this specific case it's only for tdml-lib, which
is small enough that it's not really noticeable. So should be fine. Just a
heads up to make sure we don't do this globally.
But another win for scalaxb, no need for these Java 17 reflection options
(which users running Daffodil on Java 17 would also need to add?), no need to
fork tests, no Java conditional dependencies, and no need to mess with doc or
xjc sources. Everything just works the way it's expected to.
If xjc is the right technology to use I guess this is fine, but there sure
are a lot of hacks being added to get it working that I think just go away if
we switch to scalaxb. And with the tdml-core change, the changes are very
straightforward. I was able to get it working with just a few settings:
```scala
lazy val scalaxbSettings = Seq(
Compile / scalaxb / scalaxbPackageName :=
"org.apache.daffodil.tdml.scalaxb",
Compile / scalaxb / scalaxbGenerateMutable := true,
Compile / scalaxb / sources := Seq(
(lib / Compile / resourceDirectory).value /
"org/apache/daffodil/xsd/tdml.xsd",
),
// fixes issue with unused imports
Compile / scalaxb / scalaxbHttpClientStyle := HttpClientStyle.Sync,
)
```
Granted, I didn't create any tests to see how marshalling/unmarshalling
worked, but I imagine it's straightforward.
##########
project/Dependencies.scala:
##########
@@ -63,4 +63,17 @@ object Dependencies {
lazy val exi = Seq(
"com.siemens.ct.exi" % "exificient" % "1.0.7",
)
+
+ lazy val xjc =
Review Comment:
This `xjc` dependency list is assigned to both `xjcLibs` and
`libraryDependencies`. This is fine for `xjcLibs` since that setting only
defines dependencies needed to run the xjc source generator. But I don't think
we can have dependencies added to `libraryDependencies` that are conditional on
the java version, since the version of Java we build with might be different
than the version of Java a used at runtime.
In fact, since releases are built and published with Java 8, these won't be
listed as actual dependencies for our official releases. So people using Java
11 or later won't have them as a dependency.
But maybe that's okay and none of these should be added to
`libraryDependencies` in the first place? Maybe we document (or maybe it's
obvious to JAXB users?) that if a user wants to use these xjc generated files
they need to depend on those xjc libraries? Or maybe we just always require
them regardless of java version?
Is this the result of
https://github.com/apache/daffodil/pull/1057#discussion_r1339338337
Note, another win for scalaxb--I don't think it has any dependency
complications like this.
--
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]
