* feat(jdtls): surface Lombok-generated methods in document symbols
JDTLS' DocumentSymbolHandler filtered out every SourceMethod where
JDTUtils.isGenerated() was true, so Lombok-synthesised methods (getX/setX,
builder(), equals/hashCode/toString, withX, fluent accessors, ...) never
reached the LSP client. As a result Serena's symbol-aware tools — find_symbol,
get_symbols_overview, replace_symbol_body, insert_before_symbol,
insert_after_symbol — could not see, address or edit any Lombok-generated
member; only search_for_pattern / replace_content (text-based) worked.
Upstream introduced an opt-in preference java.symbols.includeGeneratedCode
in eclipse-jdtls/eclipse.jdt.ls#3706 (merged 2026-02-24) and surfaced it
through redhat-developer/vscode-java#4335. First vscode-java release with
the new JDTLS build is v1.53.0 (2026-02-26). Serena was pinned to v1.42.0-561,
well before the fix existed.
Changes:
- New ls_specific_settings.java.lombok_show_generated setting (default true);
forwarded to JDTLS as java.symbols.includeGeneratedCode in initialize
params. Older servers ignore the unknown preference key silently.
- Bump bundled vscode-java DEFAULT 1.42.0-561 -> 1.54.0-923 (brings JRE
21.0.10, Lombok 1.18.39 and Equinox launcher 1.7.100). INITIAL stays at
1.42.0-561, so per the per-version install-dir convention from #1438 the
new build lands in vscode-java-1.54.0-923/ while legacy vscode-java/
caches and any explicit vscode_java_version: '1.42.0-561' override keep
working.
- New VsixResourcePaths dataclass + INITIAL/DEFAULT_VSCODE_JAVA_PATHS pin
the JRE / Lombok / launcher filenames *inside* the VSIX. Without this,
bumping the archive would break users on legacy 1.42.0-561 because
resource paths inside the archive change between releases. Resolution
mirrors SHA pinning: known versions get their pinned paths; any other
version raises SolidLSPException with a pointer to upstream-jdtls mode
(which derives paths dynamically and needs no pinning).
- Drop dead 'static/vscode-java/...' placeholder in initialize params; the
real runtimes[] is overwritten below from runtime_dependency_paths
.jre_home_path, which is correct in both default-VSIX and upstream-jdtls
modes.
- Test fixtures: Lombok provided dep in test_repo/pom.xml plus
LombokModel / FluentLombokModel / DefaultGreeter covering @Data, @Builder
(toBuilder=true), @With, @Delegate, @AllArgsConstructor, @NoArgsConstructor
and @Accessors(fluent=true). Regression test in test_java_basic.py
asserts every generated-method shape lands in document symbols.
Closes#1432
- Add 'Additional Workspace Folders' section to project configuration docs
- Add cross-reference note to TypeScript LS settings section
- Include configuration example and usage notes
The TypeScript language server was initialized with a single workspace folder,
so tsserver could not discover references across sibling packages in a monorepo.
This adds an `additional_workspace_folders` setting in
`ls_specific_settings` that accepts a list of directory paths.
Each folder is registered as an LSP workspace folder during initialization,
and a representative .ts file is opened from each to trigger tsserver project
loading. This enables `find_referencing_symbols` and `request_references` to
return results from across package boundaries.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Per the LSP spec, Content-Type is optional and defaults to
application/vscode-jsonrpc; charset=utf-8 (the exact value we were
sending). Spec-compliant servers behave identically with or without it.
In practice some servers have stricter parsers. Notably, Godot's
GDScript LSP (LSPeer::handle_data in
modules/gdscript/language_server/gdscript_language_protocol.cpp)
extracts the body length via header.substr(16).to_int() and silently
drops messages that contain any header beyond Content-Length.
Sending only Content-Length is interoperable across the spec-compliant
servers we use today and unblocks Godot's LSP. Also tightens the type
signature of create_message from tuple[bytes, bytes, bytes] to
tuple[bytes, bytes] now that there is no Content-Type element.
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Per the LSP spec, Content-Type is optional and defaults to
application/vscode-jsonrpc; charset=utf-8 (the exact value we were
sending). Spec-compliant servers behave identically with or without it.
In practice some servers have stricter parsers. Notably, Godot's
GDScript LSP (LSPeer::handle_data in
modules/gdscript/language_server/gdscript_language_protocol.cpp)
extracts the body length via header.substr(16).to_int() and silently
drops messages that contain any header beyond Content-Length.
Sending only Content-Length is interoperable across the spec-compliant
servers we use today and unblocks Godot's LSP. Also tightens the type
signature of create_message from tuple[bytes, bytes, bytes] to
tuple[bytes, bytes] now that there is no Content-Type element.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* Apply common functionality already used in JetBrainsFindDeclarationTool
* Remove location-based tool (counteracts Serena's principle to eschew line numbers)
* Apply renaming to use "find declaration" instead of "find defining symbol"
When the Codex client sends shell work via `exec_command`, the tool name is
always `exec_command` and the actual command is under `tool_input.cmd`. The
previous `is_grep_tool` / `is_read_file_tool` checks inspected only the tool
name and therefore never fired for Codex grep/read workflows.
Add `_GREP_SHELL_COMMANDS` and `_READ_SHELL_COMMANDS` frozensets and a helper
`_get_exec_command_name()` that extracts the basename of the first token in
`cmd`. Both detection methods now use these to classify `exec_command` calls
when the client is `HookClient.CODEX`, leaving all other client paths unchanged.
Co-Authored-By: Octopus <liyuan851277048@icloud.com>
* Breaking change: Projects (project.yml) can no longer override `base_modes`.
Instead, they can define `added_modes` to add modes on top of base and default modes.
This allows `base_modes` to be fully applied for the computation of the base toolset
as they are no longer dynamic.
* Serena's default configuration now uses `interactive` and `editing` as `base_modes`
instead of as `default_modes`.
* Fix: send languageId 'typescriptreact' / 'javascriptreact' for .tsx / .jsx
Without this, .tsx files are opened with languageId 'typescript', so
tsserver parses JSX as syntax errors and recovers by truncating the
enclosing symbol's range at the first multi-line JSX expression. The
resulting symptoms:
- find_symbol(name, include_body=True) on a React component returns a
body that ends mid-component, hiding everything below.
- The same component shows up as multiple Method-kind symbols (one per
call site) plus a separately-tracked Constant for the definition,
because tsserver mistakes JSX-tag tokens for member access.
Reproducer (before fix, real-world TSX file):
SidebarPDF range = [11:1-25:207] (truncated at first JSX, line 25)
After fix:
SidebarPDF range = [11:1-281:2] (full body)
The base SolidLanguageServer._get_language_id_for_file is explicitly
designed for this — its docstring says "Override in subclasses to
return file-specific language IDs." This change just exercises that
hook for the React file extensions.
Adds a regression test + jsx_component.tsx fixture covering the same
arrow-function-with-multi-line-JSX-ternary pattern that triggers the
truncation in real codebases (see oraios/serena#1029 for an earlier
report whose root cause was not identified).
Dominik Jain