Done at r758244.
Dacapo works for me now
\Harmony\deploy\jdk\jre\bin\java.exe -jar dacapo-2006-10-MR2.jar eclipse
===== DaCapo eclipse starting =====
<setting up workspace...>
<creating
projects..............................................................>
<running tests at level 0...>
<performing build tests...>
org.apache.ant (not open) opening cleaning building
org.junit (not open) opening cleaning building
org.eclipse.osgi (not open) opening cleaning building
<performing type hierarchy tests...>
Hierarchy: org.eclipse.help.internal HelpPlugin
<performing AST tests...>
AST creation: org.eclipse.jdt.internal.compiler.parser
<performing completion tests...>
Completion: Completion>Name>Empty
Completion: Completion>Name>Empty>No Method
<performing search tests...>
Searching: indexing
===== DaCapo eclipse PASSED in 43657 msec =====
Regards,
Tim
Oliver Deakin wrote:
> Ill second the rollback for M9.
>
> Regards,
> Oliver
>
> Tim Ellison wrote:
>> Regis wrote:
>>
>>> Tim Ellison wrote:
>>>
>>>> Regis wrote:
>>>>
>>>>> Sian January wrote:
>>>>>
>>>>>> 8. Dacapo benchmark failure HARMONY-6041
>>>>>>
>>>>> I have found the cause of this regression, and had a initial patch,
>>>>> but
>>>>> still has 1 test failure in WinFileTest. So I suggest revert
>>>>> r727327 if
>>>>> it blocked M9.
>>>>>
>>>> Yes, I think that we should probably roll back r727327 and re-open
>>>> HARMONY-6041.
>>>>
>>> Agree. We have a lot of duplicated code which dealing with path name,
>>> we'll have enough time to refactor it in next milestone.
>>>
>>>
>>>> It seems that the patch was not sufficient, and the subsequent attempts
>>>> to fix things (HARMONY-6090, HARMONY-6091, HARMONY-6092) have not been
>>>> applied, and may cause further disruption.
>>>>
>>>> Since the original problem was found by inspection, I propose we leave
>>>> it as a known issue with M9 and try again after the code freeze.
>>>>
>>> +1
>>>
>>
>> Any committers second the proposal to rollback?
>>
>> Regards,
>> Tim
>>
>>
>>
>