Some other positives if DAP were combined it into the existing CLI:
There was once talk of making it so the the VS Code debugger could
switch between different Daffodil versions. If it were part of the CLI,
this just means downloading a new version of the Daffodil CLI and
pointing VS Code to it--that process could either be manual or automated
in the VS Code settings.
I think this would also make it easier to test Daffodil snapshots with
the VSCode extension? I believe the current process requires you to
publishLocal a Daffodil snapshot, then update the daffodil-vscode repo
(or if we split it, the daffodil-debugger repo) to have the snapshot
version, and the build that. If it was all part of the CLI, you could
just run "sbt stage" in the Daffodil repo and point VSCode to those
staged files. It only avoids a couple extra steps, but if you do it
frequently it would be nice.
On 7/19/22 2:15 PM, Steve Lawrence wrote:
+1 to this
I was thinking the same thing as I read this. My only thought is using
"daffodil dap" since the debug server is just a thing that implements
the DAP protocol, and theoretically it could be used any any IDE that
supports DAP (I think?). But the name is the easy part.
My only other (minor) concern is that this pulls in a number of
dependencies. It's not an issue from a licensing perspective since we
know they are fine, but it does make the CLI release a bit bigger and
more to manage, e.g. lots of Cats jars. I suspect it's not enough to
really matter (and most of the size is probably daffodil jars), but if
we do go this route, during or prior to migration it might be worth
looking to see if anything can be replaced. For example, one thing that
jumps out is VSCode debugger currently depends on logback for logging,
but daffodil use log4j.
The other concern is that currently the VS Code stuff can sort of
develop at its own pace. If we integrate the DAP portion into the CLI,
it means VSCode can't get DAP updates without a Daffodil release. But it
seems DAP is fairly stable, and as long as we keep a quick release cycle
and plan accordingly, that shouldn't be too much of an issue.
I would perfer this approach over creating a new repo. It's a bit less
to keep track of, and makes it easier to ensure we don't have any
breaking changes with changes to Daffodil.
On 7/19/22 1:52 PM, Mike Beckerle wrote:
I think of this as a daffodil server mode, for the front end VSCode stuff
to use.
So, is it plausable to add the code to daffodil proper. Make it a CLI
command mode to start up this server, so that
daffodil vscodeServer
starts it, optionally with connection options like what ports to use,
etc.
On Tue, Jul 19, 2022 at 1:45 PM Shane Dell <[email protected]> wrote:
All,
This thread is to discuss splitting out the code for the Apache Daffodil
Scala Debugger from the apache/daffodil-vscode repository. The two
options
would be:
- 1.) Move the debugger source code into the apache/daffodil repo.
However,
will this work because the debugger code depends on certain daffodil
Scala
libraries to be published? This is mostly an option since both are
mostly/fully Scala based.
- 2.) Create a new repo (apache/daffodil-debugger?,
apache/daffodil-debugger-scala?) where the Scala code will live.
This would be helpful as the apache/daffodil-vscode repo is heavily
based
on creating the VS Code extension for Daffodil. With this the debugger
source code is rarely updated, when it is they are pretty minor fixes or
dependency updates. Currently it is a bit of a cluster having a mix of
node/JavaScript/TypeScript and Scala which causes an issue with
dependency
bots checking as these are checking for both npm and sbt/Scala
dependencies, causing many PRs to be made. The extension code also
runs a
sbt universal:packageBin command in multiple occurences, being able to
remove this and downloading the debugger package would simplify a couple
different processes for the extension.
My personal vote is for creating a new repo called something like either
apache/daffodil-debugger or apache/daffodil-debugger-scala.
Sincerely,
Shane Dell
