Build tools

Each detected build tool gets its own tasks tool window (its stripe appears when the tool’s marker file is present, docked on the right by default): a browsable tree of the tool’s goals, scripts, or targets with a mini toolbar (Run / Reload / Stop / Run custom…). Double-click or Enter runs a task, and the output streams to the shared Output window, which has one tab per tool (created on first run and selected while it runs), so two builds running at once stay in separate tabs instead of interleaving. A searchable actions popup is also available from the palette (<tool>.showActions, e.g. Maven: Show Actions). tool.<tool> opens the tasks window; tool.buildOutput opens the Output console. It’s on by default, and each tool is inert until its marker file is found.

The console holds more than build output, and was called “Build Output” until 0.10.0. Alongside a tab per build tool it carries a CI tab for a failed GitHub Actions log, and a Git and GitHub tab holding a transcript of the git / gh commands Editora ran on your behalf, each with its output, exit code and duration. Only the window’s label changed; its stripe placement and any keybinding you gave tool.buildOutput are unaffected.

Maven and Gradle prefer the project’s own ./mvnw / ./gradlew wrapper, falling back to mvn / gradle on your PATH. npm uses the detected package manager (npm / yarn / pnpm / bun) from the packageManager field or the lockfile.

A wrapper is a script the repository ships, and it runs with your privileges. The first time a task (or Gradle’s Load all tasks…) would run one, Editora shows a Workspace Trust notice naming the script and waits for your answer. Trust is remembered for the folder that ships the wrapper and the folders inside it. Declining cancels the run; it does not fall back to the mvn or gradle on your PATH. A project without a wrapper is not asked. Review or revoke trust under Trusted folders.

Choose the JDK used for Maven under Settings → Languages & Tools → Build Tools → Default JDK. The selector finds installed JDKs in standard platform locations and through SDKMAN, asdf, mise, Jabba, and JetBrains-managed installs; System default keeps using JAVA_HOME / PATH. The choice supplies both JAVA_HOME and the matching java executable to Maven tasks, Maven classpath resolution, Java Run and Debug, and before-launch commands. A saved run configuration can override it for one project or launch.

Discovery parses the marker file directly, with no shell-out and no new dependency, so it’s instant and offline. Toggle each under Settings → Languages & Tools → Build Tools.

Maven

Every goal a plugin offers

A literal reading of pom.xml can show only a goal written inside an explicit <execution>. A plugin declared for direct invocation, such as javafx-maven-plugin, spring-boot-maven-plugin or exec-maven-plugin, carries only <configuration> and no executions, so that reading gives it no row, and javafx:run would be reachable only by typing it into Run custom….

Each plugin therefore gets a collapsed section listing every goal it offers, read from the plugin’s own descriptor, with each goal’s description as its tooltip. Because the goals come from the descriptor and not from a built-in table of well-known goals, the section covers whatever plugins are in your pom.

The flat Plugins section and these per-plugin groups overlap by design and answer different questions: the flat one is what this build runs (with the phase and execution id in its tooltip), a group is what this plugin can run.

It reads your local repository only, never the network, so opening a project never fetches anything and a plugin you have not downloaded contributes nothing. Results are cached, since detection re-runs on every save and tab switch. A goal belonging to a plugin declared only inside a profile is not listed, even when that profile is checked.

The Maven submenu

A Maven submenu appears wherever there’s a pom in hand: on a pom.xml in the editor’s right-click menu, and on a folder or a pom.xml row in the Project tree. It carries Update Versions, Actions, Run…, Re-run, and Stop.

One builder serves all three surfaces, so they always offer the same actions. It offers nothing when Maven is off, when there’s no pom above the folder, or on a file that isn’t itself a pom.xml.

Update the versions in an existing project

maven.updateVersions checks the nearest pom.xml’s dependencies and plugins against Maven Central and shows what would change before writing anything. A dialog lists a row per artifact, current → latest, and you can decline it. Nothing is written until you accept.

The update is applied through the open buffer as a single edit, so one C-z takes the whole thing back and the buffer is left dirty for you to save. Only a pom that isn’t open is written to disk.

It has three limits:

• Maven Central’s <release> marker is not trusted. It means “newest non-snapshot published”, which for maven-surefire-plugin was a milestone for years; the full version list is filtered for stability instead.
• A version is never walked backwards, which an unguarded set-to-latest would do to a pom pinned on purpose.
• A property-driven version (${junit.version}) is skipped. Rewriting the reference would replace the indirection you chose, and rewriting the property is a different edit that can reach other artifacts.

Each artifact is resolved independently and best-effort, so one unreachable coordinate leaves that version alone rather than failing the rest. A plugin with no <version> is left alone too, because its version comes from a parent and writing one would change how the plugin is resolved.

The same option is offered up front when generating a new project.

Test runner

Running a build tool’s test task, from the tasks tree, the palette (test.run), or a gutter icon, is intercepted and shown in a dedicated Test Results tool window (M-g e) instead of only as raw console text. The same single process still runs, and its raw output still streams to the Output console.

The window shows a status header with pass / fail / skip counts, a progress bar, and elapsed time, over a tree of suites and tests. Selecting a test shows its failure message, stack trace, and captured output in the detail pane, with clickable stack frames. Double-click or Enter on a test jumps to its source. A right-click on a test row offers Go to Test, Rerun This Test and Debug This Test; on a class row, Go to Test Class, Rerun This Class and Debug This Class. The Debug entry appears where the Java debugger is available. A test’s output, failure message and stack trace are kept up to 200,000 characters; past that the start and the end are shown, with a line between them saying how much was left out.

Results are parsed per tool: Maven and Gradle read the JUnit XML reports as they are written, Go uses go test -json, npm reads TAP when the reporter emits it, and Cargo parses libtest output. Where a structured format isn’t available, the window says so and points at the Output console.

For an unfiltered JVM run, Editora scans the project’s test sources up front and pre-seeds the whole expected list greyed-out, flipping each entry green or red as results land, so a long run reads like a progress bar rather than classes appearing already finished. Parameterized and dynamic tests are left out of the seed, since their case ids are generated at runtime.

JUnit test classes and methods also get a run icon in the gutter (with a tooltip naming what it runs), and a test file’s right-click menu offers Run Tests for the whole class. test.runAtCaret and test.runClassAtCaret do the same from the keyboard, and test.rerun, test.rerunFailed, and test.stop control the run. Gutter icons are JVM-only and need a detected Maven or Gradle project.

Tests in nested classes have their own icons: a method inside a JUnit @Nested class, or inside a static nested test class, gets a ▶, and so does the nested class itself. Run and Debug address the nested class as Outer$Inner, so only that class’s tests run. A class whose tests are all in nested classes is marked the same way.

Debug Test at Caret (test.debugAtCaret) and the test-results context menu launch the selected JUnit method or class through Maven or Gradle with its JVM suspended, then attach Editora’s Java debugger automatically. This needs the same Java debug adapter as ordinary Java debugging.

Toggle the whole feature under Settings → Languages & Tools → Build Tools (view.toggleTestRunner). It’s off in Simple UI mode.