stevedlawrence commented on code in PR #1452:
URL: https://github.com/apache/daffodil-vscode/pull/1452#discussion_r2413876985
##########
vite/package.vite.config.mjs:
##########
@@ -109,23 +121,38 @@ function copyToPkgDirPlugin() {
{ from: 'src/styles/styles.css', to: `${pkg_dir}/src/styles/styles.css` },
{ from: 'src/tdmlEditor/', to: `${pkg_dir}/src/tdmlEditor` },
]
- const serverPackageFolder = path.join(
- path.resolve('dist/package'),
- serverPackage
- )
-
- console.debug(`== [Vite] | serverPackageFolder: ${serverPackageFolder}`)
- // remove debugger package folder if exists
- if (fs.existsSync(serverPackageFolder)) {
- fs.rmSync(serverPackageFolder, { recursive: true })
+
+ const serverPackageFolders = {
+ scala2_12: path.join(
+ path.resolve('dist/package'),
+ `daffodil-debugger-${daffodilVersions['scala2.12']}-${pkg_version}`
+ ),
+ scala2_13: path.join(
+ path.resolve('dist/package'),
+ `daffodil-debugger-${daffodilVersions['scala2.13']}-${pkg_version}`
+ ),
+ scala3: path.join(
+ path.resolve('dist/package'),
+ `daffodil-debugger-${daffodilVersions['scala3']}-${pkg_version}`
+ ),
Review Comment:
> would I be adding the Daffodil CLI as a dependency in build.sbt instead of
the other ones?
I didn't mean to suggest that. The dependencies and directories you have
would stay just as you have them, since those dependencies are all that is
needed to compile your daffodil-debugger.jar's. By marking them as "provided"
it makes it so those daffodil jars that you depend on are not packaged into the
.vsix file (I think, I'm not actually sure how the jars get bundled?).
But you still need those daffodil jars when you actually run the debugger.
I'm suggesting that you download those from official daffodil CLI releases
since those contain all the jars you compiled with and need at runtime (plus
some you don't need that will essentially be ignored).
Also note that we only need binary compatibility, which Daffodil strives to
maintain. So for example, you could compile daffodil-debugger-3 with
dafodil-core-4.0.0 and run against Daffodil 4.1.0 CLI jars and in theory things
should still work. So that's why you really only need three versions of
daffodil-debugger for each of the 3 scala binary versions.
> Could you describe an example of how I make multiple projects
I think it's much like what you have now. You build three different daffodil
debugger jars, the extension bundles those jars and their non-daffodil
dependencies. So your vsix looks something like this:
```
├── daffodil-debugger-2.12-1.4.2
│ └── lib
│ └── *.jar # non-daffodil jars
├── daffodil-debugger-2.13-1.4.2
│ └── lib
│ └── *.jar # non-daffodil jars
├── daffodil-debugger-3-1.4.2
│ └── lib
│ └── *.jar # non-daffodil jars
├── bin/
│ ├── daffodil-debugger
│ └── daffodil-debugger.bat
└── ... // other extension stuff
```
Now, let's assume that the user has some projects that they want to test
with 3.11.0 and 4.0.0. And we'll assume somehow the official
apache-daffodil-X.Y.Z-bin.zip's have been downloaded and extracted to
`~/.cache/daffodil-debugger/`, e.g.
```
~/.cache/daffodil-debugger/
├── apache-daffodil-3.11.0-bin/
│ ├── bin/ # daffodil CLI bin, not used
│ └── lib/
│ └── *.jar # daffodil jars, some will not be used
└── apache-daffodil-4.0.0-bin/
├── bin/ # daffodil CLI bin, not used
└── lib/
└── *.jar // daffodil jars, some will not be used
```
All these these separate directories have everything needed to run the
debugger if combined correctly. The extension could run the daffodil-debugger
script with some option that says which version to use, e.g.
```
extension/bin/daffodil-debugger --daffodil-version 3.11.0 ...
extension/bin/daffodil-debugger --daffodil-version 4.0.0 ...
```
Based on that option, the script will setup the classpath with the right
jars and execute java. For example, the 3.11.0 version would run something like
```
java \
-classpath
".../daffodil-debugger-2.13-1.4.2/lib/*.jar:~/.cache/daffodil-debugger/apache-daffodil-3.11.0-bin/lib/*.jar"
\
org.apache.daffodil.debugger.dap.DAPodil
```
The 4.0.0 command would look very similar, just with different directories:
```
java \
-classpath
".../daffodil-debugger-3-1.4.2/lib/*.jar:~/.cache/daffodil-debugger/apache-daffodil-4.0.0-bin/lib/*.jar"
\
org.apache.daffodil.debugger.dap.DAPodil ...
```
So the daffodil-debugger script stays mostly the same, but has a little
extra logic to build the classpath based on jars bundled with the extension and
daffodil jars downloaded from official releases. And the downloaded daffodil
release will contain some jars you don't need, like the daffodil-cli.jar, but
DAPodil will never use anything in those jars so they'll just be ignored.
Note that this is just one way to do it, I'm sure there are many other ways.
For example, maybe the extension has logic to figure out the classpaths and it
just passes that into the daffodil-debugger command.
But the core idea is that debugger jars (excluding daffodil jars) are
bundled with the extension, the daffodil jars are downloaded separately, and
all the jars are combined to build the classpath when executing DAPodil.
--
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]
