We will also need some tests for this mode to insure we haven't broken it. A test rig would be needed of some sort.
On Tue, Jul 19, 2022 at 2:15 PM Steve Lawrence <slawre...@apache.org> 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 <shaned...@apache.org> 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 > >> > > > >
