mbeckerle commented on code in PR #1479:
URL: https://github.com/apache/daffodil/pull/1479#discussion_r2070574619
##########
build.sbt:
##########
@@ -28,20 +28,13 @@ lazy val genTunablesDoc = taskKey[Seq[File]]("Generate
tunables doc from dafext.
lazy val daffodil = project
.in(file("."))
- .enablePlugins(JavaUnidocPlugin, ScalaUnidocPlugin)
+ .enablePlugins(ScalaUnidocPlugin)
.aggregate(
cli,
codeGenC,
- core,
- io,
- japi,
- lib,
Review Comment:
But in general the separation of core from runtime1 was not properly layered
from the earliest days of this project. I'm culpable for much of that as I
*think* I set up this Compiler -> ProcessorFactory -> DataProcessor stuff in
2010 before I even joined Owl/Tresys.
I'm not opposed to merging core and runtime1 and runtime1-unparsers
together, along with daffodil-lib even.
Scala 3's requirement that the top of a class taxonomy must be a Java
interface if Java is to be able to call it,... requires a huge amount of
refactoring that we didn't anticipate.
We could avoid this by implement the java api by way of delegation (aka
proxy objects) but as with our prior japi/sapi, that's painful to maintain. I
very much prefer to just define java interfaces at the top, and our classes
implement the user API.
Splitting this back out into independent separable modules is a bunch of
additional work, which is necessary eventually to support goals like
non-XSD-based syntax for DFDL, and to properly support DFDL's DPath expressions
in the C-code-generator, and allow for other backends than runtime1, and not
require runtime1 when creating a different runtime like the C-code-generator.
We have JIRA tix for that sort of work. But that kind of work is a substantial
rewrite of large aspects of daffodil.
But the point I guess is until that refactoring work is done, having core,
runtime1, runtime1-unparsers and lib as separate modules doesn't really add any
value for users. They all ultimately depend on core which depends on the others
so it's all pulled in anyway currently.
And the split-out modules makes the scala 3 new Java API either impossible
or quite difficult.
So I'm not opposed to merging them for now.
I suggest this big merged module NOT be named "runtime1". But rather "core"
is the name we should carry forward.
--
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: commits-unsubscr...@daffodil.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
