It is currently possible to use JDK 8 for the build and execution. However, as the Apache NetBeans project is slowly moving towards JDK 11, using JDK 11 may be the safest bet.
$ git clone https://github.com/apache/netbeans.git $ cd netbeans/
To build the VS Code extension invoke:
netbeans$ ant build netbeans$ cd java/java.lsp.server java.lsp.server$ ant build-vscode-ext
The resulting extension is then in the build
directory, with the .vsix
extension. The typical file name is apache-netbeans-java-0.1.0.vsix
- the version can be changed by using the -Dvsix.version=x.y.z
property - that's what continuous integration server and release builders do.
If you want to develop the extension, use these steps for building instead:
netbeans$ cd java/java.lsp.server java.lsp.server$ ant build-lsp-server java.lsp.server$ cd vscode vscode$ npm install vscode$ npm run watch
This target is faster than building the .vsix
file. Find the instructions for running and debugging below.
Often it is also important to properly clean everything. Use:
java.lsp.server$ ant clean-vscode-ext java.lsp.server$ cd ../.. netbeans$ ant clean
The java.lsp.server
module has classical (as other NetBeans modules) tests. The most important one is ServerTest which simulates LSP communication and checks expected replies. In addition to that there are VS Code integration tests - those launch VS Code with the VSNetBeans extension and check behavior of the TypeScript integration code:
java.lsp.server$ ant build-vscode-ext # first and then java.lsp.server$ ant test-vscode-ext
In case you are behind a proxy, you may want to run the tests with
java.lsp.server$ npm_config_https_proxy=http://your.proxy.com:port ant test-vscode-ext
when executing the tests for the first time. That shall overcome the proxy and download an instance of code
to execute the tests with.
Using the application yourself is the best way of testing! If you want to edit/compile/debug Apache NetBeans sources, there is a way. After building the project, execute:
vscode$ npm run apisupport
the system connects to associated autoupdate center and downloads, installs and enables org.netbeans.modules.apisupport.ant
module. With such module installed one can open Apache NetBeans projects and work with them directly from VSCode.
To use the extension created for developement you can run VS Code with following parameter:
vscode$ code --extensionDevelopmentPath=`pwd` path_to_project
Or you can open the vscode
folder in code
directly and use F5 to debug the extension's typescript code.
To debug the Java code, launch the NetBeans part of the VS Code system first and specify suitable debug arguments to start standalone NBLS instance:
vscode$ npm run nbcode -- --jdkhome /jdk -J-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=8000
Connect to the process with Java debugger, setup all breakpoints. Then launch the VS Code extension (which connects to the already running standalone NBLS Java process):
vscode$ code --extensionDevelopmentPath=`pwd` path_to_the_maven_project
To start from a clean state, following CLI options maybe of an interest:
--user-data-dir
- clean any user settings with this option--extensions-dir
- avoid 3rd party extensions using this optionImportant note: when --user-data-dir
is used, the standalone NBLS must be start as
vscode$ nbcode_userdir=/the-code-user-data-dir npm run nbcode -- --jdkhome /jdk -J-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=8000
So that the vscode can connect to the standalone NBLS instance.
The default userdir location is inside the global vscode settings location:
When the environment variable nbcode_userdir
(to e.g. /tmp/foo
) is set when starting vscode or nbcode (npm run nbcode), the userdir will point to /tmp/foo/userdir
.
Standalone NBLS can be instructed to print messages (stderr, out) to the console: add -J-Dnetbeans.logger.console=true
to the npm commandline. This has the same effect as netbeans.verbose = true
settings in the vscode. Messages from the LSP protocol can be displayed in vscode by setting java.trace.server = verbose
setting in vscode JSON settings.
By default the extension uses global userdir of the global vscode instance and uses NBLS data in there. In case this is not desired, the launch.json
must be changed:
"env": { "nbcode_userdir": "/path/to/development/area" }
When using standalone NBLS at the same time, the NBLS must be started as
vscode$ user_data_dir=/path/to/development/area npm run nbcode -- --jdkhome /jdk -J-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=8000
This way the NBLS will use a separate config/cache directory and will not interfere with the default / global installation.