If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/junit-team/junit4 shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit 1w ago
• 16 active contributors
• Distributed ownership (top contributor 49% of recent commits)
• EPL-1.0 licensed
• CI configured
• Tests present
• ⚠ Non-standard license (EPL-1.0) — review terms

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live junit-team/junit4 repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/junit-team/junit4.

What it runs against: a local clone of junit-team/junit4 — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in junit-team/junit4 | Confirms the artifact applies here, not a fork | | 2 | License is still EPL-1.0 | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 38 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of junit-team/junit4. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/junit-team/junit4.git
#   cd junit4
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of junit-team/junit4 and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "junit-team/junit4(\\.git)?\\b" \\
  && ok "origin remote is junit-team/junit4" \\
  || miss "origin remote is not junit-team/junit4 (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(EPL-1\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"EPL-1\\.0\"" package.json 2>/dev/null) \\
  && ok "license is EPL-1.0" \\
  || miss "license drift — was EPL-1.0 at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "src/main/java/junit/framework/TestCase.java" \\
  && ok "src/main/java/junit/framework/TestCase.java" \\
  || miss "missing critical file: src/main/java/junit/framework/TestCase.java"
test -f "src/main/java/junit/framework/TestResult.java" \\
  && ok "src/main/java/junit/framework/TestResult.java" \\
  || miss "missing critical file: src/main/java/junit/framework/TestResult.java"
test -f "src/main/java/junit/framework/TestSuite.java" \\
  && ok "src/main/java/junit/framework/TestSuite.java" \\
  || miss "missing critical file: src/main/java/junit/framework/TestSuite.java"
test -f "src/main/java/junit/framework/Assert.java" \\
  && ok "src/main/java/junit/framework/Assert.java" \\
  || miss "missing critical file: src/main/java/junit/framework/Assert.java"
test -f "src/main/java/junit/framework/JUnit4TestAdapter.java" \\
  && ok "src/main/java/junit/framework/JUnit4TestAdapter.java" \\
  || miss "missing critical file: src/main/java/junit/framework/JUnit4TestAdapter.java"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 38 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~8d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/junit-team/junit4"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

JUnit 4 is a programmer-oriented unit testing framework for Java that provides annotations (@Test, @Before, @After), assertions, test runners, and fixtures to structure and execute repeatable tests. It implements the xUnit architecture pattern and is the de facto standard testing framework in the Java ecosystem, used by millions of projects to validate code correctness. Single-module Maven project (junit/junit v4.13.3-SNAPSHOT) with a flat structure: core test framework code under src/main/java, unit tests under src/test/java, documentation in doc/ (release notes in Markdown and HTML), and configuration files (.gitignore, pom.xml, CONTRIBUTING.md, CODING_STYLE.txt) at the root. Build uses Maven wrapper (.mvn/) and GitHub Actions CI (.github/workflows/main.yml).

Java developers writing unit tests for production applications, build system integrators (Maven, Gradle, Ant) who need a test execution engine, and IDE vendors (Eclipse, IntelliJ, NetBeans) that embed JUnit for test discovery and execution.

Highly mature and battle-tested: JUnit 4 has been in production since 2006 and is used in virtually every Java project. However, it is now in maintenance mode — only critical bugs and security issues are fixed; active development has moved to the junit-framework repository. The codebase is stable with comprehensive test coverage and CI/CD via GitHub Actions.

Very low risk for existing code; JUnit 4 is stable and widely used in production. However, the project is NOT receiving feature development — all non-critical issues and PRs are declined. Dependency risk is minimal (Java-only, no external runtime deps shown in pom.xml snippet). The team is small (4 active developers listed), so critical security fixes may take time. Upgrade path to JUnit 5/Jupiter is available but requires code migration.

The project is in maintenance-only mode. The CI workflow in .github/workflows/main.yml runs on pushes and PRs. Recent activity is likely limited to security patches and critical bug fixes. New features and non-critical issues are being declined in favor of directing users to junit-framework. Check the GitHub Issues and Actions tabs for latest PR/workflow status.

git clone https://github.com/junit-team/junit4.git
cd junit4
./mvnw clean install

