Skip to content

Fix integration tests to use correct Maven version instead of hardcoded 2.1-SNAPSHOT #2476

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 8 commits into from
Jun 24, 2025

Conversation

gnodet
Copy link
Contributor

@gnodet gnodet commented Jun 13, 2025

Problem

The integration tests were using hardcoded Maven version 2.1-SNAPSHOT instead of dynamically using the version of Maven being tested (4.0.0-rc-4-SNAPSHOT). This caused dependency resolution failures when trying to build the integration test support artifacts:

Caused by: org.eclipse.aether.transfer.ArtifactNotFoundException: Could not find artifact org.apache.maven:maven-plugin-api:jar:2.1-SNAPSHOT in apache.snapshots

Root Cause

The issue was in Maven property resolution:

  • Parent POM (its/pom.xml) had dependency management using ${project.version}
  • When inherited by child projects (support artifacts with version 2.1-SNAPSHOT), the ${project.version} was evaluated in the context of the child project instead of the parent
  • This caused Maven dependencies to resolve to 2.1-SNAPSHOT instead of 4.0.0-rc-4-SNAPSHOT

Solution

  1. Added explicit maven-version property in its/pom.xml set to 4.0.0-rc-4-SNAPSHOT
  2. Updated all Maven dependency management entries to use ${maven-version} instead of ${project.version}
  3. Added missing maven-executor dependency to dependency management
  4. Removed conflicting dependency management from core-it-support/pom.xml

Key Changes

its/pom.xml

<properties>
  <!-- Maven version being tested - must match the parent project version -->
  <maven-version>4.0.0-rc-4-SNAPSHOT</maven-version>
  <!-- Support artifacts version - kept separate from Maven version -->
  <core-it-support-version>2.1-SNAPSHOT</core-it-support-version>
</properties>

<dependencyManagement>
  <dependencies>
    <!-- All Maven dependencies now use ${maven-version} -->
    <dependency>
      <groupId>org.apache.maven</groupId>
      <artifactId>maven-plugin-api</artifactId>
      <version>${maven-version}</version>
    </dependency>
    <dependency>
      <groupId>org.apache.maven</groupId>
      <artifactId>maven-core</artifactId>
      <version>${maven-version}</version>
    </dependency>
    <dependency>
      <groupId>org.apache.maven</groupId>
      <artifactId>maven-executor</artifactId>
      <version>${maven-version}</version>
    </dependency>
    <!-- ... all other Maven dependencies ... -->
  </dependencies>
</dependencyManagement>

its/core-it-support/pom.xml

  • Removed duplicate dependency management that was overriding parent settings
  • Removed conflicting maven-version property
  • Now properly inherits Maven dependency versions from parent

its/core-it-support/maven-it-helper/pom.xml

  • Removed explicit versions from Maven dependencies to inherit from parent dependency management

Testing

Build Test: mvn install -Prun-its -DskipTests now PASSES
Dependency Resolution: Maven dependencies correctly resolve to 4.0.0-rc-4-SNAPSHOT
No More Errors: No more 2.1-SNAPSHOT dependency resolution failures
Integration Test Setup: Build progresses to final step (unpacking Maven distribution)
Support Artifacts: All integration test support artifacts build successfully

Verification

Before (dependency resolution failure):

<dependency>
  <groupId>org.apache.maven</groupId>
  <artifactId>maven-plugin-api</artifactId>
  <version>2.1-SNAPSHOT</version>  <!-- ❌ Wrong version, doesn't exist -->
</dependency>

After (correct dependency resolution):

<dependency>
  <groupId>org.apache.maven</groupId>
  <artifactId>maven-plugin-api</artifactId>
  <version>4.0.0-rc-4-SNAPSHOT</version>  <!-- ✅ Correct version -->
</dependency>

Impact

