stevedlawrence commented on code in PR #1452:
URL: https://github.com/apache/daffodil-vscode/pull/1452#discussion_r2414213882
##########
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:
> So we want the bin for our debugger to be able to switch between versions
and not have 3 separate versions like I have now.
I wouldn't say that *must* be how it's done. If it makes things easier you
could have a a bin file for each each scala binary version. Each binary always
adds its own daffodil-debugger jars and then adds the downloaded jars to that
with the specified daffodil version. This moves the logic form the bin script
to the extension. I think either probably works, just depends on where you want
the logic. My instinct says it's a bit easier to have a single bin file that
has the logic to avoid duplication, but it might create additional complications
> Now is this all done via how I package things in the VSIX, through vite,
or can this be done via the build.sbt?
I'm not too faimlar with how VSIX or vite, so I'm not sure I can say. But
the current PR looks likeit's mostly there. I'm sure it can be done with
build.sbt too. I would recommend figuring out exactly how everything wants to
be organized (e.g. single bin, multiple bins, maybe something completely
different instead of sbt-native-packager, etc.) and then we can figure out the
best way to package it.
> I have some confusion on if we are not bundling the JARs how are we
testing the debugger locally with different versions of Daffodil and getting
sbt to run properly?
I'm not sure I understand this question. Can you clarify what locally
testing looks like right now? I would think local testing is basically
unchanged, just some parts of testing might trigger logic to download and cache
a daffodil version.
--
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]