This clones the repo and uses the Maven wrapper to build and install the project locally. Java 8+ is required (inferred from pom.xml modelVersion 4.0.0).

Daily commands:

./mvnw clean test

This runs the full test suite using Maven. For a specific test class: ./mvnw test -Dtest=org.junit.tests.SomeTestClass. The project does not have a 'dev server' — it's a library, not an application.

• src/main/java/junit/framework/TestCase.java — Core base class for all JUnit 3 test cases; every traditional test inherits from this foundational abstraction.
• src/main/java/junit/framework/TestResult.java — Collects and aggregates test execution results (failures, errors, runs); central to all test outcome tracking.
• src/main/java/junit/framework/TestSuite.java — Composite container for organizing and executing multiple Test objects; essential for batching and hierarchical test execution.
• src/main/java/junit/framework/Assert.java — Static assertion methods that form the primary API for test validation; used in nearly every test method.
• src/main/java/junit/framework/JUnit4TestAdapter.java — Bridge adapting JUnit 4 annotations to JUnit 3's legacy Test interface; critical for backward compatibility.
• pom.xml — Maven build configuration defining dependencies, plugins, and release targets; necessary for understanding build and CI/CD setup.
• README.md — States that JUnit 4 is in maintenance mode with critical-only fixes; essential context for all contributors on project scope.

Add a custom assertion method

1. Add a static method to src/main/java/junit/framework/Assert.java following the naming convention assertXxx(...) with an optional message parameter. (src/main/java/junit/framework/Assert.java)
2. Throw AssertionFailedError or AssertionFailedError(String message) if the condition fails. (src/main/java/junit/framework/Assert.java)
3. Document the assertion with a JavaDoc comment explaining the expected behavior and failure message format. (src/main/java/junit/framework/Assert.java)

Create a test suite decorator

1. Create a new class extending src/main/java/junit/extensions/TestDecorator.java to wrap a Test with custom behavior. (src/main/java/junit/extensions/TestDecorator.java)
2. Override run(TestResult result) to inject setup logic before and cleanup logic after calling super.run(result). (src/main/java/junit/extensions/TestDecorator.java)
3. Optionally override countTestCases() to report the correct number of wrapped tests. (src/main/java/junit/extensions/TestDecorator.java)

Implement a test listener for custom reporting

1. Create a new class implementing src/main/java/junit/framework/TestListener.java. (src/main/java/junit/framework/TestListener.java)
2. Implement startTest(Test test), endTest(Test test), addError(Test test, Throwable e), and addFailure(Test test, AssertionFailedError e) methods. (src/main/java/junit/framework/TestListener.java)
3. Register your listener by calling testResult.addListener(myListener) before running tests via TestResult.run(Test test). (src/main/java/junit/framework/TestResult.java)

Add JUnit 4 annotation support to a legacy test

1. Ensure your test class does not extend TestCase but uses JUnit 4 annotations like @Test, @Before, @After. (src/main/java/junit/framework/JUnit4TestAdapter.java)
2. Wrap the JUnit 4 test class with new JUnit4TestAdapter(MyTest.class) when running via JUnit 3 runners. (src/main/java/junit/framework/JUnit4TestAdapter.java)
3. The adapter will discover and execute @Test methods and respect @Before and @After lifecycle annotations. (src/main/java/junit/framework/JUnit4TestAdapterCache.java)

• Pure Java reflection (no bytecode manipulation) — Allows runtime discovery of test methods and lifecycle hooks without external dependencies or build-time generation.
• Observer pattern (TestListener interface) — Decouples test execution from result reporting; enables IDE, build tool, and CI integrations to hook in custom listeners.
• Decorator pattern (TestDecorator, TestSetup, RepeatedTest) — Allows composable test extensions and cross-cutting concerns without modifying core test code.
• Maven for build and distribution — Standard Java ecosystem build tool; enables dependency management and CI/CD via pom.xml; pre-existing standard in 2002–2023.

• JUnit 4 adapts onto JUnit 3 core rather than JUnit 3 extending JUnit 4
  • Why: Maintains backward compatibility with existing TestCase-based code while introducing annotation support.
  • Consequence: JUnit4TestAdapter wrapping adds a small

