Strip internal module dependencies from ivy.xml before resolve to prevent stale transitive deps#184
Strip internal module dependencies from ivy.xml before resolve to prevent stale transitive deps#184stijn-vranckx wants to merge 3 commits into
Conversation
|
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #184 +/- ##
========================================
Coverage ? 5.45%
========================================
Files ? 59
Lines ? 1393
Branches ? 224
========================================
Hits ? 76
Misses ? 1311
Partials ? 6 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
By removing the internal dependencies you might influence the resolve results, especially wrt conflict manangement. Take your example: If Ivy resolves the dependencies of module A, library X v1 will get evicted by v2. I think the only correct solution here is to write some kind of 'project' resolver, which takes the modules of the project into account when resolving dependencies. Something similar as the (archived) IvyDE Eclipse workspace resolver: https://github.com/apache/ant-ivyde/blob/master/org.apache.ivyde.eclipse/src/java/org/apache/ivyde/internal/eclipse/workspaceresolver/WorkspaceResolver.java |
Replace pre-filtering with workspace module resolver for inter-module dependenciesInstead of filtering internal module dependencies from Key changes:
|
When IvyIDEA resolves Module A that depends on another workspace Module B, Ivy resolves the full dependency tree from the Ivy repository server. Even though IvyIDEA correctly replaces Module B with a module reference, the transitive dependencies resolved from the server's version of Module B (which may be outdated) are still added as external library entries.
Example: Module A depends on Module B. After updating Dependency X from v1 to v2 in Module B's ivy.xml, resolving Module A pulls in both v1 and v2 of Dependency X — v2 from the workspace module reference, and v1 resolved transitively from the server's outdated Module B descriptor.
Root cause:
DependencyResolver.extractDependencies()processes the flattened resolve tree. Even when Module B is correctly detected as an internal module and replaced with a module reference, Module B's transitive dependencies from the server are separate entries in the resolved set and pass through as external dependencies.Fix: Before resolving, identify internal module dependencies and remove them from the ivy descriptor passed to Ivy's resolve engine. This ensures the server is never consulted for workspace modules or their transitive closures. Internal module references are added back manually after resolve via
InternalDependency.Files changed:
DependencyResolver.java— Pre-filter internal deps from the ivy descriptor before resolve; fall back to original behavior on error; addInternalDependencyentries after resolveIntellijModuleDependencies.java— ExposehasInternalDependencies(),getInternalModuleIds(),getAllDependencyModules()