Bunch 0.2.0 - #5
Merged
Merged
Conversation
Since 2025.3, intellijIdea() bundles what used to be Ultimate-only plugins, none of which this plugin depends on or asked for. The Vue.js plugin's VueLspServerSupportProvider intermittently threw ExceptionInInitializerError during lazy init inside the headless test sandbox; doHighlighting() (used by several feature tests) touches every registered extension point, so the resulting logged error failed whichever test happened to be running at the time -- not a real regression, and not always the same test. Confirmed by two green CI runs against d73a807's test sources and two failures after, on unrelated commits that never touched plugin code.
The check reads sourceCompatibility from :plugin:compileJava's module, not the
platform-version-relevant Kotlin code, and IntelliJ's Gradle sync does not
evaluate the configureEach {} block that already sets release = 8 -- so
without an explicit java {} block on each Java-8 module, the IDE assumed the
project default (21) and its inspections suggested syntax those modules
can't compile.
Also modernizes the mavenExt source set and jar task declarations, replacing
the deprecated by ...creating / by ...registering Kotlin DSL delegates with
the plain create()/register() calls the Gradle Kotlin DSL now recommends
(behavior unchanged), and gives the mavenExtJar task the description every
other custom task in this file already has.
The old description was three bullet points from before the debugger, Java interoperability, and Maven injection existed. renderMarketplaceDescription lets the new one be reviewed as rendered HTML without publishing anything.
Both were compile-only/test-only already (never bundled into the shipped plugin), but this sandbox previously had no Maven Central access to verify a version bump would still build. maven-core 3.6.3 -> 3.9.16 and plexus-utils 3.3.0 -> 3.6.1 (latest of their respective 3.x lines) compile and test clean, and also drop the transitive guava/maven-shared-utils to non-vulnerable versions while removing the commons-io/commons-lang3 transitives entirely. Verified end-to-end via agent/checks/run-all.sh, including 02-maven-plugin-realm.sh (real mvn process, real plugin realm), now fully green in this environment for the first time.
Diamond operators, unnecessary boxing/unboxing, enhanced for-loops, try-with-resources, NIO Files-based stream construction, StandardCharsets, redundant throws/casts/null-checks, and raw-type generics -- all mechanical, behavior-preserving quick fixes reported by an IntelliJ inspection export.
Diamond-equivalent generic inference, multi-dollar string interpolation, property-access syntax, Enum.entries, destructuring, redundant if/when simplification, and moving companion objects that held only constants to top-level file-scope declarations -- all mechanical, behavior-preserving quick fixes reported by an IntelliJ inspection export.
CMD_*/EVT_* in BshHook were superseded by DebugChannel.Command.Kind and only still referenced from this file's own Javadoc; NativeChannel keeps its own live copies for its own encoding, so those stay. Also drops DapChannel's unused MODE_RUN (its siblings are live) and Json.getBoolean (no callers, unlike its getInt/getString/getList siblings). Fixed the Javadoc @links left dangling by the removed constants to point at DebugChannel.Command.Kind instead. In the plugin's Kotlin sources: BshJavaResolver.resolveMember had no callers (call sites use resolveClassPsi + member directly); BshTokenTypes.NUMBERS/ BRACES were never wired into the highlighter, unlike their COMMENTS/ STRING_LITERALS/WHITESPACES siblings; BshDebugInstrumentation.SOURCES_PROPERTY was never read by name, only duplicated as a literal at its one call site; BshLineBreakpointType's PsiFile import was unused. Verified against the actual bytecode-injection/reflection call sites (ASM transformer, Sisu DI, BeanShell source-rewriting, plugin.xml extensions, JUnit) before deleting anything -- an exported whole-project "Inspect Code" run flags many things here as unused that are simply invisible to static analysis, not actually dead.
…lugin BshHook.java: channel is assigned exactly once (across mutually exclusive branches of the same static initializer) and callStackTop is read only once, right where it's computed, so both lose their unnecessary staying-power: channel becomes final, callStackTop becomes a local instead of a class field. Suppressed two inspections whose suggestion would make the code worse: the mailbox queues are unbounded LinkedBlockingQueues, so offer()'s boolean result has no failure case worth checking; waitForConfiguration()'s Thread.sleep(20) is a deliberately bounded poll against a 30s deadline, not an unbounded spin. BshAmbiguousName extends BshNamedElement, so isReadWriteAccessible()'s second disjunct could never independently contribute anything -- simplified to the single check. Added clarifying parentheses around the offset+1 fallback in BshLineBreakpointType, per the operator-precedence inspection's suggestion. BshDebugRunner.kt: agentJar's null-check already flows through the local useAgent val, making the later !! redundant. BshMavenRunConfiguration.kt: MavenRunnerParameters.runnerParameters is @NotNull, making the safe call redundant too -- kept the workingDirPath ?: return fallback deliberately (suppressed, with a comment) since that nullability guarantee is upstream's to keep, not this code's. BshUnusedVariableInspection.kt: the preceding is/!is guard already lets Kotlin smart-cast to the common BshNamedElement supertype. BshParameterInfoHandler.kt: removed two ParameterInfoHandler overrides marked deprecated for removal upstream -- couldShowInLookup() returned true but getParametersForLookup() always returned null, so they were already a no-op; the interface has default implementations. BshMavenInjector used !isBlank() where isNotBlank() says the same thing more directly; BshScriptRewriterTest called setConfiguration() instead of the Kotlin property syntax the Maven model's Java bean already supports.
Surround With menu entries and parser error messages need title/sentence capitalization per platform convention; the file-chooser dialog title and the Maven action text used the internal "bsh" short name where every sibling dialog/action in the same files uses the full "BeanShell" name. The three bundled local inspections had no inspectionDescriptions/*.html, the introduce-variable intention was missing its before/after example templates (description.html already existed), and the postfix template provider had neither a description nor examples. These back the tooltip JetBrains' own inspections/intentions/postfix templates show in Settings.
…nd VS Code extension Mark the fire-and-forget showErrorMessage calls in configurationProvider.ts as intentional: each call is immediately followed by a synchronous return, there is no button/action to react to, so there is nothing to await; void makes that explicit instead of leaving the returned promise looking abandoned. Also suppresses SameParameterValue, SameReturnValue, and JSUnusedGlobalSymbols where the inspections' suggestions don't apply.
'index' was never read inside the DAP client check script's loop body. ShellCheck (SC2164): guard cd against failure in the check-runner shell scripts -- if dirname's output somehow doesn't exist, the script would silently keep running from the wrong directory instead of stopping. run-all.sh: expand the glob into an array first so ShellCheck doesn't flag the for-loop's unquoted expansion. check-instrumentation.py: report()'s loop variable shadowed the outer for-loop's 'number'. mock-ide.py: merged the "frames" key into the dict literal it was appended to right after (same read order preserved), dropped redundant tuple parens on a bare return, and suppressed two PyCharm false positives -- a "Format spec not supported for Queue" on an f-string whose operands are plain ints, and "Session doesn't have attribute pack" on resume(s, ...) call sites, when resume() only ever calls s.send() and struct.pack() (on the struct module, never on s). docs/BEANSHELL-DEFECTS.md: mark the repro's code fence as jshelllanguage so it doesn't get flagged as unparseable Java, and annotate it with @SuppressWarnings("EmptyFinallyBlock") since the empty finally is the point of the repro.
BshHook.java: {@link #connect} pointed at a method that lives on
DebugChannel, not BshHook itself. Two Javadoc comments had gone dangling --
one describing a write-serialization lock that was refactored away (each
channel implementation now has its own writeLock), the other a stale
duplicate of the per-thread handles field's doc, both left behind by an
earlier refactor with nothing left to attach to. DebugChannel.java:
{@link Answer} referenced a type that was never added; the word was meant
as plain prose.
[lineFor] can't resolve from BshDebugInstrumenter's class-level KDoc comment
-- it's a parameter name, only linkable from within the function that
declares it.
editors/{eclipse,neovim,vscode}/README.md linked bare sibling directories
(e.g. ../vscode/); IntelliJ's markdown resolver doesn't apply GitHub's
directory-implies-README convention, so point at the README.md files
directly -- still renders identically on GitHub. docs/PROTOCOL.md's link to
FUTURE_WORK.md used a stale anchor from before that section was renamed to
"DAP as a second transport -- done".
Also added a few missing commas before coordinating conjunctions joining
independent clauses, in DebugHost.java and across the docs.
Comments and docs had drifted between British and American spelling (behaviour/behavior, serialise/serialize, etc.); pick American consistently and rename the one file/function that carried the British spelling into its name, including the remaining -ise spellings a first pass missed. Reword "the code around them" to "the surrounding code" in BshDebugProtocol.kt, and rewrap a comment in BshDebugInstrumentation.kt that ran past the line-length convention. BshDebugAgent: reword "one that does gets a fresh id" -- grammatically fine but a garden-path parse -- to "one that reports again gets a fresh id". BshDebugProcess: split the lastStoppedThread doc comment's 42-word sentence in two at the "but" clause. Also fixes Markdown table formatting across the READMEs and docs.
…Provider com.intellij.codeInsight.hints is marked @ApiStatus.Experimental and UnstableApiUsage fired on every member of the old provider. The stable replacement is the declarative codeInsight.hints.declarative API (InlayHintsProvider + SharedBypassCollector), registered through codeInsight.declarativeInlayProvider instead of codeInsight.parameterNameHints. That EP requires a bundle-backed display name, so this adds the plugin's first resource bundle with a single key for it -- "Parameter Name Hints", using the title capitalization the platform convention expects for Inlay Hints group display names (PluginXmlCapitalization).
…i18n Move inspection displayName/groupName, the intention category, the Maven action's text/description, and each BeanShell live template's description off of hardcoded XML strings and onto messages.BshBundle keys, resolving DevKit's i18n-extraction warnings (PluginXmlI18n and LiveTemplateI18n).
The word "Support" wasn't recommended anyway.
The demo project has grown since these were last captured (Maven multi-module samples, thread/instrumentation fixtures), so the project tree in editor.png/completion.png/etc. was stale. debugger.png's Variables panel also carried leftover watch expressions (sdf, sdf, sdfeddf) from a past debugging session, unrelated to the showcased factorial() example.
Manually enabling the disabled-by-default inspection against the debugger fixtures turned up super(...) calls in scripted-class constructors never resolving, eval/source string-literal bodies being injectable the same way BshMavenInjector already does for Maven inline scripts, and built-in commands (print, exec, source, ...) having no PSI for BshResolver to find.
BshStackFrame.computeChildren flattened both the Locals and Global scopes into one child list without deduplication. Since a method's namespace closes over the enclosing (often global) namespace, its parent-chain walk already reports script-level variables under Locals, so the same name reappeared a second time under Global.
BshStackFrame.computeChildren discarded the scope name returned by BshValueSource.scopes and flattened every scope's variables straight into the frame's children, so the Locals/Global distinction the agent already reports never reached the UI. Wrap each scope's remaining variables (after the existing cross-scope dedup) in an auto-expanded XValueGroup instead, matching how other debuggers group the same underlying scope split. Drives BshStackFrame and BshValue against a scripted BshValueSource and a recording XCompositeNode to cover the dedup, the grouping, and the value-modifier's literal-escaping/type-dispatch logic -- none of which had any test before.
BshDebugProcess decoded every agent reply and decided which reported frame belongs to the file being debugged, but nothing exercised that decoding directly: the existing end-to-end test drives the real agent protocol with its own hand-rolled reader instead of BshDebugProcess's, so a framing mistake here (field order, an off-by-one in frame line resolution) would pass unnoticed. Pull the reply decoders and frame-line resolution into BshDebugWireCodec.kt, free of XDebugSession and sockets, and pin their behavior down with plain-JUnit tests -- the same split BshStepLogic already uses for step decisions.
… action Reuses BshIcons.MAVEN, already shown on the run configuration type itself.
collectScopes now walks the whole namespace chain -- Locals, then any Block/Closure level a for/if body or a closure's captured namespace sits between it and the top, then Global -- instead of flattening straight from Locals to Global. Each level (BshHook.collectNamespaceLevel) reports only its own directly-declared variables, so a for-loop's own init variable shows up under its Block rather than being lost inside whichever level's ancestor-walk happened to reach it first.
debugger.png was stale -- captured before Locals/Global were split into their own groups, so it showed everything flattened under one "Locals" node including the script's own globals. Recaptured on the same factorial sample, with Locals and Global now visibly separate. Adds maven-debug.png, proving the same nested-scope grouping survives running through a Maven plugin realm: build-helper's for-loop shows its own Block level alongside Global. Both samples' inline scripts grew a for loop + print so there is something worth stepping through and inspecting. maven-completion.png (README already referenced it) is added too. Documents that genthaler:beanshell-maven-plugin is the one exception -- it actually runs on BeanShell 1.3.0 because of a dependency conflict in its own tree, so a typed for-loop variable doesn't surface, and its own sample script is adjusted to the untyped form that does.
Mirrors plugin/README.md's screenshots, cycling through them as a single animated GIF with clickable thumbnails below -- GitHub's markdown sanitizer strips <style>/<script>, so a hover-to-preview swap isn't possible there.
The Marketplace description embeds screenshots via raw.githubusercontent.com
pinned to a git tag, so they don't move under a later push once a version is
live. The tag was hand-typed (v0.1.1) and had already drifted from main by
the time of the next screenshot refresh. plugin.xml now carries an
"@IMAGE_TAG@" placeholder that processResources substitutes with
"v${project.version}" -- a real tag once release.yml passes
-Pversion=X.Y.Z, matching the tag it's about to push. renderMarketplaceDescription
resolves the same placeholder to a relative path instead, so the local preview
needs no network access and doesn't depend on an unreleased tag existing yet.
Extends the JDK 8 toolchain forking from agent:hook and agent:instrument to agent:samples and the plugin's two JDK 8 compile tasks (compileMavenExtJava and compileJava), for the same reason: JDK 21's javac emulating -source/-target 8 via `release` prints "source/target 8 is obsolete" since JDK 20, whereas an actual JDK 8 javac doesn't know anything about its own future deprecation. The plugin's two tasks need one extra step beyond javaCompiler.set(...): the IntelliJ Platform Gradle plugin sets options.release's *convention* to 21 project-wide via configureEach, and options.release.set(null) only clears an explicit value, falling back to that convention. Only options.release.convention(null as Int?) replaces the convention outright and makes the property truly absent -- necessary because Gradle emits --release <value> whenever the property has any value, and a JDK 8 javac doesn't understand that flag regardless of the number.
The IDEA plugin's Variables view grouping (Locals/Global, nested Block/Closure scopes) and the missing Maven-configuration action icon fix, plus the wire-protocol change behind the grouping (BshHook now reports each Block/Closure level on its own), are ready to ship. The VS Code extension has no changelog-worthy changes since 0.1.1, so it stays unreleased and its CHANGELOG.md is left untouched -- see docs/RELEASING.md. Also bumps gradle.properties' dev version to 0.2.0-SNAPSHOT to match -- purely a local default per docs/RELEASING.md, since the actual release build passes -Pversion explicitly, but there is no reason to leave it pointing at the version already released as 0.1.1.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.