slachiewicz opened a new pull request, #182: URL: https://github.com/apache/maven-resolver-ant-tasks/pull/182
Aligns what a POM contributes to a `<resolve>` with what the same POM contributes to a Maven build, and adds a test that measures the remaining difference instead of arguing about it. Context is #105, which proposes removing POM support because "the way Ant reads POMs is not identical to Maven, but people's expectation is". Since that was filed against 1.3.1 the model half stopped being ours: 2.0.0 builds the effective model with Maven's own `maven-model-builder`, and the session defaults match Maven 3. What was left was a hand-written model-to-`CollectRequest` conversion that had drifted from `ArtifactDescriptorReaderDelegate`, the code Maven runs for the same job. Changes, one per commit so any of them can be dropped: - Delegate the conversion. The local copy pinned `optional` to `false` rather than carrying the model's tri-state value, so dependency management could no longer manage optionality; delegating fixes that and keeps the two in step for every other field as well. - Set the collect request root artifact from the POM, as Maven does. - Aggregate the POM's `<repositories>` into the repositories resolved against. They were used for parent and import resolution only, so a POM that builds under Maven could still fail to resolve here. This is the one behaviour change with a blast radius; Ant-side repositories stay dominant, and mirrors, proxies and authentication apply. - Unit tests over the conversion, and a parity test that resolves a fixture POM and compares it with recorded `mvn dependency:list` output per scope. The fixture POM carries an imported BOM, a managed version, an exclusion, an optional dependency and one of every scope. Its expectations are recorded Maven output, and their headers carry the Maven version and the command that re-records them. Recording beats invoking Maven from the test because the CI matrix spans Maven 3.9, 3.10 and 4, and a live comparison would assert parity against whichever Maven happens to run the build. Verified: `mvn verify` → 69 tests, green; `mvn verify -Prun-its` → green. Compile, runtime and test classpaths all match `dependency:list` with no difference. Deliberately not changed here: the `<dependencies>`-level `<exclusions>` are still merged into managed dependencies, which Maven does not do. It is redundant rather than wrong, and undoing it is a semantic change to an Ant-only feature. What this does not close: a version-less `<dependency>` against `<dependencyManagement>` still fails validation, the `<dependencyManagement>` type still only feeds `createPom`, and there is no `-P` equivalent. Those are separate. *This change was created with AI assistance.* -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
