The section in the CRW 2.1 admin guide about customizing devfile and plugin registries has a number of problems:

a) in the procedure "1. Download the binaries locally," the code provided is poorly formatted and won't run as is. Looks like someone tried to turn markdown into code and missed a step.

Here's an example:

URL_VS_CODE_EXT1="https://github.com/microsoft/vscode-java-debug/releases/download/0.19.0/vscode-java-debug-0.19.0.vsix[_https://github.com/microsoft/vscode-java-debug/releases/download/0.19.0/vscode-java-debug-0.19.0.vsix_]"

Obviously that should read:

URL_VS_CODE_EXT1="https://github.com/microsoft/vscode-java-debug/releases/download/0.19.0/vscode-java-debug-0.19.0.vsix"

There are at least 3 more examples of this problem in the same code block.

More painful is what's documented in the next step, which is also numbered at "1." ... and which reads, simply:

FIXME

In step 2, where it's suggested that the URLs in two meta.yaml files should be updated, the instructions fail to explain that:

a) you can't do that unless you've ssh'd into the pod where the registry is deployed, and
b) doesn't define what to put for URL_PLUGIN1 and URL_PLUGIN2.

And since in CRW 2.1 these URLs in the meta.yaml are references within the container, eg., for the redhat/java/latest plugin:

  extensions:
    - relative:extension/resources/download.jboss.org/jbosstools/vscode/3rdparty/vscode-java-debug/vscode-java-debug-0.24.0.vsix
    - relative:extension/resources/download.jboss.org/jbosstools/static/jdt.ls/stable/java-0.57.0-2029.vsix

... you need to be careful to not use relative:extension but an https:// path.