stevedlawrence commented on issue #1352: URL: https://github.com/apache/daffodil-vscode/issues/1352#issuecomment-3356869305
> Maybe it would be helpful to know, what is the path Daffodil is taking to support Daffodil 3 alongside 4? We don't have any plans to officially support running Daffodil 3.x and 4.x side by side. We leave it up to users to solve the problems related to different jars and API changes if that's something they need. It's not an easy problem to solve and many solutions will want to handle it differently. For example, with the [NiFi Daffodil Processors](https://github.com/OwlCyberDefense/nifi-daffodil) each .nar release depends on and bundles a single specific version of Daffodil. And NiFi handles classpath separation so that different .nars/versions of the Daffodil processors can all be added to the same NiFi flow. The latest version of the daffodil-sbt plugin also has support for support building precompiled parsers and testing schemas across many different versions of Daffodil. Those are daffodil version specific though, so I don't think you need anything quite as complicated. It uses reflection and SBT magic which I think you can avoid. > Is there a good way you guys suggest we support two different versions of our debugger, I think I would recommend just build separate debugger jars for each version of Scala, so more like option 2, and then have something that downloads Daffodil versions and sets up the classpath with the correct debugger jar. And that would potentially mean three jars--one for Scala 2.12 (Daffodil 3.10.0 and older), one for Scala 2.13 (Daffodil 3.11.0), and one for Scala 3 (Daffodil 4.0.0 and newer). The easiest way to handle this might be with the [sbt-projectmatrix](https://github.com/sbt/sbt-projectmatrix) plugin. I haven't used this much, but it was used this as inspiration for the daffodil-sbt changes, so I think the idea is pretty solid. This plugin makes it easy to build separate jars with separate versions of Scala. And you can have different dependencies/source directories/settings/etc. for different versions. With some basic testing, this seems to do what I would expect: ```scala lazy val root = (project in file(".")) .aggregate(debugger.projectRefs: _*) // the "projectMatrix" leads three separate projects, one for each of the jvmPlatforms lazy val debugger = (projectMatrix in file("debugger")) .settings( name := "debugger", libraryDependencies ++ Seq( /* common dependencies */ ), /* other common settings */ ) .jvmPlatform( scalaVersions = Seq("2.12.20"), settings = Seq( libraryDependencies += "org.apache.daffodil" %% "daffodil-japi" % "3.10.0" % "provided", ) ) .jvmPlatform( scalaVersions = Seq("2.13.16"), settings = Seq( libraryDependencies += "org.apache.daffodil" %% "daffodil-japi" % "3.11.0" % "provided", ) ) .jvmPlatform( scalaVersions = Seq("3.3.6"), settings = Seq( libraryDependencies += "org.apache.daffodil" %% "daffodil-core" % "4.0.0" % "provided", ) ) ``` This also allows you to have common code in `src/main/scala` and scala-version specific code in other directories. I *think* the debugger API is the same in 3.10.0- and 3.11.0 so that logic can all go in `src/main/scala-2` (which is shared for 2.12 and 2.13 builds). And then the Daffodil 4.0.0+ logic would go in `src/main/scala-3`. Note that I say 3.10.0/3.11.0/4.0.0 logic, but I imagine those directories will just contain small shim classes that support the different package names and minor API differences. I imagine the vast majority of code can be shared as long as your common code builds on all scala versions--that's a bit of work, but I imagine it's not too bad. When you run sbt package, it builds three separate jars for each of the scala versions: * debugger/target/jvm-2.13/debugger_2.13-0.1.0-SNAPSHOT.jar * debugger/target/jvm-2.12/debugger_2.12-0.1.0-SNAPSHOT.jar * debugger/target/jvm-3/debugger_3-0.1.0-SNAPSHOT.jar These three jars (and their dependencies) would be packaged in the vsix file, and then the extension would download the appropriate version of Daffodil and set up the classpath to use the right debugger jars and Daffodil jars. I imagine the vsix file might also want to bundle with the latest version of Daffodil prepackaged so it doesn't need the internet to work. I'm sure things are more complex than that, especially with all the plugins and custom stuff the debugger has, but at it's core I think that's the idea I would go for. -- 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]
