stevedlawrence opened a new issue, #125: URL: https://github.com/apache/daffodil-sbt/issues/125
Supporting multiple daffodil versions has a lot of complexities, especially when it comes to plugins that are Daffodil specific. The current plugin really can't handle these complexities, and needs to be updated to support them. What we probably need is something simlar to the [sbt-projectmatrix ](https://github.com/sbt/sbt-projectmatrix)plugin, which was the original way to implement cross building for different scala versions before SBT integrated it. Drawing inspiration from that, we could do something like this: ```scala val myFormat = (daffodilProjectMatrix in file(".")) .settings( // settings that are the same for every project name := "dfdl-myFormat", libraryDependencies := Seq( // non-daffodil dependencies ), // daffodil plugin dependencies daffodilPluginDependencies := Seq( "org.example.com" % "customDaffodilCharset" % "1.0.0", "org.example.com" % "customDaffodilLayer" % "1.0.0", ), daffodilTdmlUsesPackageBin := true, daffodilPackageBinInfos := Seq(...), // should not include daffodilPackageBinVersions packageDaffodilBin / publishArtifact := true, ) .daffodilVersions("3.10.0", "3.11.0", "4.0.0") ``` The special `daffodilProjectMatrix` is a custom class that behind the scenes generate a subproject for each version specified in `daffodilVersions`. Each subproject shares the core settings (e.g. name, libraryDependencies, src/test directories) but will have daffodil version specific variations (e.g. `daffodilVersion`, `daffodilPackageBinVersions`). Additionally, the `daffodilPlugins` setting would be transformed before being added to `libraryDependencies` setting (e.g. `"org.example.com" % "customCharset" % "1.0.0"` becomes `"org.example.com" % "customCharset_daffodil400" % "1.0.0"`). We could also have subdirectories for daffodil versions specific sources or tests (e.g. src/main/scala-daffodil400)--this allows things like sharing code where possible, but having daffodil version specific code where needed (e.g. different charset APIS between daffodil versions). An additional consideration is with plugins. With non schema projects only one jar needs to be published since it just contains XML schemas and does not depend on a specific daffodil version. With plugins, we need a jar for every daffodil version. So, if a project enables one of the settings that defines this as containing a plugin (e.g. `daffodilBuildsLayer := true`), then each subproject will publish a jar with the daffodilXYZ suffix, and the core project will not publish anything. If it does not define one of those settings, then only the core project plublishes things and there is no daffodilXYZ suffix. This has an added benefit that you can run tests for multiple versions of daffodil. Currently tests are only run for `daffodilVersion`. This helps to ensure regression tests is available. For projects that don't need this capability, they should be able to use the existing syntax since all this does is automate the creation of multiple subprojects that make use of existing syntax. -- 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]
