Skip to content

Conversation

@gnodet
Copy link
Contributor

@gnodet gnodet commented Oct 8, 2025

This commit fixes issue #11135 where dependencies with missing groupId but present version were not having their groupId inferred from the project groupId in Maven 4.1.0 model version.

The issue was that the groupId inference logic was only triggered when both groupId and version were missing (in the inferDependencyVersion method). However, the issue described cases where dependencies had versions but missing groupIds.

Changes made:

  1. Modified transformFileToRaw method in DefaultModelBuilder to handle missing groupId cases separately from missing version cases
  2. Added new inferDependencyGroupId method that specifically handles groupId inference when version is present
  3. Added unit test to verify the fix works correctly

The fix ensures that for Maven 4.1.0 model version, dependencies with missing groupId will have their groupId inferred from the project groupId, regardless of whether the version is present or not.

Fixes #11135

@gnodet gnodet added bug Something isn't working backport-to-4.0.x labels Oct 8, 2025
This commit fixes issue apache#11135 where dependencies with missing groupId
but present version were not having their groupId inferred from the
project groupId in Maven 4.1.0 model version.

The issue was that the groupId inference logic was only triggered when
both groupId and version were missing (in the inferDependencyVersion
method). However, the issue described cases where dependencies had
versions but missing groupIds.

Changes made:
1. Modified transformFileToRaw method in DefaultModelBuilder to handle
   missing groupId cases separately from missing version cases
2. Added new inferDependencyGroupId method that specifically handles
   groupId inference when version is present
3. Added unit test to verify the fix works correctly

The fix ensures that for Maven 4.1.0 model version, dependencies with
missing groupId will have their groupId inferred from the project
groupId, regardless of whether the version is present or not.

Fixes apache#11135
@gnodet gnodet force-pushed the fix-dependency-groupid-inference-11135 branch from 4edda4a to b09b04c Compare October 9, 2025 05:18
@gnodet gnodet requested a review from cstamas October 9, 2025 07:46
@gnodet gnodet merged commit d4336c6 into apache:master Oct 9, 2025
37 of 38 checks passed
@gnodet
Copy link
Contributor Author

gnodet commented Oct 9, 2025

💚 All backports created successfully

Status Branch Result
maven-4.0.x

Questions ?

Please refer to the Backport tool documentation

@github-actions github-actions bot added this to the 4.1.0 milestone Oct 9, 2025
gnodet added a commit to gnodet/maven that referenced this pull request Oct 9, 2025
…e#11228)

This commit fixes issue apache#11135 where dependencies with missing groupId
but present version were not having their groupId inferred from the
project groupId in Maven 4.1.0 model version.

The issue was that the groupId inference logic was only triggered when
both groupId and version were missing (in the inferDependencyVersion
method). However, the issue described cases where dependencies had
versions but missing groupIds.

Changes made:
1. Modified transformFileToRaw method in DefaultModelBuilder to handle
   missing groupId cases separately from missing version cases
2. Added new inferDependencyGroupId method that specifically handles
   groupId inference when version is present
3. Added unit test to verify the fix works correctly

The fix ensures that for Maven 4.1.0 model version, dependencies with
missing groupId will have their groupId inferred from the project
groupId, regardless of whether the version is present or not.

Fixes apache#11135

(cherry picked from commit d4336c6)
gnodet added a commit that referenced this pull request Oct 9, 2025
… (#11240)

This commit fixes issue #11135 where dependencies with missing groupId
but present version were not having their groupId inferred from the
project groupId in Maven 4.1.0 model version.

The issue was that the groupId inference logic was only triggered when
both groupId and version were missing (in the inferDependencyVersion
method). However, the issue described cases where dependencies had
versions but missing groupIds.

Changes made:
1. Modified transformFileToRaw method in DefaultModelBuilder to handle
   missing groupId cases separately from missing version cases
2. Added new inferDependencyGroupId method that specifically handles
   groupId inference when version is present
3. Added unit test to verify the fix works correctly

The fix ensures that for Maven 4.1.0 model version, dependencies with
missing groupId will have their groupId inferred from the project
groupId, regardless of whether the version is present or not.

Fixes #11135

(cherry picked from commit d4336c6)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

backport-to-4.0.x bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

mvnup apply --infer removes groupId which results in failing build

2 participants