[
http://jira.codehaus.org/browse/MERCURY-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=157672#action_157672
]
Oleg Gusakov commented on MERCURY-40:
-------------------------------------
Looks like I am wrong: it really non-deterministic behavior of the resolver:
* when as the system of inequasions has more'n one solution, optimal selection
is completly in the hands of the optimization function
* optimization function uses GAs to orders GAVs inside
* order of GAs used to create optimization function defines which of otherwise
equivalent solutions is selected
* this GA ordering is defined by a Map's implementation, used by the solver
* HashMap's behavior changed from Java5 to Java6, thus tests failure
* Ben's solution to use LinkedHashMap which has predictable behavior between
Java5 and Java6 seem to fit the bill
I re-implemented Ben's fix and will be running ITs to make sure nothing else
breaks.
Thanks *Ben*!
> DefaultSatSolver is non-deterministic
> -------------------------------------
>
> Key: MERCURY-40
> URL: http://jira.codehaus.org/browse/MERCURY-40
> Project: Mercury
> Issue Type: Bug
> Affects Versions: 1.0.0-alpha-2
> Reporter: Benjamin Bentmann
> Attachments: mercury-failed.txt, mercury-passed.txt,
> org.apache.maven.mercury.metadata.sat.DefaultSatSolverTest.txt
>
>
> Running the unit test {{DefaultSatSolverTest.testSingleVersionResolution()}}
> once on Java 1.5 and 1.6 revealed a bug in {{DefaultSatSolver.solve()}} due
> to usage of {{HashMap}}. See attached logs (passed with 1.5, failed with 1.6).
> The internal tweaks to the hash algos employed by the different JRE versions
> exhibited a non-deterministic ordering of the artifact metadata list.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
