IVY-1653: `makepom`: write overrides to Maven `dependencyManagement` section by eric-milles · Pull Request #114 · apache/ant-ivy

eric-milles · 2025-08-08T16:43:49Z

Inspect the DependencyDescriptorMediator objects of ModuleDescriptor to represent overrides in Maven's dependencyManagement element.

https://issues.apache.org/jira/browse/IVY-1653

maartenc · 2025-08-14T19:32:01Z

I'm wondering what happens if you specify the organisation in the override, like in the example in the JIRA.
Will that give issues with the generated pom file? Will Maven be able to handle that?

eric-milles · 2025-08-15T13:30:27Z

This test case does just that:

ant-ivy/test/java/org/apache/ivy/core/module/descriptor/IvyMakePomTest.java

Line 157 in 29d68b0

" <groupId>org.aspectj</groupId>",

maartenc · 2025-08-18T08:10:36Z

Sure, but how does Maven handle the '*' artifactId? Does that work?

<dependency>
  <groupId>org.aspectj</groupId>
  <artifactId>*</artifactId>
  <version>1.9.24</version>
</dependency>

eric-milles · 2025-08-18T14:18:58Z

I'd have to try that with maven. Is there a concern that lots of top-level overrides are in use? Could this get taken as-is and if we find a compatibility problem, work it as a new issue?

maartenc · 2025-08-18T14:31:00Z

If maven gives errors on these wildcards, perhaps we could only add it to the dependencymanagement if the Ivy-override is fully specified (read: both groupId and artifactId have a non-wildcard value) ?
If maven doesn't complain about this wildcard, than we can just generate it like this PR does.

We should try to avoid generating pom.xml files that cannot be handled by Maven.

eric-milles · 2025-08-18T14:44:56Z

[ERROR] 'dependencyManagement.dependencies.dependency.artifactId' for org.eclipse.tycho:*:jar with value '*' does not match a valid id pattern.

eric-milles · 2025-08-18T16:21:19Z

I fixed the tests to write proper artifactId elements.

maartenc · 2025-08-18T17:46:00Z

src/java/org/apache/ivy/plugins/parser/m2/PomModuleDescriptorWriter.java

+        ModuleRules<DependencyDescriptorMediator> mr = md.getAllDependencyDescriptorMediators();
+        if (mr.getAllRules().isEmpty()) {
+            return;
+        }


Perhaps also return here if none of the rules are an instance of non-wildcard OverrideDependencyDescriptorMediator.
This way, we avoid an empty <dependencyManagement>/<dependencies>-construct if container was true.

Sure -- I tried to keep it simple instead of building up a filtered collection.

maartenc · 2025-08-18T17:52:37Z

test/java/org/apache/ivy/core/module/descriptor/IvyMakePomTest.java

+        };
+
+        assertEquals(String.join(System.lineSeparator(), expect), readFileToString(pomFile, "UTF-8"));
+    }


Could you also add a test case for updating a template pom.xml that already has a dependencyManagement section, and we have an ivy.xml with an override element. (just to verify that an existing dependencyManagent gets updated correctly).

maartenc · 2025-08-18T17:57:33Z

test/java/org/apache/ivy/core/module/descriptor/IvyMakePomTest.java

 public class IvyMakePomTest {

-    private Project project;
+    private Project project = TestHelper.newProject();


This isn't the same as creating a new project in a @before method.
Now, the same project is reused for every IvyMakePom task in the test methods.
Before, every task had a new project.
I'm not saying this is a problem per se, but why change it? Did it cause issues?

In JUnit 4, a new instance of the test class is created for each test case. You are describing the JUnit 3 behavior.

maartenc · 2025-08-18T18:01:29Z

META-INF/MANIFEST.MF

 org.apache.ivy.plugins.pack;version="2.6.0",
 org.apache.ivy.plugins.parser;version="2.0.0",
- org.apache.ivy.plugins.parser.m2;version="2.0.0",
+ org.apache.ivy.plugins.parser.m2;version="2.6.0",


Just out of curiousity, is this Eclipse that's doing this for you?

I am doing this. If you look at the 2.5.3 manifest, all the versions are stuck at 2.0.0 which is not really proper for OSGi.

maartenc · 2025-08-18T18:04:43Z

src/java/org/apache/ivy/plugins/parser/m2/PomModuleDescriptorWriter.java

-                    dependenciesPrinted = true;
-                }
+                    if (line.contains("</dependencyManagement>")) {
+                        dependencyManagement = false;


I think you should also check here that any overrides are printed.
This to tackle the case where the template contains an empty <dependencyManagent> element (without <dependencies> subelement)

Yes, I suppose that's possible. Was just handling likely scenarios first.

maartenc · 2025-08-18T18:06:17Z

I've added some comments, could you have a look?

eric-milles · 2025-08-18T18:50:20Z

I will get to your feedback on this one. Now that <override org="abc" rev="123" /> doesn't work, this drops in usefulness for me.

eric-milles · 2025-08-18T18:50:51Z

Could you review my PRs from oldest to newest?

bodewig · 2026-02-14T19:45:21Z

I will get to your feedback on this one. Now that <override org="abc" rev="123" /> doesn't work, this drops in usefulness for me.

I'm not deeply involved with Ivy so please bear with my ignorance.

Which effect do you expect a rule without a module attribute to have on a generated POM? Have Ivy find all transitive dependencies of explicit dependencies and add something to the POM replacing the * with all modules/artifacts found?

eric-milles · 2026-02-15T16:06:11Z

This is still in draft form since there are some compat issues raised that are not easily solved. You can ignore this until it is marked ready for review.

IVY-1653: makepom: write overrides to Maven dependencyManagement section

43efc0e

eric-milles force-pushed the IVY-1653 branch from 29d68b0 to 43efc0e Compare August 18, 2025 16:19

maartenc reviewed Aug 18, 2025

View reviewed changes

eric-milles marked this pull request as draft September 3, 2025 18:01

Conversation

eric-milles commented Aug 8, 2025

Uh oh!

maartenc commented Aug 14, 2025

Uh oh!

eric-milles commented Aug 15, 2025

Uh oh!

maartenc commented Aug 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

eric-milles commented Aug 18, 2025

Uh oh!

maartenc commented Aug 18, 2025

Uh oh!

eric-milles commented Aug 18, 2025

Uh oh!

eric-milles commented Aug 18, 2025

Uh oh!

maartenc Aug 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

eric-milles Aug 18, 2025

Choose a reason for hiding this comment

Uh oh!

maartenc Aug 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

maartenc Aug 18, 2025

Choose a reason for hiding this comment

Uh oh!

eric-milles Aug 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

maartenc Aug 18, 2025

Choose a reason for hiding this comment

Uh oh!

eric-milles Aug 18, 2025

Choose a reason for hiding this comment

Uh oh!

maartenc Aug 18, 2025

Choose a reason for hiding this comment

Uh oh!

eric-milles Aug 18, 2025

Choose a reason for hiding this comment

Uh oh!

maartenc commented Aug 18, 2025

Uh oh!

eric-milles commented Aug 18, 2025

Uh oh!

eric-milles commented Aug 18, 2025

Uh oh!

bodewig commented Feb 14, 2026

Uh oh!

eric-milles commented Feb 15, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

maartenc commented Aug 18, 2025 •

edited

Loading

maartenc Aug 18, 2025 •

edited

Loading

maartenc Aug 18, 2025 •

edited

Loading

eric-milles Aug 18, 2025 •

edited

Loading