Hi Stefan, thanks for looking into this. After having a quick look at the diffs and without being able to look into the code myself, I think I prefer your approach to solve the issue.
Maybe Jaikiran can remember more details, but I'd go for backing out the changes to IvyNodeUsage and push your fix. Maarten Op vrijdag 14 april 2023 om 12:56:00 CEST schreef Stefan Bodewig <bode...@apache.org>: Hi all tldr; there is a bug report about Ivy no handling dependencies to modules with multiple artifacts - some with classifier, but not all - and the way I fixed this seems to work. But I have no idea whether I am fixing it the correct way and need help by somebody understanding Ivy' semantics - I don't. longer story: Over on the ivy-user list somebody reported Ivy would only resolve the "data" classified artifact as transitive dependency of Saxon-HE where Saxon's POM contains <dependency> <groupId>org.xmlresolver</groupId> <artifactId>xmlresolver</artifactId> <version>5.1.1</version> </dependency> <dependency> <groupId>org.xmlresolver</groupId> <artifactId>xmlresolver</artifactId> <version>5.1.1</version> <classifier>data</classifier> </dependency> and yes, this is true for the current master branch. This is the ivy.xml created from the POM snippet above <dependency org="org.xmlresolver" name="xmlresolver" rev="5.1.1" force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"> <artifact name="xmlresolver" type="jar" ext="jar" conf="compile" m:classifier="data"/> </dependency> I created https://issues.apache.org/jira/browse/IVY-1642 and tried to fix it. My understanding was that this Ivy dependency means Saxon-HE depends on the "data" artifact and only the data artifact and the correct solution would be to add a second artifact that matches the "default" name/type/ext. So I "fixed" PomModuleDescriptorBuilder to do what I believed to be the correct translation of the POM. When I ran the tests ResolveTest#testIvy1580 failed. The modified code would suddenly return three artifacts as dependency not two as expected. The non-classifier artifact was returned twice. First of all this made me discover https://issues.apache.org/jira/browse/IVY-1580 which, I believe, describes the same error as the new IVY-1642. Jaikiran fixed the problem back then with https://github.com/apache/ant-ivy/commit/d714d9dffbaa2c91855297a7df1c5d9ddfe6d0b0 . He tackled it from a different angle, rather than changing the way POM dependencies are translated he changed the way dependencies are resolved by throwing in an "include everything" rule under certain circumstances. I must admit this change is beyond my understanding of Ivy. Backing out his change to IvyNodeUsage fixed the test in my branch. So maybe my change alone would be enough to resolve the problem? Or there are two different issues at hand and each of us just fixed one part of it? In my branch I decided to keep the IVY-1580 change and "fix" the test by making sure Ivy's reported dependencies don't contain any duplicates. The result can be seen here https://github.com/apache/ant-ivy/compare/ivy-1642 I must admit that I just don't know whether this is correct - apart from that it fixes the bug reproducer for IVY-1642. I'll be grateful for any insight Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