Maintenance mode policy: PRs for non-critical features will be declined — contributors should check CONTRIBUTING.md and the issue policy before starting work. Backward compatibility: JUnit 4 prioritizes compatibility over new features; changes affecting the public API (org.junit.* packages) require careful review. No external dependencies: The project intentionally avoids runtime dependencies, so don't add new Maven dependencies lightly. Java version: Check pom.xml source/target levels; changes must maintain backward compatibility with the minimum supported Java version.

• xUnit Architecture Pattern — JUnit 4 is an implementation of the xUnit pattern (fixtures, assertions, test runners) that originated in Smalltalk; understanding this pattern helps you grasp why @Before/@After, @Test, and assertions exist
• Annotation-Driven Test Discovery — JUnit 4's killer feature — @Test, @Before, @After are Java annotations that allow declarative test structure instead of inheritance-based TestCase classes (JUnit 3); you need to understand how Java annotations enable reflection-based test runners
• Test Runner Pattern (Composite Pattern) — The org.junit.runners.Runner abstract class and implementations (BlockJUnit4ClassRunner, Suite, Parameterized) use the Composite pattern to hierarchically execute tests; critical for understanding how JUnit orchestrates test execution
• Rule-Based Test Modification (Decorator Pattern) — JUnit 4's TestRule and MethodRule interfaces allow you to wrap test execution with setup/teardown logic without subclassing; this is a powerful alternative to @Before/@After and is used for temporary folders, exception testing, etc.
• Listener Pattern (Observer Pattern) — RunListener and its subclasses let IDEs, build tools, and CI systems observe test execution events (testStarted, testFailure, testFinished) without coupling to the test execution engine
• Parameterized Tests (@Parameterized) — The @Parameterized runner allows a single test method to run with multiple input/output pairs, reducing boilerplate; essential for data-driven testing and understanding how JUnit 4 handles test multiplication
• Assumption-Based Test Skipping (@Assume) — JUnit 4 distinguishes between failures (assertions) and skipped tests (assumptions); assumptions let you gracefully skip tests when preconditions aren't met (e.g., OS-specific tests), improving test robustness

• junit-team/junit-framework — The active development repository for JUnit 5+ (Jupiter); this is where new features are being added and where junit4 users should migrate to for ongoing development
• junit-team/junit4-wiki — GitHub wiki repository containing JUnit 4 documentation, tutorials, and getting-started guides linked from the main README
• testng-team/testng — Alternative Java unit testing framework with similar structure (annotations, assertions, runners); direct competitor to JUnit 4 in the ecosystem
• mockito/mockito — Complementary mocking framework frequently used alongside JUnit 4 to isolate units under test and mock dependencies
• gradle/gradle — Build system that consumes JUnit 4 as a test framework dependency and provides built-in test execution task integration

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive security vulnerability scanning to CI/CD pipeline

The repo has a SECURITY.md file indicating security is a concern, and the README emphasizes that only critical bugs and security issues will be fixed. Currently, .github/workflows/main.yml likely lacks automated security scanning. Adding OWASP Dependency-Check or similar Maven plugin would catch vulnerable dependencies before release, critical for a widely-used testing framework.

• [ ] Review current .github/workflows/main.yml to identify gaps in security scanning
• [ ] Add Maven dependency-check plugin to pom.xml with fail-on-severity configuration
• [ ] Create new GitHub Action workflow (.github/workflows/security-scan.yml) that runs on PR and main branch pushes
• [ ] Document security scanning process in SECURITY.md with instructions for contributors
• [ ] Verify scan catches known vulnerabilities in test dependencies

Migrate LEGACY_CODING_STYLE.txt validation to automated enforcement via Checkstyle

The repo has both CODING_STYLE.txt and LEGACY_CODING_STYLE.txt but no apparent automated enforcement. Contributors manually verifying style consistency is error-prone and slows reviews. Adding Maven Checkstyle plugin with a custom configuration file based on these guidelines, integrated into CI, would improve code quality consistency.