This fix ensures that:

  • ✅ Integration tests use the correct Maven version being tested (4.0.0-rc-4-SNAPSHOT)
  • ✅ No more hardcoded version dependencies that break when Maven version changes
  • ✅ Support artifacts properly reference Maven dependencies with the right version
  • ✅ The build system is more maintainable and version-agnostic
  • ✅ Integration tests can be built and run successfully

Files Modified

  • its/pom.xml - Added maven-version property and updated dependency management
  • its/core-it-support/pom.xml - Removed conflicting dependency management
  • its/core-it-support/maven-it-helper/pom.xml - Removed explicit Maven dependency versions

Fixes dependency resolution issues in integration tests and makes them work correctly with the current Maven version being tested.

gnodet added 8 commits June 13, 2025 08:15
Switch default behavior from using build Maven installation to testing
the Maven distribution generated by the current build. This eliminates
the need for manual version updates during releases.

- Remove hardcoded maven-version property
- Align its/ and core-it-suite/ versions with parent project
- Keep core-it-support/ artifacts at stable 2.1-SNAPSHOT version
- Add maven-from-build profile to preserve old behavior
- Update documentation for new usage patterns

Default: mvn clean test -Prun-its (tests built distribution)
Old behavior: mvn clean test -Prun-its,maven-from-build
Add maven-version property to core-it-support/pom.xml that references
the parent version (4.0.0-rc-4-SNAPSHOT) to resolve the dependency
version for maven-executor in maven-it-helper.

This fixes the build error:
'dependencies.dependency.version' for maven-executor must be a valid version but is '${maven-version}'
The integration-tests job needs to use the maven-from-build profile
since it downloads and uses the built Maven distribution to run the build.

Cannot update the workflow directly due to GitHub security restrictions
requiring workflow scope for OAuth apps.
The issue is that the new default behavior expects the distribution at
apache-maven/target/ but the CI downloads it as an artifact. The solution
is to copy the downloaded distribution to the expected location.
The file was causing RAT (Release Audit Tool) failures due to missing
Apache license header. The workflow update information is already
documented in the PR description.
Spotless moved the properties section to follow standard POM element order
(after modules, before dependencyManagement).
This ensures that the support artifacts use the correct Maven version
(4.0.0-rc-4-SNAPSHOT) instead of their own version (2.1-SNAPSHOT) when
referencing Maven dependencies like maven-plugin-api and maven-core.

The maven-version property is set to the correct Maven version being tested.
- Add maven-version property to its/pom.xml set to 4.0.0-rc-4-SNAPSHOT
- Update all Maven dependency management entries to use maven-version property
- Add maven-executor to dependency management
- Remove duplicate dependency management from core-it-support/pom.xml

This ensures that integration test support artifacts use the correct Maven
version (4.0.0-rc-4-SNAPSHOT) for Maven dependencies instead of their own
version (2.1-SNAPSHOT), fixing dependency resolution issues.
@gnodet gnodet changed the title Change integration tests default to use built Maven distribution Fix integration tests to use correct Maven version instead of hardcoded 2.1-SNAPSHOT Jun 13, 2025
@@ -23,7 +23,7 @@ under the License.
<parent>
<groupId>org.apache.maven.its</groupId>
<artifactId>core-its</artifactId>
<version>2.1-SNAPSHOT</version>
<version>4.0.0-rc-4-SNAPSHOT</version>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is there any way this can be parameterized so we don;t have to keep changing it with every version?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maven 4 can infer the version of the parent. But for Maven 3, it is required (and the project's version itself is inferred from the parent version).
But the goal is to exactly avoid having to update it when releasing, as the release plugin does indeed update all project's version.

@gnodet gnodet added this to the 4.1.0 milestone Jun 24, 2025
@gnodet gnodet merged commit 0c5b2ad into apache:master Jun 24, 2025
36 of 38 checks passed
@gnodet gnodet deleted the feature/its-default-built-distribution branch June 24, 2025 16:01
@gnodet gnodet added the chore label Jun 24, 2025
@gnodet gnodet self-assigned this Jun 24, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants