Skip to content

Fix: Add test-classes folder to classpath for test-jar workspace dependencies - #2175

Open
mnpoonia wants to merge 4 commits into
eclipse-m2e:mainfrom
mnpoonia:fix/test-jar-workspace-resolution
Open

Fix: Add test-classes folder to classpath for test-jar workspace dependencies#2175
mnpoonia wants to merge 4 commits into
eclipse-m2e:mainfrom
mnpoonia:fix/test-jar-workspace-resolution

Conversation

@mnpoonia

Copy link
Copy Markdown

Fixes #2174

Summary

Adds target/test-classes folder to classpath for workspace test-jar dependencies, fixing compilation errors like "TestUtil cannot be resolved".

Problem

When a Maven dependency has <type>test-jar</type> and the dependency project is in the workspace, M2E only added a project reference with WITHOUT_TEST_CODE attribute. Eclipse JDT doesn't automatically include the target/test-classes folder based on this attribute, causing compilation failures.

Solution

After detecting a test-jar workspace dependency, explicitly add the dependency's test-classes output folder as a library entry with source attachment.

Changed file:

  • org.eclipse.m2e.jdt/src/org/eclipse/m2e/jdt/internal/DefaultClasspathManagerDelegate.java

Implementation Details

  1. Uses existing isTestArtifact() check (already detects "test-jar".equals(type))
  2. Retrieves test output directory from Maven project: mavenProject.getBuild().getTestOutputDirectory()
  3. Adds library entry pointing to target/test-classes folder
  4. Sets source attachment to src/test/java for F3 (go to definition) support
  5. Respects TEST_ATTRIBUTE for proper visibility control
  6. Graceful fallback on error (preserves existing behavior)

Testing

Manual Testing

Minimal reproduction (2 modules):

  • Before: ❌ "TestUtil cannot be resolved"
  • After: ✅ 0 errors

Apache HBase (50+ modules, 191 test-jar dependencies):

  • Before: ❌ 37 compilation errors
  • After: ✅ 0 errors

Maven CLI Compatibility

✅ Matches Maven CLI behavior (uses test-jar from workspace)

Benefits

  • ✅ No hardcoded paths - uses Maven project model
  • ✅ Minimal change - 21 lines added
  • ✅ Backward compatible - only affects test-jar dependencies
  • ✅ Follows existing M2E patterns
  • ✅ Includes source attachment for debugging

Reproduction Project

Created minimal 2-module test case demonstrating the issue and fix:

  • Structure: module-a (produces test-jar) → module-b (depends on test-jar)
  • Before fix: Compilation error in Eclipse
  • After fix: Clean import
  • Maven CLI: Always works (uses repository test-jar)

Available at: /Users/apoonia/Code/github/m2e-testjar-repro

@mnpoonia

Copy link
Copy Markdown
Author

@laeubi Please guide me here. I am trying to contribute for the first time.

@mnpoonia
mnpoonia force-pushed the fix/test-jar-workspace-resolution branch from 31cb849 to 81d24a7 Compare May 20, 2026 06:56
mnpoonia added 2 commits June 9, 2026 22:06
When a project depends on another workspace project via type=test-jar or
classifier=tests, the dependency should resolve to a CPE_PROJECT entry
with WITHOUT_TEST_CODE=null so the consumer sees the producer's test
sources. The previous approach incorrectly added a CPE_LIBRARY entry
pointing to target/test-classes, which broke existing count-based
assertions in BuildPathManagerTest and JavaClasspathTest.

The correct mechanism already exists: excludeTestSources &= !isTestArtifact
in DefaultClasspathManagerDelegate sets WITHOUT_TEST_CODE=null for
test-jar project references. The producer also needs
m2e.disableTestClasspathFlag=true so its src/test/java folder is not
marked test=true, making test classes visible to consumers.

Adds TestJarWorkspaceResolutionTest covering:
- type=test-jar in compile scope (WITHOUT_TEST_CODE absent)
- classifier=tests (project entry present, WITHOUT_TEST_CODE absent)
- regular dependency (WITHOUT_TEST_CODE=true, no test-classes library)
- type=test-jar in test scope (test=true attribute set)
…DependencyCollector

- Fix operator precedence bug in isVersionRanged(): the expression
  version != null && version.startsWith("(") || version.startsWith("[")
  was parsed as (version != null && ...) || version.startsWith("["),
  causing NPE when version is null
- Add import scope BOM expansion: when dependencyScopes contains "import"
  and the current node is a POM artifact, also enqueue its managed
  dependencies (both in DIRECT and BFS depth paths)
- Deduplicate artifacts in the DIRECT depth path using a seen Set,
  matching the dedup logic already present in the BFS path
- Extract enqueueDependencies() helper (DRY)
- Bump org.eclipse.m2e.pde.target to 2.1.400 and
  org.eclipse.m2e.pde.feature to 2.3.800 (binary change)
@mnpoonia
mnpoonia force-pushed the fix/test-jar-workspace-resolution branch from 60d32a1 to 27f2721 Compare June 9, 2026 16:37
mnpoonia added 2 commits June 9, 2026 23:00
…operty

Previously, a project that produced a test-jar via maven-jar-plugin had to
explicitly set m2e.disableTestClasspathFlag=true in its pom.xml properties
for consumers to see its test classes via workspace project reference.

This required producer opt-in, which meant third-party projects (e.g.
Apache HBase with 191 test-jar dependencies) could not benefit without
pom.xml changes.

Fix: MavenClasspathHelpers.hasTestFlagDisabled() now also returns true
when maven-jar-plugin has a test-jar execution, regardless of whether
the pom property is set. The explicit property still works as before.

Remove m2e.disableTestClasspathFlag from the module-a test fixture since
it is no longer needed — auto-detection now covers the common case.
…10.300

MavenClasspathHelpers.hasTestFlagDisabled() is a behavioral change (auto-detection
of maven-jar-plugin:test-jar), requiring a minor version bump per Tycho baseline rules.
The containing feature must also be bumped when its bundle versions change.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Test-jar workspace dependencies not resolved - compilation errors

1 participant