Fix resource folder handling for ancestor directories

[chagong]

Problem

When a Maven resource directory resolves outside the project, AbstractJavaProjectConfigurator.getFolder() can pass an invalid relative path to Eclipse resource lookup. For ancestor resource directories such as <directory>..</directory>, that can normalize to / and fail with:

IllegalArgumentException: Path must include project and resource name: /

This affects projects whose child modules inherit or define resource directories outside the module directory, including cases seen with Apache Dubbo and Google Guava.

Fix

Normalize the project and resource paths before comparing them, and skip ancestor resource directories in addResourceDirs() before calling project.getFolder(). getFolder() now keeps its non-null container contract for other callers and reports ancestor paths as invalid linked-resource targets.

Fixes #1790

[eclipse-m2e-bot]

This pull request changes some projects for the first time in this development cycle.
Therefore the following files need a version increment:

org.eclipse.m2e.jdt/META-INF/MANIFEST.MF

Warning

🚧 This PR cannot be modified by maintainers because edits are disabled or it is created from an organization repository. To obtain the required changes apply the git patch manually as an additional commit.

Git patch

From f916ef9027ade5f4d91b6a2a2fa941315b11dd5b Mon Sep 17 00:00:00 2001
From: Eclipse M2E Bot <m2e-bot@eclipse.org>
Date: Sat, 25 Apr 2026 13:55:46 +0000
Subject: [PATCH] Version bump(s) for null object or invalid expression stream


diff --git a/org.eclipse.m2e.jdt/META-INF/MANIFEST.MF b/org.eclipse.m2e.jdt/META-INF/MANIFEST.MF
index 0109ba6b..7fb51874 100644
--- a/org.eclipse.m2e.jdt/META-INF/MANIFEST.MF
+++ b/org.eclipse.m2e.jdt/META-INF/MANIFEST.MF
@@ -2,7 +2,7 @@ Manifest-Version: 1.0
 Bundle-ManifestVersion: 2
 Bundle-Name: %Bundle-Name
 Bundle-SymbolicName: org.eclipse.m2e.jdt;singleton:=true
-Bundle-Version: 2.5.100.qualifier
+Bundle-Version: 2.5.200.qualifier
 Bundle-Localization: plugin
 Export-Package: org.eclipse.m2e.jdt,
  org.eclipse.m2e.jdt.internal;x-friends:="org.eclipse.m2e.jdt.ui",
-- 
2.53.0

Further information are available in Common Build Issues - Missing version increments.

[github-actions]

Test Results

  339 files  ±0    339 suites  ±0   1h 4m 26s ⏱️ + 4m 47s
  721 tests ±0    704 ✅ +3  16 💤 ±0  1 ❌  - 2 
2 163 runs  ±0  2 114 ✅ +3  48 💤 ±0  1 ❌  - 2 

For more details on these failures, see this check.

Results for commit 3f3e690. ± Comparison against base commit 7ff8669.

♻️ This comment has been updated with latest results.

[fbricon]

@chagong you need to rebase your project against main (merge commits are strictly forbidden)
The build fails because you have to bump the org.eclipse.m2e.jdt version to 2.5.200

[chagong]

@fbricon I actually undid the bump up bundle version. And by looking at the error log:

[2026-04-17T08:14:35.740Z] Caused by: org.eclipse.tycho.core.exceptions.VersionBumpRequiredException: Baseline problems found! Project version: 2.5.100.20260417-0757, baseline version: 2.5.100.20260205-1607, suggested version: 2.5.200

Looks like it requires me to bump that version?

[fbricon]

try running "mvn clean verify -DskipTests -Dtycho.p2.baselineMode=failCommon" locally

[chagong]

@fbricon Looks like over 13 modules need version bumps. Do you want me to do it in this PR?

[fbricon]

@chagong can you do it in a different PR?

[chagong]

@chagong can you do it in a different PR?

#2163

[HannesWell]

Looks like over 13 modules need version bumps. Do you want me to do it in this PR?

I have to say that I'm in strong doubt that this is really necessary. With the information I have, I cannot explain why this would be necessary. Furthermore I also just submitted a PR where this problem didn't surface.

As #2160 (comment) suggests, you definitively need a version increment in org.eclipse.m2e.jdt.
If you'd permit edits by maintainers for this PR, the tooling do everything for you as recommended by this project.
If you don't want to do this, please see the linked FAQ on how to properly apply the version increment (e.g. the separation in another PR).

[HannesWell]

@chagong please rebase this on the latest main. The baseline check should pass now since we had another PR applying the version bump for the touched Plug-in already.

[chagong]

@HannesWell pls let the workflows run.

[HannesWell]

@chagong generally the build looks good now.
If you address the comments above, please also make sure to squash all your changes into one final commit and force push it again to this PR's branch. There is no need to record the development process in git.
Thanks in advance.

[chagong]

@HannesWell resolve your comments, but not sure about the CI failure, seems should not be caused by this PR.

[chagong]

@HannesWell can you take a look?

[chagong]

@fbricon @HannesWell can you let the workflows run?

[chagong]

@fbricon @HannesWell is it ok to merge?

[HannesWell]

It looks better now, but I tried it with the Guava repository and noticed that returning null in getFolder() breaks the import too. See my comment below for details.

Furthermore, please squash all your commits into one with a suitable message for this change (not just an aggregation of all current ones), including the requested change and force push it to this PR's branch.

Then this should be ready.