stevedlawrence commented on issue #146:
URL: https://github.com/apache/daffodil-sbt/issues/146#issuecomment-3665494192
Agreed, we certainly shouldn't let sbt syntax limit our own syntax. The
counter to that is that there is potentially some value in making things
somewhat similar to SBT configs so that things look familiar to people that
know SBT or are reading sbt documentation and don't have to learn too much
syntax. So we probably want to find the right balance and capabilities.
> Note also that schemas have dependencies on BOTH the compiled daffodil
".bin" as well as on the daffodil plugin jar files, and we should try to grab
them both and use appropriately on classpath etc. with one mention here.
In order to support the daffodilCrossVersion stuff, we actually have to a
special property just for plugins, e.g.
```scala
daffodilPluginDependencies := Seq(
"org.example" % "daffodil-layer-plugin" % "1.0.0"
)
```
This dependency is tweaked so that it adds the "daffodilXYZ" classifier
based on the `daffodilVersion` being built.
But maybe this is the wrong approach and we want something like one of the
above options. For exmaple, maybe we support DFDLSchema and DFDLPlugin, e.g.:
```scala
libraryDependencies ++= Seq(
DFDLSchema(...)
DFDLPlugin(...)
)
```
Or we could do someting similar to the original comment:
```scala
libraryDependencies ++= Seq(
"com.example" % "dfdl-layer" % "0.0.1" daffodilPlugin("4.0.0")
)
```
Something along those lines is probably better than the
daffodilPluginDependencies setting since it avoids having to learn a new
setting.
--
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]
