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/square/dagger 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 all four use cases

• 14 active contributors
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Stale — last commit 5y ago
• ⚠ Concentrated ownership — top contributor handles 56% of recent commits

_{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 square/dagger repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/square/dagger.

What it runs against: a local clone of square/dagger — 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 square/dagger | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | Last commit ≤ 1746 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of square/dagger. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/square/dagger.git
#   cd dagger
#
# 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 square/dagger and re-run."
  exit 2
fi

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

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

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

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 1746 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1716d)"
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/square/dagger"
  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).

Dagger 1 is a compile-time dependency injection framework for Java and Android that uses annotation processing to generate boilerplate-free, type-safe dependency graphs. It generates optimized bytecode at compile time rather than using reflection at runtime, making it fast and suitable for Android's resource-constrained environment. The compiler (in compiler/ directory) parses @Inject, @Provides, and @Module annotations to generate adapter classes that wire dependencies together. Two-module Maven structure: compiler/ contains the annotation processor and code generator (main logic), while the parent pom.xml manages versions. Integration tests live in compiler/src/it/ with subdirectories for each test scenario (e.g., extension-graph/, inject-on-class/, final-field-inject/) demonstrating different injection patterns. The compiler generates Java source code using JavaPoet.

Android and Java developers who need fast, compile-time dependency injection without runtime reflection overhead. Specifically, developers building Android apps in the pre-Dagger 2 era (this is deprecated in favor of Google's Dagger 2), or teams maintaining legacy Dagger 1 codebases who need to understand or modify the compiler.

This is deprecated and unmaintained. The README explicitly states 'Deprecated – Please upgrade to Dagger 2' and recommends migration. The codebase shows 444KB of Java (mature volume) and has a Maven-based build with integration tests, indicating it was production-ready at its time, but no active development is happening—this is an archived predecessor to Google's Dagger 2.

Very high risk for new projects: this is deprecated and the maintainers recommend migrating to Google's Dagger 2. Dependencies include guava and javapoet (stable), but without active maintenance, any Java compatibility issues with modern JVMs will not be addressed. Last activity appears historical (version 1.2.6-SNAPSHOT). Do not use for new projects.

Nothing—this is a frozen, deprecated repository. Version is stuck at 1.2.6-SNAPSHOT. The project is maintained for historical/legacy reasons only, with users directed to migrate to Google's Dagger 2 (see CONTRIBUTING.md and the deprecation notice in README.md).

git clone https://github.com/square/dagger.git
cd dagger
mvn clean install

Note: Requires Maven 3.x and Java 6+. This will compile the runtime (dagger module) and compiler (compiler/ module), running integration tests in compiler/src/it/.

Daily commands: This is a library/compiler, not a runnable app. To use it: include dagger-compiler-${version}.jar on the compile classpath and dagger-${version}.jar on the runtime classpath. The compiler runs automatically during Maven's annotation processing phase. To test the compiler itself: mvn clean install -pl compiler runs unit and integration tests in compiler/src/it/.

• compiler/pom.xml: Defines the compiler module dependencies (javapoet, guava) and build configuration for the annotation processor
• compiler/src/it/: Integration test directory—each subdirectory is a self-contained Maven project testing a specific injection pattern (extension graphs, final fields, default packages, etc.)
• CHANGELOG.md: Documents all 1.x releases and deprecation notice; essential for understanding breaking changes and migration path to Dagger 2
• README.md: Clearly states deprecation status and points to Google's Dagger 2 migration guide; primary entry point for all users
• .travis.yml: CI configuration showing how the project is built and tested (Maven builds, likely Java version constraints)

Code generation logic: compiler/src/main/java/ contains the processor and code generators. Integration tests: each subdirectory in compiler/src/it/ (like inject-on-class/) is a separate Maven project demonstrating a use case—modify TestApp.java in each to test behavior. Validation: checkstyle.xml enforces style; see CONTRIBUTING.md for guidelines.

Deprecation: This project is officially deprecated—any new development should use Google's Dagger 2. Annotation Processing: The compiler relies on Java's annotation processor (APT) framework; it only runs during compilation if the compiler JAR is on the compile classpath. Maven-specific: Build uses Maven; no Gradle support visible (though Gradle can invoke the APT). Java 6 baseline: Code targets Java 6; may not compile cleanly on Java 17+. Integration tests: Each IT project in compiler/src/it/ requires its own Maven invocation; use Maven Invoker Plugin to run them.

• Annotation Processing (APT) — Dagger 1 is built entirely around the Java Annotation Processing Tool—it generates code at compile time by inspecting @Inject, @Provides, and @Module annotations
• Dependency Injection Graph — Dagger constructs a directed acyclic graph (DAG) of dependencies at compile time and generates code to satisfy them; understanding the graph structure is essential to fixing injection errors
• Compile-time Code Generation vs. Runtime Reflection — Dagger 1's core advantage over Spring is that it generates all injection code at compile time, eliminating runtime reflection overhead—critical for Android's constrained resources
• JSR-330 Annotations (@Inject, @Named, @Singleton) — Dagger 1 uses standard javax.inject annotations to mark injection points; understanding these standardized annotations is essential for reading and writing Dagger 1 code
• Module Adapters and Object Graph — Dagger generates ObjectGraph instances from @Module classes and creates adapters for each binding; these generated classes are what actually wire dependencies together at runtime
• Maven Invoker Plugin for Integration Testing — Dagger 1 tests use Maven Invoker to run separate Maven projects as test cases; this pattern isolates compiler behavior testing from the main codebase

• google/dagger — The official successor to Dagger 1; Google's Dagger 2 is what you should migrate to (this 1.x repo points to it)
• square/javapoet — Dagger 1 compiler depends on JavaPoet for generating Java source code; understanding JavaPoet is critical to modifying code generation
• google/guava — Utility library used throughout compiler logic for collections and functional programming patterns
• square/picasso — Contemporary Square library using Dagger 1 for dependency injection; example of how Dagger 1 was used in real Android projects
• eclipse/eclipse.jdt.core — Contains the Java annotation processor (APT) framework that Dagger 1 compiler depends on; low-level reference for annotation processing internals

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 integration tests for edge cases in parameterized type injection

The repo has an integration test directory compiler/src/it/inject-parameterized-type/ but lacks comprehensive test coverage for complex generic type scenarios. Given that Dagger handles parameterized types (generics) which are error-prone, adding tests for nested generics, bounded type variables, and wildcard types would catch regressions early and improve code quality for a critical feature.

• [ ] Review existing compiler/src/it/inject-parameterized-type/src/main/java/test/TestApp.java to understand current coverage
• [ ] Create new test cases in compiler/src/it/ subdirectories for: nested generics (e.g., List<Set<String>>), bounded wildcards (e.g., ? extends Number), and type variable injection
• [ ] Add corresponding verify.bsh scripts (like in inject-on-class/verify.bsh) to validate generated code
• [ ] Run full Maven integration test suite via mvn install to ensure no regressions

Add verification tests for final field injection error handling

The directory compiler/src/it/final-field-inject/ exists with a verify.bsh script but appears incomplete. Dagger should explicitly reject or document injection into final fields (a common mistake). Adding comprehensive error message validation and edge case tests would prevent user confusion and improve error reporting quality.

• [ ] Examine compiler/src/it/final-field-inject/src/main/java/test/TestApp.java and verify.bsh to understand current test scope
• [ ] Expand verify.bsh to assert specific error messages when attempting to inject into final fields
• [ ] Add new test variants: final fields with @Inject, final fields in abstract classes, and final fields in modules
• [ ] Document expected behavior in CONTRIBUTING.md or add inline comments explaining the rationale

Add Maven integration tests for non-module include validation

The test case compiler/src/it/include-non-module/ with invoker.properties suggests Dagger validates module includes, but the test coverage appears minimal. Adding comprehensive validation tests for invalid module inclusions (non-annotated classes, circular includes) would catch configuration errors and improve the clarity of compiler diagnostics.

• [ ] Review compiler/src/it/include-non-module/invoker.properties and pom.xml configuration
• [ ] Expand or create new test case for scenarios: attempting to include non-@Module classes, circular module dependencies, and duplicate includes
• [ ] Add verify.bsh scripts to assert compiler errors include helpful diagnostics (e.g., 'Class X is not annotated with @Module')
• [ ] Document the behavior in CONTRIBUTING.md under integration testing guidelines

• Add integration test for Dagger 1 with Java 9+ module system (compiler/src/it/ is missing a test scenario verifying compatibility with Java 9+ JPMS; create java9-modules/ test case)
• Document the compile-vs-runtime dependency split in README.md (current README mentions it but doesn't have a dedicated 'How the Compiler Works' section; add a diagram or explanation of APT lifecycle)
• Expand integration tests coverage for edge cases like circular dependencies or missing bindings—review compiler/src/it/ for gaps and add new test projects demonstrating error cases with expected compile-time failures

The Dagger 1.x dependency injection framework analyzed shows moderate security concerns. The primary risk is the use of deprecated software (Dagger 1.2.6-SNAPSHOT) which is no longer maintained and may contain unpatched vulnerabilities. Additional concerns include incomplete dependency declarations, lack of explicit version pinning for transitive dependencies, and potential exposure of build credentials. The project structure itself follows reasonable practices with proper licensing and documentation, but immediate action is needed to upgrade to Dagger 2 and implement stricter dependency management to reduce supply chain risks.

• High · Deprecated Dependency - Dagger 1.x — pom.xml (parent version: 1.2.6-SNAPSHOT), README.md. The project is using Dagger 1.x (version 1.2.6-SNAPSHOT), which is officially deprecated. Square has deprecated Dagger 1 in favor of Google's Dagger 2. Deprecated software may contain unpatched security vulnerabilities and lacks ongoing security maintenance. Fix: Upgrade to Dagger 2 or later. Follow the official migration guide at https://google.github.io/dagger/dagger-1-migration.html to ensure a smooth transition.
• Medium · Incomplete Dependency Declaration in POM — compiler/pom.xml. The compiler/pom.xml file appears to be truncated in the provided content (ends with '<gro'). This incomplete configuration may indicate missing or improperly declared dependencies, which could lead to supply chain risks or version mismatches. Fix: Verify the complete and valid syntax of the pom.xml file. Ensure all dependencies are properly declared with explicit versions and no truncation exists.
• Medium · Missing Dependency Version Pinning — compiler/pom.xml (javapoet, guava dependencies). Dependencies like 'com.squareup:javapoet' and 'com.google.guava:guava' appear to use version placeholders without explicit version numbers shown. This could lead to unexpected version resolution and potential introduction of vulnerable transitive dependencies. Fix: Use explicit version numbers for all dependencies. Implement dependency locking mechanisms (e.g., Maven Dependency Plugin, bill-of-materials). Regularly scan for vulnerable transitive dependencies using tools like OWASP Dependency-Check.
• Low · Credentials in Build Configuration — .buildscript/settings.xml. The file '.buildscript/settings.xml' exists which typically contains Maven credentials and repository configurations. While not directly visible, such files should be protected to prevent credential exposure. Fix: Ensure .buildscript/settings.xml is added to .gitignore and never committed to version control. Use CI/CD environment variables or secure credential management systems for sensitive build configurations.
• Low · Integration Tests with Potential Injection Points — compiler/src/it/*/src/main/java/test/TestApp.java. Multiple integration test directories (compiler/src/it/*) contain TestApp.java files that may be testing annotation processing and code generation. While this is expected for a DI framework, ensure these tests don't inadvertently generate exploitable code patterns. Fix: Review code generation logic to ensure it doesn't create vulnerabilities. Add security-focused tests for generated code. Validate that generated code cannot be exploited for injection attacks.

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.