Unable to install and run without Internet Access

[mbeckerle]

A new DFDL user tried to install the VSCode extension 1.3.0 on a machine with no internet access and was unsuccessful as something is not bundled that ends up being required.

See email thread: https://lists.apache.org/thread/v4jcs57qzvfg08gcd5hpj96mx0nslh7s

Given that a lot of people using DFDL work in cyber security, development on air-gapped networks needs to be workable somehow.

[mbeckerle]

Interesting: https://github.com/LOLINTERNETZ/vscodeoffline

Not encouraging: https://users.scala-lang.org/t/scala-offline-development/6469

Some ideas here but basically they're saying install and test online, then capture the cached m2 and ivy2 repositories and copy them to the offline machine. https://www.reddit.com/r/scala/comments/a4uhxc/developing_scala_offline/

[mbeckerle]

The real goal is for the Daffodil VSCode Extension to work on a Locked-down MS-Windows (10+) system, where VSCode has been pre-installed, but nothing else.

The complete set of dependencies needs to be able to be packaged and downloaded and "installed" only in user-writable directories, without any need to run privileged installers that modify the system or environment.

[scholarsmate]

There are 2 runtime extension dependencies that this extension relies on:

  "extensionDependencies": [
    "vincaslt.highlight-matching-tag",
    "wmanth.jar-viewer"
  ],

Perhaps one or both of these is contributing the air-gapped system problem?

Neither of these dependencies have additional extension dependencies, so the so once these prerequisite extensions are installed, dependencies for the extension itself ought to be satisfied.

[arosien]

I don't think development of an open-source project is compatible with a locked-down environment. We should support using the debugger extension offline though. (For example, we currently download the debugger backend when starting the extension, rather than package it with the extension itself.)

[mbeckerle]

It is fine for air-gapped and locked down environments to require a few extra steps, like perhaps downloading and unzipping the debugger backend manually, downloading and unzipping scala manually, downloading and unzipping Java JVM/JDK manually, etc. No installers can be involved.

The key is to make it (a) possible, and later worry about making it (b) smoother. A few easy extra steps is fine.

Given our limited resources (dev & test people time) we want as few configurations as possible to maintain and test, so I would nudge in the direction of making ALL the installs a bit more manual and multi-part if that eliminates the air-gap/not distinction.

For example, making everything cope automatically and seamlessly with a "installer installed" Scala OR a Scala unzipped in some user location is too much to test. We should just NOT assume Scala is installed and on any paths or anything, but just depend on it existing somewhere in the file system that we either find, or if not found the locations are given by the user.

Ditto Java and anything else we depend on.

[stevedlawrence]

For example, we currently download the debugger backend when starting the extension, rather than package it with the extension itself.

Is that true? I thought we downloaded the backend when building the vsix file?

[arosien]

Is that true? I thought we downloaded the backend when building the vsix file?

Oops, I don't know why I thought we did that. Perhaps we used to, and this comment needs to be fixed:

  // If useExistingServer var set to false make sure version of debugger entered is downloaded then ran

[arosien]

Created #711.