habit-hooks-java 1.3.0__tar.gz → 1.4.0__tar.gz

habit_hooks_java-1.4.0/PKG-INFO

@@ -0,0 +1,50 @@
+Metadata-Version: 2.5
+Name: habit-hooks-java
+Version: 1.4.0
+Summary: The Java Habit Hooks plugin
+Project-URL: Homepage, https://habit-hooks.com
+Project-URL: Repository, https://github.com/habit-hooks/habit-hooks
+Project-URL: Issues, https://github.com/habit-hooks/habit-hooks/issues
+Project-URL: Changelog, https://github.com/habit-hooks/habit-hooks/blob/main/CHANGELOG.md
+License-Expression: MIT
+Keywords: ai-coding-agents,ci,code-quality,code-review,code-smells,coding-agents,developer-tools,java,linter,refactoring,static-analysis,technical-debt
+Classifier: Development Status :: 4 - Beta
+Classifier: Environment :: Console
+Classifier: Intended Audience :: Developers
+Classifier: Operating System :: OS Independent
+Classifier: Programming Language :: Python :: 3
+Classifier: Programming Language :: Python :: 3.11
+Classifier: Programming Language :: Python :: 3.12
+Classifier: Programming Language :: Python :: 3.13
+Classifier: Topic :: Software Development :: Quality Assurance
+Classifier: Topic :: Software Development :: Testing
+Classifier: Topic :: Utilities
+Requires-Python: >=3.11
+Description-Content-Type: text/markdown
+
+# habit-hooks-java
+
+The Java Habit Hooks plugin: wraps [`pmd`](https://pmd.github.io/) for
+structural code-smell detection.
+
+## Install
+
+```sh
+pip install "habit-hooks[java]"
+```
+
+## Enable
+
+```toml
+# .habit-hooks/config.toml
+plugins = ["java", "generic"]
+```
+
+Installing a plugin does not switch it on — it has to be named in
+`plugins` before habit-hooks runs it.
+
+## Detectors
+
+- [`pmd`](https://pmd.github.io/) — `brew install pmd` (it brings its own Java runtime)
+
+Part of [habit-hooks](https://github.com/habit-hooks/habit-hooks).

habit_hooks_java-1.4.0/README.md

@@ -0,0 +1,26 @@
+# habit-hooks-java
+
+The Java Habit Hooks plugin: wraps [`pmd`](https://pmd.github.io/) for
+structural code-smell detection.
+
+## Install
+
+```sh
+pip install "habit-hooks[java]"
+```
+
+## Enable
+
+```toml
+# .habit-hooks/config.toml
+plugins = ["java", "generic"]
+```
+
+Installing a plugin does not switch it on — it has to be named in
+`plugins` before habit-hooks runs it.
+
+## Detectors
+
+- [`pmd`](https://pmd.github.io/) — `brew install pmd` (it brings its own Java runtime)
+
+Part of [habit-hooks](https://github.com/habit-hooks/habit-hooks).

{habit_hooks_java-1.3.0 → habit_hooks_java-1.4.0}/docs/java-plugin.spec.md

@@ -211,5 +211,5 @@ habit-sensors --all 2>&1 >/dev/null | sed -n 1p
 
 🖥️ ❌ 1
 ```text
-habit-sensors: sensor 'pmd' failed: ${python} ${dir}/pmd_sensor.py ${args} -- ${files}
+habit-sensors: sensor 'pmd' failed: '${python}' '${dir}/pmd_sensor.py' '${detector:pmd}' '${args}' -- '${files}'
 ```

habit_hooks_java-1.4.0/pyproject.toml

@@ -0,0 +1,51 @@
+[project]
+name = "habit-hooks-java"
+version = "1.4.0"
+description = "The Java Habit Hooks plugin"
+readme = "README.md"
+license = "MIT"
+keywords = [
+    "code-quality",
+    "code-smells",
+    "static-analysis",
+    "linter",
+    "ci",
+    "code-review",
+    "technical-debt",
+    "refactoring",
+    "ai-coding-agents",
+    "coding-agents",
+    "developer-tools",
+    "java",
+]
+classifiers = [
+    "Development Status :: 4 - Beta",
+    "Environment :: Console",
+    "Intended Audience :: Developers",
+    "Operating System :: OS Independent",
+    "Programming Language :: Python :: 3",
+    "Programming Language :: Python :: 3.11",
+    "Programming Language :: Python :: 3.12",
+    "Programming Language :: Python :: 3.13",
+    "Topic :: Software Development :: Quality Assurance",
+    "Topic :: Software Development :: Testing",
+    "Topic :: Utilities",
+]
+requires-python = ">=3.11"
+dependencies = []
+
+[project.entry-points."habit_hooks.plugins"]
+java = "habit_hooks_java"
+
+[project.urls]
+Homepage = "https://habit-hooks.com"
+Repository = "https://github.com/habit-hooks/habit-hooks"
+Issues = "https://github.com/habit-hooks/habit-hooks/issues"
+Changelog = "https://github.com/habit-hooks/habit-hooks/blob/main/CHANGELOG.md"
+
+[build-system]
+requires = ["hatchling"]
+build-backend = "hatchling.build"
+
+[tool.hatch.build.targets.wheel]
+packages = ["src/habit_hooks_java"]

habit_hooks_java-1.4.0/src/habit_hooks_java/sensors/pmd.toml

@@ -0,0 +1 @@
+argv = ["${python}", "${dir}/pmd_sensor.py", "${detector:pmd}", "${args}", "--", "${files}"]

habit_hooks_java-1.4.0/src/habit_hooks_java/sensors/pmd_ruleset.py

@@ -0,0 +1,50 @@
+"""Decide which ruleset PMD is run with.
+
+PMD never discovers a project ruleset on its own — ``-R`` is required — so the
+answer is chosen here: a ``--rulesets``/``-R`` among the sensor's ``args`` (the
+project naming its config explicitly) wins; then the first conventional ruleset
+file the Java ecosystem's build tools point at, in the project directory only;
+then the plugin's bundled ``pmd-ruleset.xml`` as the answer to "the project has
+none".
+"""
+
+from __future__ import annotations
+
+from pathlib import Path
+
+# The ruleset names Maven and Gradle PMD setups conventionally point at, in
+# the order a project directory is checked. PMD itself offers no discovery
+# signal (it never looks one up), so this is the knip-shaped search for the
+# project's own config; a ``--rulesets`` in the sensor's args overrides it.
+RULESET_LOCATIONS = (
+    "src/main/resources/pmd/ruleset.xml",
+    "pmd/ruleset.xml",
+    "ruleset.xml",
+    "pmd.xml",
+)
+
+RULESET_OPTIONS = ("--rulesets", "-R")
+# The attached spellings picocli also takes, longest prefix first so `-R=x` is
+# not read as a bare `-R` with `=x` on it. A spelling missed here does not fall
+# back: the project's `-R` stays in the tail, ours goes in beside it, and PMD
+# unions the two rulesets rather than using theirs.
+ATTACHED_RULESET_PREFIXES = ("--rulesets=", "-R=", "-R")
+
+
+def ruleset_of(argv: list[str], project: Path) -> tuple[Path, list[str]]:
+    """The ruleset in force, and the remaining args with no ruleset named.
+
+    A ``--rulesets``/``-R`` among the sensor's args is the project's own config
+    and wins over everything; PMD only ever gets one, so it is pulled out of
+    the tail rather than left beside the wrapper's own.
+    """
+    for i, token in enumerate(argv):
+        if token in RULESET_OPTIONS and i + 1 < len(argv):
+            return Path(argv[i + 1]), [*argv[:i], *argv[i + 2 :]]
+        for prefix in ATTACHED_RULESET_PREFIXES:
+            if token.startswith(prefix) and len(token) > len(prefix):
+                return Path(token[len(prefix) :]), [*argv[:i], *argv[i + 1 :]]
+    for name in RULESET_LOCATIONS:
+        if (project / name).is_file():
+            return project / name, argv
+    return Path(__file__).with_name("pmd-ruleset.xml"), argv

{habit_hooks_java-1.3.0 → habit_hooks_java-1.4.0}/src/habit_hooks_java/sensors/pmd_sensor.py

@@ -4,25 +4,25 @@ PMD exits 4 when it finds violations, 0 when clean, and 1/2/5 on exceptions,
 usage errors and recoverable errors (since 7.3.0) — so a bare pipe cannot tell
 a clean run from a crash. This wrapper runs PMD against the scoped files,
 treats only 0/4 as success, and shapes each violation into the canonical
-finding, mapping PMD rule names to smell keys.
+finding, mapping PMD rule names to smell keys. Which ruleset it runs with is
+the neighbouring ``pmd_ruleset``'s decision.
 
-PMD never discovers a project ruleset on its own — ``-R`` is required — so the
-ruleset is resolved here: a ``--rulesets`` among the sensor's ``args`` (the
-project naming its config explicitly) wins; then the first conventional ruleset
-file the Java ecosystem's build tools point at, in the project directory only;
-then the plugin's bundled ``pmd-ruleset.xml`` as the answer to "the project has
-none".
+The sensor is run as a loose script (``${python} ${dir}/pmd_sensor.py``), so its
+own directory is ``sys.path[0]`` and that neighbour is a plain top-level import
+— the same in the installed package and in a vendored copy, since ``${dir}``
+expands to whichever of the two won the override chain.
 
 PMD 7's picocli reads a positional path that directly follows the ruleset value
 as another ``-R`` value (``-R ruleset.xml file.java`` analyses nothing), so the
 wrapper uses the short forms ``-R`` and per-file ``-d``, which do not. Verified
 against PMD 7.26.0.
 
-The sensor's own command spells ``${args} -- ${files}``, so ``sys.argv[1:]``
-carries both halves of ``[sensors.pmd] args`` on one side of a literal ``--``
-and the scoped files on the other — that is what lets a project pass any PMD
-flag (``--aux-classpath``, ``--minimum-priority``, ...) through untouched
-instead of every argv token becoming a bogus ``-d`` file argument.
+The sensor's own argv spells ``${detector:pmd} ${args} -- ${files}``, so
+``sys.argv[1]`` is the file to run PMD by and ``sys.argv[2:]`` carries both
+halves of ``[sensors.pmd] args`` on one side of a literal ``--`` and the scoped
+files on the other — that is what lets a project pass any PMD flag
+(``--aux-classpath``, ``--minimum-priority``, ...) through untouched instead of
+every argv token becoming a bogus ``-d`` file argument.
 """
 
 from __future__ import annotations
@@ -32,6 +32,8 @@ import subprocess
 import sys
 from pathlib import Path
 
+from pmd_ruleset import ruleset_of
+
 RULE_SMELLS = {
     "ExcessiveParameterList": "too-many-parameters",
     "CyclomaticComplexity": "high-complexity",
@@ -49,43 +51,25 @@ RULE_SMELLS = {
 METHOD_LEVEL_RULES = ("NcssCount", "CyclomaticComplexity")
 METHOD_LEVEL_PREFIXES = ("The method", "The constructor")
 
-# The ruleset names Maven and Gradle PMD setups conventionally point at, in
-# the order a project directory is checked. PMD itself offers no discovery
-# signal (it never looks one up), so this is the knip-shaped search for the
-# project's own config; a ``--rulesets`` in the sensor's args overrides it.
-RULESET_LOCATIONS = (
-    "src/main/resources/pmd/ruleset.xml",
-    "pmd/ruleset.xml",
-    "ruleset.xml",
-    "pmd.xml",
-)
-
 SUCCESS_EXIT_CODES = (0, 4)
-RULESET_OPTIONS = ("--rulesets", "-R")
-# The attached spellings picocli also takes, longest prefix first so `-R=x` is
-# not read as a bare `-R` with `=x` on it. A spelling missed here does not fall
-# back: the project's `-R` stays in the tail, ours goes in beside it, and PMD
-# unions the two rulesets rather than using theirs.
-ATTACHED_RULESET_PREFIXES = ("--rulesets=", "-R=", "-R")
-
-
-def run_pmd(arguments: list[str]) -> subprocess.CompletedProcess[str]:
-    """What PMD said, or what a shell says about a PMD nobody installed.
-
-    The plugin does not ship the distribution, so ``pmd`` is the command that
-    goes missing — and an absent one raised a ``FileNotFoundError`` out of
-    here, making twenty lines of Python internals the sensor's diagnosis
-    (#114). This wrapper is what looks for pmd, so it answers the way the
-    shell would have, and that phrase is what the run recognises to name the
-    missing tool.
+
+
+def run_pmd(pmd: str, arguments: list[str]) -> subprocess.CompletedProcess[str]:
+    """What PMD said, run as the file this sensor was handed.
+
+    ``pmd`` is a file and never a name to look up. The plugin declares the tool
+    its sensor reaches for, and the run resolves that declaration to the very
+    file the setup cleared it by before spawning this helper — which is how the
+    ``pmd.bat`` PMD ships is reached on Windows, where a spawn adds ``.exe`` to
+    a bare name and nothing else. A PMD nobody installed never reaches here: the
+    sensor fails first, named, as the missing command it is.
     """
-    command = ["pmd", "check", "--no-cache", "--format", "json"]
-    try:
-        return subprocess.run(
-            [*command, *arguments], capture_output=True, text=True
-        )
-    except FileNotFoundError:
-        return subprocess.CompletedProcess(command, 127, "", "pmd: command not found\n")
+    return subprocess.run(
+        [pmd, "check", "--no-cache", "--format", "json", *arguments],
+        capture_output=True,
+        encoding="utf-8",
+        errors="replace",  # one invalid byte must not take the sensor down
+    )
 
 
 def split_argv(argv: list[str]) -> tuple[list[str], list[str]]:
@@ -102,25 +86,6 @@ def split_argv(argv: list[str]) -> tuple[list[str], list[str]]:
     return argv[:index], argv[index + 1 :]
 
 
-def ruleset_of(argv: list[str], project: Path) -> tuple[Path, list[str]]:
-    """The ruleset in force, and the remaining args with no ruleset named.
-
-    A ``--rulesets``/``-R`` among the sensor's args is the project's own config
-    and wins over everything; PMD only ever gets one, so it is pulled out of
-    the tail rather than left beside the wrapper's own.
-    """
-    for i, token in enumerate(argv):
-        if token in RULESET_OPTIONS and i + 1 < len(argv):
-            return Path(argv[i + 1]), [*argv[:i], *argv[i + 2 :]]
-        for prefix in ATTACHED_RULESET_PREFIXES:
-            if token.startswith(prefix) and len(token) > len(prefix):
-                return Path(token[len(prefix) :]), [*argv[:i], *argv[i + 1 :]]
-    for name in RULESET_LOCATIONS:
-        if (project / name).is_file():
-            return project / name, argv
-    return Path(__file__).with_name("pmd-ruleset.xml"), argv
-
-
 def violations(report: dict) -> list[dict]:
     return [
         {"file": entry["filename"], "violation": violation}
@@ -165,14 +130,14 @@ def findings(entries: list[dict]) -> list[dict]:
 
 
 def main() -> int:
-    argv = sys.argv[1:]
+    pmd, argv = sys.argv[1], sys.argv[2:]
     if not argv:
         print("[]")
         return 0
     pmd_args, files = split_argv(argv)
     ruleset, remaining_args = ruleset_of(pmd_args, Path.cwd())
     file_args = [token for file in files for token in ("-d", file)]
-    result = run_pmd(["-R", str(ruleset), *remaining_args, *file_args])
+    result = run_pmd(pmd, ["-R", str(ruleset), *remaining_args, *file_args])
     if result.returncode not in SUCCESS_EXIT_CODES:
         sys.stderr.write(processing_errors(result.stdout) or result.stderr or result.stdout)
         return 2

habit_hooks_java-1.4.0/tests/conftest.py

@@ -0,0 +1,41 @@
+"""Load the pmd sensor the way it is actually run, and hand it what a run hands it.
+
+**A helper loads as a loose script.** The sensor spec spells
+``${python} ${dir}/pmd_sensor.py``, so the interpreter puts the helper's own
+directory first on ``sys.path`` and its neighbour ``pmd_ruleset`` is a plain
+top-level import. A unit test here does the same rather than reaching the code as
+``habit_hooks_java.sensors.pmd_sensor`` — a load path no run takes, and the only
+one that import fails under.
+
+**A helper is handed its tool as a file.** The spec names it with
+``${detector:pmd}``, which the run resolves before the helper is spawned
+(``project_paths.tool_executable``). A test spawning the helper directly stands
+in for the run, so it asks the same question and hands over the same file.
+Absent is a failure rather than a skip: CI installs PMD on both legs, so a
+machine without it is a suite that has quietly stopped gating.
+"""
+
+from __future__ import annotations
+
+import shutil
+import sys
+from pathlib import Path
+
+import pytest
+
+SENSORS = Path(__file__).resolve().parents[1] / "src" / "habit_hooks_java" / "sensors"
+
+sys.path.insert(0, str(SENSORS))
+
+
+@pytest.fixture(scope="session")
+def pmd() -> str:
+    """The file this machine runs PMD by, as the sensor's first argument.
+
+    ``shutil.which`` rather than the name on disk: PMD ships ``pmd.bat``, which
+    Windows finds by a lookup and cannot spawn by the bare name.
+    """
+    found = shutil.which("pmd")
+    if found is None:
+        pytest.fail("pmd is not on PATH — 'brew install pmd'")
+    return found

habit_hooks_java-1.4.0/tests/test_a_vendored_sensor_finds_its_neighbour.py

@@ -0,0 +1,59 @@
+"""The route that copies the plugin's files into a project must still import.
+
+Vendoring under ``.habit-hooks/<plugin>/`` is the extras-free install the README
+advertises: the copied files win the override chain, ``${dir}`` in the sensor
+command expands to wherever they landed, and the plugin package is typically not
+installed at all — that is the point of vendoring. The sensor imports
+``pmd_ruleset`` from beside itself, which has to resolve because a loose
+script's own directory is ``sys.path[0]``, never because ``habit_hooks_java``
+happens to be importable.
+
+``-S`` is what tells those two apart: it denies the child the site-packages this
+checkout has the plugin installed into, so an import reaching for the package
+fails here exactly as it would for a project that vendored instead of
+installing. Without it the copy would pass on the installed package's modules
+and prove nothing about the files it just copied.
+"""
+
+from __future__ import annotations
+
+import json
+import shutil
+import subprocess
+import sys
+from pathlib import Path
+
+SENSORS = Path(__file__).resolve().parents[1] / "src" / "habit_hooks_java" / "sensors"
+
+FIVE_PARAMETER_METHOD = """class Billing {
+    double charge(double a, double b, double c, double d, double e) {
+        return a + b + c + d + e;
+    }
+}
+"""
+
+
+def _vendored_sensor(project: Path) -> Path:
+    """The plugin's sensor files copied where a project vendoring them puts them."""
+    sensors = project / ".habit-hooks" / "java" / "sensors"
+    shutil.copytree(SENSORS, sensors, ignore=shutil.ignore_patterns("__pycache__"))
+    return sensors / "pmd_sensor.py"
+
+
+def test_a_vendored_sensor_reports_a_smell_with_no_package_around_it(
+    tmp_path: Path, pmd: str
+) -> None:
+    (tmp_path / "Billing.java").write_text(FIVE_PARAMETER_METHOD, encoding="utf-8")
+    sensor = _vendored_sensor(tmp_path)
+
+    result = subprocess.run(
+        [sys.executable, "-S", str(sensor), pmd, "--", "Billing.java"],
+        cwd=tmp_path,
+        capture_output=True,
+        encoding="utf-8",
+        errors="replace",
+    )
+
+    assert result.returncode == 0, result.stderr
+    findings = json.loads(result.stdout)
+    assert [finding["smell"] for finding in findings] == ["too-many-parameters"]

{habit_hooks_java-1.3.0 → habit_hooks_java-1.4.0}/tests/test_class_level_metric_violations_are_dropped.py

@@ -14,7 +14,7 @@ over-complex function anywhere in the file.
 
 from __future__ import annotations
 
-from habit_hooks_java.sensors.pmd_sensor import findings, smell_of
+from pmd_sensor import findings, smell_of
 
 
 def _entry(rule: str, description: str, beginline: int = 1) -> dict:

{habit_hooks_java-1.3.0 → habit_hooks_java-1.4.0}/tests/test_every_ruleset_spelling_wins.py

@@ -15,7 +15,7 @@ from __future__ import annotations
 from pathlib import Path
 
 import pytest
-from habit_hooks_java.sensors.pmd_sensor import ruleset_of
+from pmd_ruleset import ruleset_of
 
 BUNDLED = "pmd-ruleset.xml"
 THEIRS = "mine.xml"
@@ -59,7 +59,7 @@ def test_a_project_naming_none_gets_the_bundled_ruleset(tmp_path: Path) -> None:
 def test_a_conventional_ruleset_beats_the_bundled_one(tmp_path: Path) -> None:
     theirs = tmp_path / "pmd" / "ruleset.xml"
     theirs.parent.mkdir()
-    theirs.write_text("<ruleset/>")
+    theirs.write_text("<ruleset/>", encoding="utf-8")
 
     assert ruleset_of([], tmp_path) == (theirs, [])
 

{habit_hooks_java-1.3.0 → habit_hooks_java-1.4.0}/tests/test_sensor_args_reach_pmd_not_the_file_list.py

@@ -4,10 +4,16 @@ Before this fix ``main()`` turned every argv token that was not the ruleset
 into a ``-d <path>`` PMD file argument, so a genuine PMD flag such as
 ``--minimum-priority`` broke the run outright (picocli: "Expected parameter
 for option '--dir' but found '--minimum-priority'"). The sensor's command now
-spells ``${args} -- ${files}``, and the wrapper splits ``sys.argv[1:]`` on the
-*last* ``--``: everything before it goes to PMD verbatim, everything after
-becomes a file. A ``--rulesets``/``-R`` on the PMD-flag half is still pulled
-out for `-R`, exactly as it was before this split existed.
+spells ``${detector:pmd} ${args} -- ${files}``: ``sys.argv[1]`` is the file to
+run PMD by, and the wrapper splits what follows on the *last* ``--`` —
+everything before it goes to PMD verbatim, everything after becomes a file. A
+``--rulesets``/``-R`` on the PMD-flag half is still pulled out for `-R`,
+exactly as it was before this split existed.
+
+The cases below hand the tool over themselves, so it is ``java-plugin.spec.md``'s
+``[sensors.pmd] args`` case — the one that runs the real pipeline — that holds
+the *spec's* own ordering in place: spell ``${detector:pmd}`` after ``${args}``
+there and ``--minimum-priority`` is what gets spawned.
 """
 
 from __future__ import annotations
@@ -47,16 +53,17 @@ TWO_IS_TOO_MANY_RULESET = """<?xml version="1.0"?>
 """
 
 
-def _run(cwd: Path, arguments: list[str]) -> subprocess.CompletedProcess[str]:
+def _run(cwd: Path, pmd: str, arguments: list[str]) -> subprocess.CompletedProcess[str]:
     return subprocess.run(
-        [sys.executable, str(SENSOR), *arguments],
+        [sys.executable, str(SENSOR), pmd, *arguments],
         cwd=cwd,
         capture_output=True,
-        text=True,
+        encoding="utf-8",
+        errors="replace",
     )
 
 
-def test_a_pmd_flag_in_args_reaches_pmd(tmp_path: Path) -> None:
+def test_a_pmd_flag_in_args_reaches_pmd(tmp_path: Path, pmd: str) -> None:
     """ExcessiveParameterList reports at priority 3 and UnnecessaryImport at
     priority 4 (verified against PMD 7.26.0), so ``--minimum-priority 3``
     keeps the first and drops the second — proof the flag reached PMD's own
@@ -64,10 +71,10 @@ def test_a_pmd_flag_in_args_reaches_pmd(tmp_path: Path) -> None:
     that dropped every rule would pass as trivially as one that reached
     nothing at all, so the assertion has to be a smell that survives, not an
     empty result."""
-    (tmp_path / "Billing.java").write_text(FIVE_PARAMETER_METHOD_WITH_UNUSED_IMPORT)
+    (tmp_path / "Billing.java").write_text(FIVE_PARAMETER_METHOD_WITH_UNUSED_IMPORT, encoding="utf-8")
 
-    without_the_flag = _run(tmp_path, ["--", "Billing.java"])
-    with_the_flag = _run(tmp_path, ["--minimum-priority", "3", "--", "Billing.java"])
+    without_the_flag = _run(tmp_path, pmd, ["--", "Billing.java"])
+    with_the_flag = _run(tmp_path, pmd, ["--minimum-priority", "3", "--", "Billing.java"])
 
     assert without_the_flag.returncode == 0, without_the_flag.stderr
     without_smells = {finding["smell"] for finding in json.loads(without_the_flag.stdout)}
@@ -78,12 +85,12 @@ def test_a_pmd_flag_in_args_reaches_pmd(tmp_path: Path) -> None:
     assert with_smells == {"too-many-parameters"}
 
 
-def test_a_ruleset_named_in_args_is_still_honoured(tmp_path: Path) -> None:
-    (tmp_path / "Project.java").write_text(TWO_PARAMETER_METHOD)
+def test_a_ruleset_named_in_args_is_still_honoured(tmp_path: Path, pmd: str) -> None:
+    (tmp_path / "Project.java").write_text(TWO_PARAMETER_METHOD, encoding="utf-8")
     ruleset = tmp_path / "strict.xml"
-    ruleset.write_text(TWO_IS_TOO_MANY_RULESET)
+    ruleset.write_text(TWO_IS_TOO_MANY_RULESET, encoding="utf-8")
 
-    result = _run(tmp_path, ["--rulesets", str(ruleset), "--", "Project.java"])
+    result = _run(tmp_path, pmd, ["--rulesets", str(ruleset), "--", "Project.java"])
 
     assert result.returncode == 0, result.stderr
     findings = json.loads(result.stdout)

habit_hooks_java-1.4.0/tests/test_the_sensor_runs_the_pmd_it_is_handed.py

@@ -0,0 +1,53 @@
+"""The PMD this run resolved is the one the sensor spawns.
+
+``sensors/pmd.toml`` names its tool with ``${detector:pmd}``, so the run
+resolves it to a file and hands that file over as the helper's first argument.
+Spawning it — rather than the bare name it was resolved from — is the whole of
+what the sensor owes: a name is looked up again by whatever spawns it, and
+Windows' own lookup adds ``.exe`` and nothing else, where PMD installs as a
+``pmd.bat``.
+
+A PMD nobody installed is no longer answered here. The part carries no file for
+it, so nothing is ever spawned and the run answers as it does for any missing
+command — the notice, the failed run, and that sensor's dropped findings
+(``sensors/broken_part.py``).
+"""
+
+from __future__ import annotations
+import json
+import subprocess
+import sys
+from pathlib import Path
+
+from tool_lookup import where_the_bare_name_reaches_nothing
+
+SENSOR = (
+    Path(__file__).resolve().parents[1] / "src/habit_hooks_java/sensors/pmd_sensor.py"
+)
+
+FIVE_PARAMETER_METHOD = """class Billing {
+    double charge(double a, double b, double c, double d, double e) {
+        return a + b + c + d + e;
+    }
+}
+"""
+
+
+def test_the_pmd_it_is_handed_runs_where_the_name_reaches_nothing(
+    tmp_path: Path, pmd: str
+) -> None:
+    (tmp_path / "Billing.java").write_text(FIVE_PARAMETER_METHOD, encoding="utf-8")
+
+    result = subprocess.run(
+        [sys.executable, str(SENSOR), pmd, "--", "Billing.java"],
+        cwd=tmp_path,
+        capture_output=True,
+        encoding="utf-8",
+        errors="replace",
+        env=where_the_bare_name_reaches_nothing("pmd"),
+    )
+
+    assert result.returncode == 0, result.stderr
+    assert [finding["smell"] for finding in json.loads(result.stdout)] == [
+        "too-many-parameters"
+    ]

habit_hooks_java-1.3.0/PKG-INFO

@@ -1,5 +0,0 @@
-Metadata-Version: 2.5
-Name: habit-hooks-java
-Version: 1.3.0
-Summary: The Java Habit Hooks plugin
-Requires-Python: >=3.11

habit_hooks_java-1.3.0/pyproject.toml

@@ -1,16 +0,0 @@
-[project]
-name = "habit-hooks-java"
-version = "1.3.0"
-description = "The Java Habit Hooks plugin"
-requires-python = ">=3.11"
-dependencies = []
-
-[project.entry-points."habit_hooks.plugins"]
-java = "habit_hooks_java"
-
-[build-system]
-requires = ["hatchling"]
-build-backend = "hatchling.build"
-
-[tool.hatch.build.targets.wheel]
-packages = ["src/habit_hooks_java"]

habit_hooks_java-1.3.0/src/habit_hooks_java/sensors/pmd.toml

@@ -1 +0,0 @@
-command = "${python} ${dir}/pmd_sensor.py ${args} -- ${files}"

habit_hooks_java-1.3.0/tests/test_a_java_pmd_nobody_installed_is_named.py

@@ -1,35 +0,0 @@
-"""The tool this plugin does not ship must still answer in one line.
-
-The plugin does not bundle the PMD distribution, so ``pmd`` is the command that
-goes missing — and it is spawned from Python, where an absent tool is a
-``FileNotFoundError`` and twenty lines of internals would otherwise become the
-sensor's diagnosis (#114).
-"""
-
-from __future__ import annotations
-
-import subprocess
-import sys
-from pathlib import Path
-
-SENSOR = (
-    Path(__file__).resolve().parents[1] / "src/habit_hooks_java/sensors/pmd_sensor.py"
-)
-
-
-def test_a_java_pmd_nobody_installed_answers_the_way_a_shell_does(
-    tmp_path: Path,
-) -> None:
-    (tmp_path / "App.java").write_text("class App {}\n")
-
-    result = subprocess.run(
-        [sys.executable, str(SENSOR), "App.java"],
-        cwd=tmp_path,
-        capture_output=True,
-        text=True,
-        env={"PATH": "/nonexistent"},
-    )
-
-    assert result.returncode != 0
-    assert result.stdout.strip() == ""
-    assert result.stderr.strip() == "pmd: command not found"