[
https://issues.apache.org/jira/browse/IVY-644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543578
]
Gilles Scokart commented on IVY-644:
------------------------------------
I'm not sure of what should be the right fix for that.
Here is a summary of the problem:
We have :
M1 -> M2 in conf runtime,
M1 -> M3 in conf test
M1 -> M4 1.1 in conf test
with conf test extending runtime.
And :
M2->M4 1.0
M3->M4 1.2
The problem happen when we resolve test conf first, then runtime.
When the root configuration test is resolved. M4 1.1 is evicted by 1.2.
Then we resolve the root configuration runtime, only M4 1.0 is involved.
However, as the conflict in other conf was detected before, M4 1.0 is flagged
as evicted by 1.1 in root configuration runtime. This eviction transfer the
usage of 1.0 to usage of 1.1 (method updateDataFrom). However, as 1.1 is not
included in the root configuration runtime, is is never processed anymore. And
M4 1.1 stays with a rootModuleConfs = 'runtime' -> 'compile' transferred from
1.0 while the eviction data only refers to test root configuration.
This trigger the NPE when the report is produced. Indeed, the report expects
that all modules not completely evicted are loaded (and 1.1 is not loaded but
is not flagged as evicted for root config runtime).
I don't know what the right fix is.
One aproach should be to resolve every root configuration entirely separately,
then resolve the conflict accros them. I managed to do the first part by
modifying the ResolveEngine.computeConflicts to only take into account the
conflict is the configuration currently resolved. But for the second part
(resolve the conflict accross configuration), I didn't manage to find the right
data in the method ResolveEngine.getDependencies.
An other aproach would be to transfer the usage to the latest 'evicter' when a
conflict is found. I tried to update IvyNode.updateDataFrom, but I don't think
it will works when the node is evicted transitevely.
Finally, I'm not sure of what the final result should be when 2 root confs have
conflict.
Anyone has an idea?
> NPE in case of eviction by 2 other modules on different confs
> -------------------------------------------------------------
>
> Key: IVY-644
> URL: https://issues.apache.org/jira/browse/IVY-644
> Project: Ivy
> Issue Type: Bug
> Affects Versions: 2.0.0-beta-1
> Reporter: Gilles Scokart
>
> java.lang.NullPointerException
> at org.apache.ivy.core.resolve.IvyNode.getArtifacts(IvyNode.java:759)
> at
> org.apache.ivy.core.resolve.IvyNode.getSelectedArtifacts(IvyNode.java:731)
> at
> org.apache.ivy.core.report.ResolveReport.setDependencies(ResolveReport.java:172)
> at
> org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:233)
> at
> org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:194)
> at org.apache.ivy.Ivy.resolve(Ivy.java:256)
> at org.apache.ivy.ant.IvyResolve.doExecute(IvyResolve.java:212)
> at org.apache.ivy.ant.IvyTask.execute(IvyTask.java:281)
> at
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
> at org.apache.tools.ant.Task.perform(Task.java:364)
> at org.apache.tools.ant.Target.execute(Target.java:341)
> at org.apache.tools.ant.Target.performTasks(Target.java:369)
> at
> org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
> at org.apache.tools.ant.Project.executeTarget(Project.java:1185)
> at
> org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:40)
> at org.apache.tools.ant.Project.executeTargets(Project.java:1068)
> at org.apache.tools.ant.Main.runBuild(Main.java:668)
> at org.apache.tools.ant.Main.startAnt(Main.java:187)
> at org.apache.tools.ant.launch.Launcher.run(Launcher.java:246)
> at org.apache.tools.ant.launch.Launcher.main(Launcher.java:67)
> This error seems to happen because an evicted modules is not loaded by not
> flagged as completely evicted neither. I think t happens when we have two
> evicted revisions that are actually used in different configurations. I will
> try to isaolate beter.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