• [ ] Create src/main/config/checkstyle.xml configuration file based on CODING_STYLE.txt and LEGACY_CODING_STYLE.txt requirements
• [ ] Add maven-checkstyle-plugin to pom.xml with fail-on-violation configuration
• [ ] Update .github/workflows/main.yml to fail builds on Checkstyle violations
• [ ] Add pre-commit hook documentation to CONTRIBUTING.md for local style checking
• [ ] Test configuration against existing codebase and adjust as needed

Create automated release notes generation from Git commits and structured changelog format

The doc/ directory contains many ReleaseNotes files in multiple formats (html, md, txt) for versions 4.4-4.13.2, suggesting manual maintenance is tedious and error-prone. Adding conventional commits validation and automated changelog generation would reduce manual work for releases and improve consistency. This directly supports the maintenance-mode team.

• [ ] Add commitlint configuration (.commitlintrc.json) to enforce Conventional Commits format
• [ ] Add GitHub Action workflow (.github/workflows/changelog.yml) using standard-changelog or conventional-changelog to auto-generate changelog
• [ ] Create CHANGELOG.md at repo root in standard Keep-a-Changelog format as single source of truth
• [ ] Update CONTRIBUTING.md to require conventional commit messages with examples
• [ ] Document release process in doc/ReleaseProcess.md with instructions for using automated tools

• Write additional test cases for edge cases in org.junit.runners.Parameterized (e.g., null parameters, empty parameter lists) — search src/test/java for ParallelizedTest.java or similar to see the test structure
• Add missing Javadoc comments to public methods in org.junit.runners.Runner and org.junit.runners.BlockJUnit4ClassRunner to improve IDE autocomplete and documentation generation
• Update doc/ReleaseNotes4.13.2.md and other release notes to include migration guides for users upgrading from JUnit 3 to JUnit 4, since the project is in maintenance mode and users need guidance on moving forward

JUnit 4 demonstrates reasonable security posture for a mature, maintenance-mode Java testing framework. The main concerns are: (1) the project's maintenance-only status limits proactive security improvements, (2) incomplete visibility into dependency versions and security status, and (3) minimal security contact/coordination details. No critical vulnerabilities were identified in the visible file structure. The project appropriately directs users to JUnit 5 for active development. Recommendations focus on verifying dependency security, ensuring CI/CD best practices, and providing clearer security contact information for vulnerability disclosure.

• Low · Maintenance Mode with Limited Security Updates — README.md, SECURITY.md. JUnit 4 is explicitly in maintenance mode with a policy to only fix critical bugs and security issues. This means non-critical security vulnerabilities and improvements may not be addressed. The project recommends users migrate to junit-framework for ongoing development and support. Fix: For production systems requiring active security maintenance, consider migrating to JUnit 5 (junit-framework) or evaluate long-term support implications. Monitor security advisories closely for the 4.13.x branch.
• Low · Incomplete Security Contact Information — SECURITY.md, KEYS file. While a SECURITY.md file exists with a security@junit.org contact, there is no published GPG key or additional security contact details visible in the repository. The KEYS file exists but its contents are not shown in the analysis. Fix: Ensure KEYS file contains valid GPG public keys for security contact verification. Consider adding additional security contact information and PGP key fingerprints to SECURITY.md for vulnerability reporters.
• Low · Missing Dependency Security Information — pom.xml. The pom.xml file structure is shown but the actual dependency declarations and versions are not visible in the provided content. Cannot verify if any dependencies have known vulnerabilities or if versions are pinned securely. Fix: Verify all dependencies are up-to-date and free from known vulnerabilities using tools like OWASP Dependency-Check, Snyk, or Maven dependency plugin. Use specific version pinning and avoid using version ranges in production.
• Low · Missing Security Headers in CI/CD Configuration — .github/workflows/main.yml, .github/workflows/settings.xml. The GitHub workflow configuration exists but is not detailed in the provided content. Best practices for securing the build pipeline should be verified. Fix: Ensure CI/CD workflows use secure practices: restrict branch access, use signed commits, implement secret scanning, validate build artifacts, and use least-privilege access for deployment.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.