Re: [build] status
As I said in the accordig JIRA we should use properties from the file
or remove that commented properties from the properties file.
This properties are misleading people.
SY, Alexey
21 Jul 2006 10:53:08 +0700, Egor Pasko [EMAIL PROTECTED]:
On the 0x1AC day of Apache Harmony Anton Luht wrote:
Hello buildmasters,
One note: ant fetch-depends seem not to work behind proxy - it fails
after timeout. Adding proxy settings to depends.properties didn't
help.
The problem solved after I've added
setproxy proxyhost=${http.proxyHost}
proxyport=${http.proxyPort}/
in the beginning of 'download' target in depends.xml
Known issue. I do it with:
$ export ANT_OPTS=-Dhttp.proxyHost=XXX -Dhttp.proxyPort=YYY
$ ant fetch-depends
--
Egor Pasko, Intel Managed Runtime Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Alexey A. Petrenko
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build] status
Agree. I was confused when I saw it the first time.
Regards,
2006/7/21, Alexey Petrenko [EMAIL PROTECTED]:
As I said in the accordig JIRA we should use properties from the file
or remove that commented properties from the properties file.
This properties are misleading people.
SY, Alexey
21 Jul 2006 10:53:08 +0700, Egor Pasko [EMAIL PROTECTED]:
On the 0x1AC day of Apache Harmony Anton Luht wrote:
Hello buildmasters,
One note: ant fetch-depends seem not to work behind proxy - it fails
after timeout. Adding proxy settings to depends.properties didn't
help.
The problem solved after I've added
setproxy proxyhost=${http.proxyHost}
proxyport=${http.proxyPort}/
in the beginning of 'download' target in depends.xml
Known issue. I do it with:
$ export ANT_OPTS=-Dhttp.proxyHost=XXX -Dhttp.proxyPort=YYY
$ ant fetch-depends
--
Egor Pasko, Intel Managed Runtime Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Alexey A. Petrenko
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Alexei Zakharov,
Intel Middleware Product Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build] status
I've filed JIRA issue: http://issues.apache.org/jira/browse/HARMONY-943
Please vote for it! :)
SY, Alexey
2006/7/21, Alexei Zakharov [EMAIL PROTECTED]:
Agree. I was confused when I saw it the first time.
Regards,
2006/7/21, Alexey Petrenko [EMAIL PROTECTED]:
As I said in the accordig JIRA we should use properties from the file
or remove that commented properties from the properties file.
This properties are misleading people.
SY, Alexey
21 Jul 2006 10:53:08 +0700, Egor Pasko [EMAIL PROTECTED]:
On the 0x1AC day of Apache Harmony Anton Luht wrote:
Hello buildmasters,
One note: ant fetch-depends seem not to work behind proxy - it fails
after timeout. Adding proxy settings to depends.properties didn't
help.
The problem solved after I've added
setproxy proxyhost=${http.proxyHost}
proxyport=${http.proxyPort}/
in the beginning of 'download' target in depends.xml
Known issue. I do it with:
$ export ANT_OPTS=-Dhttp.proxyHost=XXX -Dhttp.proxyPort=YYY
$ ant fetch-depends
--
Egor Pasko, Intel Managed Runtime Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Alexey A. Petrenko
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Alexei Zakharov,
Intel Middleware Product Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Alexey A. Petrenko
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build] status
Too late to vote, it's already closed. :)
Regards,
2006/7/21, Alexey Petrenko [EMAIL PROTECTED]:
I've filed JIRA issue: http://issues.apache.org/jira/browse/HARMONY-943
Please vote for it! :)
SY, Alexey
2006/7/21, Alexei Zakharov [EMAIL PROTECTED]:
Agree. I was confused when I saw it the first time.
Regards,
2006/7/21, Alexey Petrenko [EMAIL PROTECTED]:
As I said in the accordig JIRA we should use properties from the file
or remove that commented properties from the properties file.
This properties are misleading people.
SY, Alexey
21 Jul 2006 10:53:08 +0700, Egor Pasko [EMAIL PROTECTED]:
On the 0x1AC day of Apache Harmony Anton Luht wrote:
Hello buildmasters,
One note: ant fetch-depends seem not to work behind proxy - it fails
after timeout. Adding proxy settings to depends.properties didn't
help.
The problem solved after I've added
setproxy proxyhost=${http.proxyHost}
proxyport=${http.proxyPort}/
in the beginning of 'download' target in depends.xml
Known issue. I do it with:
$ export ANT_OPTS=-Dhttp.proxyHost=XXX -Dhttp.proxyPort=YYY
$ ant fetch-depends
--
Egor Pasko, Intel Managed Runtime Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Alexey A. Petrenko
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Alexei Zakharov,
Intel Middleware Product Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Alexey A. Petrenko
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Alexei Zakharov,
Intel Middleware Product Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build] status
Yep, Mark is lightning fast! :)
2006/7/21, Alexei Zakharov [EMAIL PROTECTED]:
Too late to vote, it's already closed. :)
Regards,
2006/7/21, Alexey Petrenko [EMAIL PROTECTED]:
I've filed JIRA issue: http://issues.apache.org/jira/browse/HARMONY-943
Please vote for it! :)
SY, Alexey
2006/7/21, Alexei Zakharov [EMAIL PROTECTED]:
Agree. I was confused when I saw it the first time.
Regards,
2006/7/21, Alexey Petrenko [EMAIL PROTECTED]:
As I said in the accordig JIRA we should use properties from the file
or remove that commented properties from the properties file.
This properties are misleading people.
SY, Alexey
21 Jul 2006 10:53:08 +0700, Egor Pasko [EMAIL PROTECTED]:
On the 0x1AC day of Apache Harmony Anton Luht wrote:
Hello buildmasters,
One note: ant fetch-depends seem not to work behind proxy - it fails
after timeout. Adding proxy settings to depends.properties didn't
help.
The problem solved after I've added
setproxy proxyhost=${http.proxyHost}
proxyport=${http.proxyPort}/
in the beginning of 'download' target in depends.xml
Known issue. I do it with:
$ export ANT_OPTS=-Dhttp.proxyHost=XXX -Dhttp.proxyPort=YYY
$ ant fetch-depends
--
Egor Pasko, Intel Managed Runtime Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Alexey A. Petrenko
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Alexei Zakharov,
Intel Middleware Product Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Alexey A. Petrenko
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Alexei Zakharov,
Intel Middleware Product Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Alexey A. Petrenko
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build] status
The issue mentioned below disapperead after the latest changes for class library. Nevertheless I'm not clear a clue for this build error. In any case thanks for this fix. Vladimir. On 7/19/06, Vladimir Gorr [EMAIL PROTECTED] wrote: Can anybody say about the build status on Windows we have now? Unfortunately, I cannot build for the recent sources due to the following issue: [exec] winFont.obj : error LNK2019: unresolved external symbol void __cde l throwNPException(struct JNIEnv_ *,char const *) ( ?throwNPException@@YAXPAUJN Env_@@[EMAIL PROTECTED]) referenced in function _Java_org_apache_harmony_awt_gl_font_Native [EMAIL PROTECTED] [exec] ..\fontlib.dll : fatal error LNK1120: 1 unresolved externals [exec] NMAKE : fatal error U1077: 'link' : return code '0x460' [exec] Stop. Any ideas? Thanks, Vladimir. On 7/19/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Nathan Beyer wrote: -Original Message- From: Geir Magnusson Jr [mailto: [EMAIL PROTECTED] Paulex Yang wrote: I think Richard's patch is fine, i.e., specify a locale to the test, what we want to test is toPattern()'s logic, not the locale data or something, and the specified locale is OK to test the logic. And I also think maybe one locale is not enough, so we may want to include some more exceptional locale, say, en_UK in this case, by which, we can try to follow RI as possible. Loose the test by removing the assertion here is dangerous, just like any other cases without clear spec. I think what this proved to us is that our testing matrix must include WinXP en_US, en_UK, en_RU etc. Locale-sensitive testing is pragmatically only necessary on a small subset of Harmony's modules (for example, text); this could be isolated to the build scripts of those modules. A trivial implementation would be to setup a list of locales to test, iterate the modules suite of tests for each locale and set the default locale respective to the iteration. Sure, although I don't know how to flip locale programmatically from ant in windows :) I do know how to ask Tim, Stephan, Paulex and myself to run the same tests :) geir -Nathan IOW, we want to run our test suite on as many locale's as possible, and have it pass on every one of them. We may choose local-specific tests, btw, which is what I think you are suggesting. geir Geir Magnusson Jr wrote: What do you suggest then? Paulex Yang wrote: Geir Magnusson Jr wrote: Then I guess we just fix the test. Agree, just think we should not fix the test by removing the assertion. geir Paulex Yang wrote: Tim Ellison wrote: Geir Magnusson Jr wrote: Now, on my windows box I got a clean build, no failures hm. The test works on en_US locale and fails on en_UK. I'm guessing that your machine is set up as en_US. Richard offered a patch that sets the locale to en_US for all MessageFormatTest-s, but I suggested that was not a suitable solution. For now I suggest we remove the assertion, since it is beyond the spec requirements for this type. Tim, Should we also consider the principle of follow the RI here? I think it is a sample of unclear spec, and we should assert if our implementation follows RI, i.e., the assert about return value of toPattern() is necessary. The issue here is just that the testcase assumes the return value is locale-independent, so I think Richard's patch is OK. Further, from the test perspective, maybe(just maybe) test case on only one locale is not enough to check Harmony's toPattern() logic, tests on more different locale(especially the 'exceptional' case like en_UK) are better. Also FYI, I tried the original test case with RI on en_UK locale, and it failed exactly as Harmony. Regards, Tim Geir Magnusson Jr wrote: This is nuts. We need to chase down the commit that broke this, and reverse it. We can't have a broken build persisting this long. geir Tim Ellison wrote: (1) Linux build/tests are passing again, but for some reason the 'BUILD SUCCESSFUL' note didn't go to the commit list? (2) Windows build/test is still failing with: Wrong full date pattern expected:...full... but was:...long... junit.framework.ComparisonFailure: Wrong full date pattern expected:...full... but was:...long... at org.apache.harmony.text.tests.java.text.MessageFormatTest.test_applyPatter nLjava_lang_String(MessageFormatTest.java:244) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) Regards, Tim - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
Re: [build] status
This was the build break I tried to own up to yesterday. It was caused by my refactoring of exception function - to have one set not several. (I missed the extern C clause and included it in some C++ code.) -Mark. On 20 July 2006 at 14:30, Vladimir Gorr [EMAIL PROTECTED] wrote: The issue mentioned below disapperead after the latest changes for class library. Nevertheless I'm not clear a clue for this build error. In any case thanks for this fix. Vladimir. On 7/19/06, Vladimir Gorr [EMAIL PROTECTED] wrote: Can anybody say about the build status on Windows we have now? Unfortunately, I cannot build for the recent sources due to the following issue: [exec] winFont.obj : error LNK2019: unresolved external symbol void __cde l throwNPException(struct JNIEnv_ *,char const *) ( ?throwNPException@@YAXPAUJN Env_@@[EMAIL PROTECTED]) referenced in function _Java_org_apache_harmony_awt_gl_font_Native [EMAIL PROTECTED] [exec] ..\fontlib.dll : fatal error LNK1120: 1 unresolved externals [exec] NMAKE : fatal error U1077: 'link' : return code '0x460' [exec] Stop. Any ideas? Thanks, Vladimir. On 7/19/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Nathan Beyer wrote: -Original Message- From: Geir Magnusson Jr [mailto: [EMAIL PROTECTED] Paulex Yang wrote: I think Richard's patch is fine, i.e., specify a locale to the test, what we want to test is toPattern()'s logic, not the locale data or something, and the specified locale is OK to test the logic. And I also think maybe one locale is not enough, so we may want to include some more exceptional locale, say, en_UK in this case, by which, we can try to follow RI as possible. Loose the test by removing the assertion here is dangerous, just like any other cases without clear spec. I think what this proved to us is that our testing matrix must include WinXP en_US, en_UK, en_RU etc. Locale-sensitive testing is pragmatically only necessary on a small subset of Harmony's modules (for example, text); this could be isolated to the build scripts of those modules. A trivial implementation would be to setup a list of locales to test, iterate the modules suite of tests for each locale and set the default locale respective to the iteration. Sure, although I don't know how to flip locale programmatically from ant in windows :) I do know how to ask Tim, Stephan, Paulex and myself to run the same tests :) geir -Nathan IOW, we want to run our test suite on as many locale's as possible, and have it pass on every one of them. We may choose local-specific tests, btw, which is what I think you are suggesting. geir Geir Magnusson Jr wrote: What do you suggest then? Paulex Yang wrote: Geir Magnusson Jr wrote: Then I guess we just fix the test. Agree, just think we should not fix the test by removing the assertion. geir Paulex Yang wrote: Tim Ellison wrote: Geir Magnusson Jr wrote: Now, on my windows box I got a clean build, no failures hm. The test works on en_US locale and fails on en_UK. I'm guessing that your machine is set up as en_US. Richard offered a patch that sets the locale to en_US for all MessageFormatTest-s, but I suggested that was not a suitable solution. For now I suggest we remove the assertion, since it is beyond the spec requirements for this type. Tim, Should we also consider the principle of follow the RI here? I think it is a sample of unclear spec, and we should assert if our implementation follows RI, i.e., the assert about return value of toPattern() is necessary. The issue here is just that the testcase assumes the return value is locale-independent, so I think Richard's patch is OK. Further, from the test perspective, maybe(just maybe) test case on only one locale is not enough to check Harmony's toPattern() logic, tests on more different locale(especially the 'exceptional' case like en_UK) are better. Also FYI, I tried the original test case with RI on en_UK locale, and it failed exactly as Harmony. Regards, Tim Geir Magnusson Jr wrote: This is nuts. We need to chase down the commit that broke this, and reverse it. We can't have a broken build persisting this long. geir Tim Ellison wrote: (1) Linux build/tests are passing again, but for some reason the 'BUILD SUCCESSFUL' note didn't go to the commit list? (2) Windows build/test is still failing with: Wrong full date pattern expected:...full... but was:...long
Re: [build] status
Hello buildmasters,
One note: ant fetch-depends seem not to work behind proxy - it fails
after timeout. Adding proxy settings to depends.properties didn't
help.
The problem solved after I've added
setproxy proxyhost=${http.proxyHost} proxyport=${http.proxyPort}/
in the beginning of 'download' target in depends.xml
--
Regards,
Anton Luht,
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[testing] locale dependent tests (was: Re: [build] status)
Richard Liang wrote: Although the spec does not require the round-trip of applyPattern and toPattern, we still want to get one *certain* pattern through toPattern. Now the problem is the returned pattern is locale-dependent. I'm uncertain about the reason to remove the assertion: 1) Because the behavior is not required by spec, or 2) Because the behavior is locale-dependent It would seem that rather than forcing the locale to be en_US to make the test assertions valid, you could work with the default locale and guard any assertions that are locale-specific. It would seem a shame to loose the diversity of testing on multiple locale machines if the tests always force everyone to look like an American (horror! ;-) ) I would expect the fix therefore to be something like, if locale is en_US go ahead and assert more round-tripping code, otherwise can't test it as the spec allows variances. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build] status
Can anybody say about the build status on Windows we have now? Unfortunately, I cannot build for the recent sources due to the following issue: [exec] winFont.obj : error LNK2019: unresolved external symbol void __cde l throwNPException(struct JNIEnv_ *,char const *) ( ?throwNPException@@YAXPAUJN Env_@@[EMAIL PROTECTED]) referenced in function _Java_org_apache_harmony_awt_gl_font_Native [EMAIL PROTECTED] [exec] ..\fontlib.dll : fatal error LNK1120: 1 unresolved externals [exec] NMAKE : fatal error U1077: 'link' : return code '0x460' [exec] Stop. Any ideas? Thanks, Vladimir. On 7/19/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Nathan Beyer wrote: -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Paulex Yang wrote: I think Richard's patch is fine, i.e., specify a locale to the test, what we want to test is toPattern()'s logic, not the locale data or something, and the specified locale is OK to test the logic. And I also think maybe one locale is not enough, so we may want to include some more exceptional locale, say, en_UK in this case, by which, we can try to follow RI as possible. Loose the test by removing the assertion here is dangerous, just like any other cases without clear spec. I think what this proved to us is that our testing matrix must include WinXP en_US, en_UK, en_RU etc. Locale-sensitive testing is pragmatically only necessary on a small subset of Harmony's modules (for example, text); this could be isolated to the build scripts of those modules. A trivial implementation would be to setup a list of locales to test, iterate the modules suite of tests for each locale and set the default locale respective to the iteration. Sure, although I don't know how to flip locale programmatically from ant in windows :) I do know how to ask Tim, Stephan, Paulex and myself to run the same tests :) geir -Nathan IOW, we want to run our test suite on as many locale's as possible, and have it pass on every one of them. We may choose local-specific tests, btw, which is what I think you are suggesting. geir Geir Magnusson Jr wrote: What do you suggest then? Paulex Yang wrote: Geir Magnusson Jr wrote: Then I guess we just fix the test. Agree, just think we should not fix the test by removing the assertion. geir Paulex Yang wrote: Tim Ellison wrote: Geir Magnusson Jr wrote: Now, on my windows box I got a clean build, no failures hm. The test works on en_US locale and fails on en_UK. I'm guessing that your machine is set up as en_US. Richard offered a patch that sets the locale to en_US for all MessageFormatTest-s, but I suggested that was not a suitable solution. For now I suggest we remove the assertion, since it is beyond the spec requirements for this type. Tim, Should we also consider the principle of follow the RI here? I think it is a sample of unclear spec, and we should assert if our implementation follows RI, i.e., the assert about return value of toPattern() is necessary. The issue here is just that the testcase assumes the return value is locale-independent, so I think Richard's patch is OK. Further, from the test perspective, maybe(just maybe) test case on only one locale is not enough to check Harmony's toPattern() logic, tests on more different locale(especially the 'exceptional' case like en_UK) are better. Also FYI, I tried the original test case with RI on en_UK locale, and it failed exactly as Harmony. Regards, Tim Geir Magnusson Jr wrote: This is nuts. We need to chase down the commit that broke this, and reverse it. We can't have a broken build persisting this long. geir Tim Ellison wrote: (1) Linux build/tests are passing again, but for some reason the 'BUILD SUCCESSFUL' note didn't go to the commit list? (2) Windows build/test is still failing with: Wrong full date pattern expected:...full... but was:...long... junit.framework.ComparisonFailure: Wrong full date pattern expected:...full... but was:...long... at org.apache.harmony.text.tests.java.text.MessageFormatTest.test_applyPatter nLjava_lang_String(MessageFormatTest.java:244) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) Regards, Tim - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- --- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: harmony-dev- [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail
[build] status
(1) Linux build/tests are passing again, but for some reason the 'BUILD SUCCESSFUL' note didn't go to the commit list? (2) Windows build/test is still failing with: Wrong full date pattern expected:...full... but was:...long... junit.framework.ComparisonFailure: Wrong full date pattern expected:...full... but was:...long... at org.apache.harmony.text.tests.java.text.MessageFormatTest.test_applyPatternLjava_lang_String(MessageFormatTest.java:244) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build] status
On 18 July 2006 at 9:21, Tim Ellison [EMAIL PROTECTED] wrote: (1) Linux build/tests are passing again, but for some reason the 'BUILD SUCCESSFUL' note didn't go to the commit list? Size problems again I think. (Some of the awt natives are built by default now - since they don't rely on the additional dependencies - and the default build flags for native code cause a lot of warnings.) Doubling the current size limit would allow even the largest of recent logs messages to get through to the list. Geir, Can you give my hindessm (at) apache.org address permission to post to the commit list so I can try to test a better fix? (I'm think that a mail filter that saves the log to my people.apache.org/~hindessm/ web space, fixes the url, and post just ~100 lines of the log to the list might be a reasonable workaround.) Regards, Mark. (2) Windows build/test is still failing with: Wrong full date pattern expected:...full... but was:...long... junit.framework.ComparisonFailure: Wrong full date pattern expected:...full... but was:...long... at org.apache.harmony.text.tests.java.text.MessageFormatTest.test_applyPatternLj ava_lang_String(MessageFormatTest.java:244) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build] status
Hello Tim, I'm looking at this issue :-) Tim Ellison wrote: (1) Linux build/tests are passing again, but for some reason the 'BUILD SUCCESSFUL' note didn't go to the commit list? (2) Windows build/test is still failing with: Wrong full date pattern expected:...full... but was:...long... junit.framework.ComparisonFailure: Wrong full date pattern expected:...full... but was:...long... at org.apache.harmony.text.tests.java.text.MessageFormatTest.test_applyPatternLjava_lang_String(MessageFormatTest.java:244) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) Regards, Tim -- Richard Liang China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build] status
Richard Liang wrote:
Hello Tim,
I'm looking at this issue :-)
Tim Ellison wrote:
(1) Linux build/tests are passing again, but for some reason the
'BUILD SUCCESSFUL' note didn't go to the commit list?
(2) Windows build/test is still failing with:
Wrong full date pattern expected:...full... but was:...long...
junit.framework.ComparisonFailure: Wrong full date pattern
expected:...full... but was:...long... at
org.apache.harmony.text.tests.java.text.MessageFormatTest.test_applyPatternLjava_lang_String(MessageFormatTest.java:244)
at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205)
Hello Tim,
This is another locale-dependent test case. I will provide a patch to
fix this issue.
Let me describe the test case details: ;-)
The failed test code is:
(Line1) MessageFormat format = new MessageFormat(test);
(Line2) format.applyPattern({0, date, full});
(Line3) assertTrue(Wrong full date format, format.getFormats()[0]
.equals(DateFormat.getDateInstance(DateFormat.FULL)));
(Line4) assertEquals(Wrong full date pattern,
{0,date,full}, format.toPattern());
Line1, Create an instance of MessageFormat
Line2, Set the pattern used by the format which will create a date
formatter with a FULL style pattern
Line3. assert the operation in Line2 is correct.
Line4. assert pattern of the format is equal to the previous one. This
line fails if the platform default locale is en_UK.
The reason is: In en_UK, a FULL style date formatter is the same as a
LONG style date formatter. So the return value of format.toPattern()
maybe {0,date,long}, and according to the spec of
MessageFormat.toPattern() ...The string is constructed from internal
information and therefore *does not necessarily equal* the previously
applied pattern. So I think it's a bug of the test case.
Best regards,
Richard
Regards,
Tim
--
Richard Liang
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build] status
Hello Tim,
I have raised Harmony-910[1] for this issue, patch is also available
:-) Would you please have a look at it. Thanks a lot.
[1]http://issues.apache.org/jira/browse/HARMONY-910
Best regards,
Richard
Richard Liang wrote:
Richard Liang wrote:
Hello Tim,
I'm looking at this issue :-)
Tim Ellison wrote:
(1) Linux build/tests are passing again, but for some reason the
'BUILD SUCCESSFUL' note didn't go to the commit list?
(2) Windows build/test is still failing with:
Wrong full date pattern expected:...full... but was:...long...
junit.framework.ComparisonFailure: Wrong full date pattern
expected:...full... but was:...long... at
org.apache.harmony.text.tests.java.text.MessageFormatTest.test_applyPatternLjava_lang_String(MessageFormatTest.java:244)
at
java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205)
Hello Tim,
This is another locale-dependent test case. I will provide a patch to
fix this issue.
Let me describe the test case details: ;-)
The failed test code is:
(Line1) MessageFormat format = new MessageFormat(test);
(Line2) format.applyPattern({0, date, full});
(Line3) assertTrue(Wrong full date format,
format.getFormats()[0]
.equals(DateFormat.getDateInstance(DateFormat.FULL)));
(Line4) assertEquals(Wrong full date pattern,
{0,date,full}, format.toPattern());
Line1, Create an instance of MessageFormat
Line2, Set the pattern used by the format which will create a date
formatter with a FULL style pattern
Line3. assert the operation in Line2 is correct.
Line4. assert pattern of the format is equal to the previous one.
This line fails if the platform default locale is en_UK.
The reason is: In en_UK, a FULL style date formatter is the same as a
LONG style date formatter. So the return value of format.toPattern()
maybe {0,date,long}, and according to the spec of
MessageFormat.toPattern() ...The string is constructed from internal
information and therefore *does not necessarily equal* the previously
applied pattern. So I think it's a bug of the test case.
Best regards,
Richard
Regards,
Tim
--
Richard Liang
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build] status
Richard Liang wrote:
Hello Tim,
I have raised Harmony-910[1] for this issue, patch is also available
:-) Would you please have a look at it. Thanks a lot.
I've had a look at it, but you don't appear to fix the problem described
below...
Richard Liang wrote:
snip
The reason is: In en_UK, a FULL style date formatter is the same as a
LONG style date formatter. So the return value of format.toPattern()
maybe {0,date,long}, and according to the spec of
MessageFormat.toPattern() ...The string is constructed from internal
information and therefore *does not necessarily equal* the previously
applied pattern. So I think it's a bug of the test case.
So shouldn't you be removing the assertion that they are equal? It
seems that the suggested patch is relying on a particular implementation
in a given locale, but it still is asserting more than required by the
specification.
Regards,
Tim
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build] status
Mark Hindess wrote: On 18 July 2006 at 9:21, Tim Ellison [EMAIL PROTECTED] wrote: (1) Linux build/tests are passing again, but for some reason the 'BUILD SUCCESSFUL' note didn't go to the commit list? Size problems again I think. (Some of the awt natives are built by default now - since they don't rely on the additional dependencies - and the default build flags for native code cause a lot of warnings.) Doubling the current size limit would allow even the largest of recent logs messages to get through to the list. And no one will ever need more than 640k! I thought last time was more than we'll ever need :) I've just tweaked the msg size up another 100k. Maybe the msg will slip through. Geir, Can you give my hindessm (at) apache.org address permission to post to the commit list so I can try to test a better fix? It's already there - I did that last time, I think, so you could experiment. (I'm think that a mail filter that saves the log to my people.apache.org/~hindessm/ web space, fixes the url, and post just ~100 lines of the log to the list might be a reasonable workaround.) I assume that the last 100 lines are dependably useful? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build] status
This is nuts. We need to chase down the commit that broke this, and reverse it. We can't have a broken build persisting this long. geir Tim Ellison wrote: (1) Linux build/tests are passing again, but for some reason the 'BUILD SUCCESSFUL' note didn't go to the commit list? (2) Windows build/test is still failing with: Wrong full date pattern expected:...full... but was:...long... junit.framework.ComparisonFailure: Wrong full date pattern expected:...full... but was:...long... at org.apache.harmony.text.tests.java.text.MessageFormatTest.test_applyPatternLjava_lang_String(MessageFormatTest.java:244) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) Regards, Tim - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build] status
Now, on my windows box I got a clean build, no failures hm. Geir Magnusson Jr wrote: This is nuts. We need to chase down the commit that broke this, and reverse it. We can't have a broken build persisting this long. geir Tim Ellison wrote: (1) Linux build/tests are passing again, but for some reason the 'BUILD SUCCESSFUL' note didn't go to the commit list? (2) Windows build/test is still failing with: Wrong full date pattern expected:...full... but was:...long... junit.framework.ComparisonFailure: Wrong full date pattern expected:...full... but was:...long... at org.apache.harmony.text.tests.java.text.MessageFormatTest.test_applyPatternLjava_lang_String(MessageFormatTest.java:244) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) Regards, Tim - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build] status
Geir Magnusson Jr wrote: This is nuts. We need to chase down the commit that broke this, and reverse it. We can't have a broken build persisting this long. It was this change that removed the test from the exclusion list: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/text/build.xml?view=diffr1=422500r2=422501pathrev=422501 Regards, Tim Tim Ellison wrote: (1) Linux build/tests are passing again, but for some reason the 'BUILD SUCCESSFUL' note didn't go to the commit list? (2) Windows build/test is still failing with: Wrong full date pattern expected:...full... but was:...long... junit.framework.ComparisonFailure: Wrong full date pattern expected:...full... but was:...long... at org.apache.harmony.text.tests.java.text.MessageFormatTest.test_applyPatternLjava_lang_String(MessageFormatTest.java:244) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) Regards, Tim - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build] status
Geir Magnusson Jr wrote: Now, on my windows box I got a clean build, no failures hm. The test works on en_US locale and fails on en_UK. I'm guessing that your machine is set up as en_US. Richard offered a patch that sets the locale to en_US for all MessageFormatTest-s, but I suggested that was not a suitable solution. For now I suggest we remove the assertion, since it is beyond the spec requirements for this type. Regards, Tim Geir Magnusson Jr wrote: This is nuts. We need to chase down the commit that broke this, and reverse it. We can't have a broken build persisting this long. geir Tim Ellison wrote: (1) Linux build/tests are passing again, but for some reason the 'BUILD SUCCESSFUL' note didn't go to the commit list? (2) Windows build/test is still failing with: Wrong full date pattern expected:...full... but was:...long... junit.framework.ComparisonFailure: Wrong full date pattern expected:...full... but was:...long... at org.apache.harmony.text.tests.java.text.MessageFormatTest.test_applyPatternLjava_lang_String(MessageFormatTest.java:244) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) Regards, Tim - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build] status
Ok - I reversed this, and the tests are passing. Tim Ellison wrote: Geir Magnusson Jr wrote: This is nuts. We need to chase down the commit that broke this, and reverse it. We can't have a broken build persisting this long. It was this change that removed the test from the exclusion list: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/text/build.xml?view=diffr1=422500r2=422501pathrev=422501 Regards, Tim Tim Ellison wrote: (1) Linux build/tests are passing again, but for some reason the 'BUILD SUCCESSFUL' note didn't go to the commit list? (2) Windows build/test is still failing with: Wrong full date pattern expected:...full... but was:...long... junit.framework.ComparisonFailure: Wrong full date pattern expected:...full... but was:...long... at org.apache.harmony.text.tests.java.text.MessageFormatTest.test_applyPatternLjava_lang_String(MessageFormatTest.java:244) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) Regards, Tim - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build] status
Tim Ellison wrote: Geir Magnusson Jr wrote: Now, on my windows box I got a clean build, no failures hm. The test works on en_US locale and fails on en_UK. I'm guessing that your machine is set up as en_US. I'll play with this, switching to en_UK. Richard offered a patch that sets the locale to en_US for all MessageFormatTest-s, but I suggested that was not a suitable solution. Agreed. For now I suggest we remove the assertion, since it is beyond the spec requirements for this type. I'll go take a look, and if concur, will fix and re-enable those tests. Regards, Tim Geir Magnusson Jr wrote: This is nuts. We need to chase down the commit that broke this, and reverse it. We can't have a broken build persisting this long. geir Tim Ellison wrote: (1) Linux build/tests are passing again, but for some reason the 'BUILD SUCCESSFUL' note didn't go to the commit list? (2) Windows build/test is still failing with: Wrong full date pattern expected:...full... but was:...long... junit.framework.ComparisonFailure: Wrong full date pattern expected:...full... but was:...long... at org.apache.harmony.text.tests.java.text.MessageFormatTest.test_applyPatternLjava_lang_String(MessageFormatTest.java:244) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) Regards, Tim - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build] status
Geir Magnusson Jr wrote: Ok - I reversed this, and the tests are passing. FYI I saw your update and forced a build -- normally it is scheduled on the hour as necessary. I only mention it in case you wonder about non-building later. I see the success message made it through too, bonus. Regards, Tim Tim Ellison wrote: Geir Magnusson Jr wrote: This is nuts. We need to chase down the commit that broke this, and reverse it. We can't have a broken build persisting this long. It was this change that removed the test from the exclusion list: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/text/build.xml?view=diffr1=422500r2=422501pathrev=422501 Regards, Tim Tim Ellison wrote: (1) Linux build/tests are passing again, but for some reason the 'BUILD SUCCESSFUL' note didn't go to the commit list? (2) Windows build/test is still failing with: Wrong full date pattern expected:...full... but was:...long... junit.framework.ComparisonFailure: Wrong full date pattern expected:...full... but was:...long... at org.apache.harmony.text.tests.java.text.MessageFormatTest.test_applyPatternLjava_lang_String(MessageFormatTest.java:244) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) Regards, Tim - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build] status
Geir Magnusson Jr wrote: Tim Ellison wrote: Geir Magnusson Jr wrote: Now, on my windows box I got a clean build, no failures hm. The test works on en_US locale and fails on en_UK. I'm guessing that your machine is set up as en_US. I'll play with this, switching to en_UK. Richard offered a patch that sets the locale to en_US for all MessageFormatTest-s, but I suggested that was not a suitable solution. Agreed. For now I suggest we remove the assertion, since it is beyond the spec requirements for this type. I'll go take a look, and if concur, will fix and re-enable those tests. ack -- take care with the failures that Alexei is reporting too on the TEXT tests in the Russian locale. Regards, Tim Geir Magnusson Jr wrote: This is nuts. We need to chase down the commit that broke this, and reverse it. We can't have a broken build persisting this long. geir Tim Ellison wrote: (1) Linux build/tests are passing again, but for some reason the 'BUILD SUCCESSFUL' note didn't go to the commit list? (2) Windows build/test is still failing with: Wrong full date pattern expected:...full... but was:...long... junit.framework.ComparisonFailure: Wrong full date pattern expected:...full... but was:...long... at org.apache.harmony.text.tests.java.text.MessageFormatTest.test_applyPatternLjava_lang_String(MessageFormatTest.java:244) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) Regards, Tim - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build] status
Tim Ellison wrote: Geir Magnusson Jr wrote: Ok - I reversed this, and the tests are passing. FYI I saw your update and forced a build -- normally it is scheduled on the hour as necessary. I only mention it in case you wonder about non-building later. I see the success message made it through too, bonus. A two-fer. Regards, Tim Tim Ellison wrote: Geir Magnusson Jr wrote: This is nuts. We need to chase down the commit that broke this, and reverse it. We can't have a broken build persisting this long. It was this change that removed the test from the exclusion list: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/text/build.xml?view=diffr1=422500r2=422501pathrev=422501 Regards, Tim Tim Ellison wrote: (1) Linux build/tests are passing again, but for some reason the 'BUILD SUCCESSFUL' note didn't go to the commit list? (2) Windows build/test is still failing with: Wrong full date pattern expected:...full... but was:...long... junit.framework.ComparisonFailure: Wrong full date pattern expected:...full... but was:...long... at org.apache.harmony.text.tests.java.text.MessageFormatTest.test_applyPatternLjava_lang_String(MessageFormatTest.java:244) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) Regards, Tim - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build] status
Tim Ellison wrote: Geir Magnusson Jr wrote: Tim Ellison wrote: Geir Magnusson Jr wrote: Now, on my windows box I got a clean build, no failures hm. The test works on en_US locale and fails on en_UK. I'm guessing that your machine is set up as en_US. I'll play with this, switching to en_UK. Richard offered a patch that sets the locale to en_US for all MessageFormatTest-s, but I suggested that was not a suitable solution. Agreed. For now I suggest we remove the assertion, since it is beyond the spec requirements for this type. I'll go take a look, and if concur, will fix and re-enable those tests. ack -- take care with the failures that Alexei is reporting too on the TEXT tests in the Russian locale. Oh, goody. A world tour via locale in winXP.. geir Regards, Tim Geir Magnusson Jr wrote: This is nuts. We need to chase down the commit that broke this, and reverse it. We can't have a broken build persisting this long. geir Tim Ellison wrote: (1) Linux build/tests are passing again, but for some reason the 'BUILD SUCCESSFUL' note didn't go to the commit list? (2) Windows build/test is still failing with: Wrong full date pattern expected:...full... but was:...long... junit.framework.ComparisonFailure: Wrong full date pattern expected:...full... but was:...long... at org.apache.harmony.text.tests.java.text.MessageFormatTest.test_applyPatternLjava_lang_String(MessageFormatTest.java:244) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) Regards, Tim - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build] status
Tim Ellison wrote: Geir Magnusson Jr wrote: Now, on my windows box I got a clean build, no failures hm. The test works on en_US locale and fails on en_UK. I'm guessing that your machine is set up as en_US. Richard offered a patch that sets the locale to en_US for all MessageFormatTest-s, but I suggested that was not a suitable solution. For now I suggest we remove the assertion, since it is beyond the spec requirements for this type. Tim, Should we also consider the principle of follow the RI here? I think it is a sample of unclear spec, and we should assert if our implementation follows RI, i.e., the assert about return value of toPattern() is necessary. The issue here is just that the testcase assumes the return value is locale-independent, so I think Richard's patch is OK. Further, from the test perspective, maybe(just maybe) test case on only one locale is not enough to check Harmony's toPattern() logic, tests on more different locale(especially the 'exceptional' case like en_UK) are better. Also FYI, I tried the original test case with RI on en_UK locale, and it failed exactly as Harmony. Regards, Tim Geir Magnusson Jr wrote: This is nuts. We need to chase down the commit that broke this, and reverse it. We can't have a broken build persisting this long. geir Tim Ellison wrote: (1) Linux build/tests are passing again, but for some reason the 'BUILD SUCCESSFUL' note didn't go to the commit list? (2) Windows build/test is still failing with: Wrong full date pattern expected:...full... but was:...long... junit.framework.ComparisonFailure: Wrong full date pattern expected:...full... but was:...long... at org.apache.harmony.text.tests.java.text.MessageFormatTest.test_applyPatternLjava_lang_String(MessageFormatTest.java:244) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) Regards, Tim - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build] status
Then I guess we just fix the test. geir Paulex Yang wrote: Tim Ellison wrote: Geir Magnusson Jr wrote: Now, on my windows box I got a clean build, no failures hm. The test works on en_US locale and fails on en_UK. I'm guessing that your machine is set up as en_US. Richard offered a patch that sets the locale to en_US for all MessageFormatTest-s, but I suggested that was not a suitable solution. For now I suggest we remove the assertion, since it is beyond the spec requirements for this type. Tim, Should we also consider the principle of follow the RI here? I think it is a sample of unclear spec, and we should assert if our implementation follows RI, i.e., the assert about return value of toPattern() is necessary. The issue here is just that the testcase assumes the return value is locale-independent, so I think Richard's patch is OK. Further, from the test perspective, maybe(just maybe) test case on only one locale is not enough to check Harmony's toPattern() logic, tests on more different locale(especially the 'exceptional' case like en_UK) are better. Also FYI, I tried the original test case with RI on en_UK locale, and it failed exactly as Harmony. Regards, Tim Geir Magnusson Jr wrote: This is nuts. We need to chase down the commit that broke this, and reverse it. We can't have a broken build persisting this long. geir Tim Ellison wrote: (1) Linux build/tests are passing again, but for some reason the 'BUILD SUCCESSFUL' note didn't go to the commit list? (2) Windows build/test is still failing with: Wrong full date pattern expected:...full... but was:...long... junit.framework.ComparisonFailure: Wrong full date pattern expected:...full... but was:...long... at org.apache.harmony.text.tests.java.text.MessageFormatTest.test_applyPatternLjava_lang_String(MessageFormatTest.java:244) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) Regards, Tim - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build] status
Geir Magnusson Jr wrote: Then I guess we just fix the test. Agree, just think we should not fix the test by removing the assertion. geir Paulex Yang wrote: Tim Ellison wrote: Geir Magnusson Jr wrote: Now, on my windows box I got a clean build, no failures hm. The test works on en_US locale and fails on en_UK. I'm guessing that your machine is set up as en_US. Richard offered a patch that sets the locale to en_US for all MessageFormatTest-s, but I suggested that was not a suitable solution. For now I suggest we remove the assertion, since it is beyond the spec requirements for this type. Tim, Should we also consider the principle of follow the RI here? I think it is a sample of unclear spec, and we should assert if our implementation follows RI, i.e., the assert about return value of toPattern() is necessary. The issue here is just that the testcase assumes the return value is locale-independent, so I think Richard's patch is OK. Further, from the test perspective, maybe(just maybe) test case on only one locale is not enough to check Harmony's toPattern() logic, tests on more different locale(especially the 'exceptional' case like en_UK) are better. Also FYI, I tried the original test case with RI on en_UK locale, and it failed exactly as Harmony. Regards, Tim Geir Magnusson Jr wrote: This is nuts. We need to chase down the commit that broke this, and reverse it. We can't have a broken build persisting this long. geir Tim Ellison wrote: (1) Linux build/tests are passing again, but for some reason the 'BUILD SUCCESSFUL' note didn't go to the commit list? (2) Windows build/test is still failing with: Wrong full date pattern expected:...full... but was:...long... junit.framework.ComparisonFailure: Wrong full date pattern expected:...full... but was:...long... at org.apache.harmony.text.tests.java.text.MessageFormatTest.test_applyPatternLjava_lang_String(MessageFormatTest.java:244) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) Regards, Tim - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build] status
Tim Ellison wrote:
Richard Liang wrote:
Hello Tim,
I have raised Harmony-910[1] for this issue, patch is also available
:-) Would you please have a look at it. Thanks a lot.
I've had a look at it, but you don't appear to fix the problem described
below...
Ah., Let me explain it below. ;-)
Richard Liang wrote:
snip
The reason is: In en_UK, a FULL style date formatter is the same as a
LONG style date formatter. So the return value of format.toPattern()
maybe {0,date,long}, and according to the spec of
MessageFormat.toPattern() ...The string is constructed from internal
information and therefore *does not necessarily equal* the previously
applied pattern. So I think it's a bug of the test case.
So shouldn't you be removing the assertion that they are equal? It
seems that the suggested patch is relying on a particular implementation
in a given locale, but it still is asserting more than required by the
specification.
Although the spec does not require the round-trip of applyPattern and
toPattern, we still want to get one *certain* pattern through toPattern.
Now the problem is the returned pattern is locale-dependent. I'm
uncertain about the reason to remove the assertion:
1) Because the behavior is not required by spec, or
2) Because the behavior is locale-dependent
Thanks a lot.
Best regards,
Richard
Regards,
Tim
--
Richard Liang
China Software Development Lab, IBM
Re: [build] status
What do you suggest then? Paulex Yang wrote: Geir Magnusson Jr wrote: Then I guess we just fix the test. Agree, just think we should not fix the test by removing the assertion. geir Paulex Yang wrote: Tim Ellison wrote: Geir Magnusson Jr wrote: Now, on my windows box I got a clean build, no failures hm. The test works on en_US locale and fails on en_UK. I'm guessing that your machine is set up as en_US. Richard offered a patch that sets the locale to en_US for all MessageFormatTest-s, but I suggested that was not a suitable solution. For now I suggest we remove the assertion, since it is beyond the spec requirements for this type. Tim, Should we also consider the principle of follow the RI here? I think it is a sample of unclear spec, and we should assert if our implementation follows RI, i.e., the assert about return value of toPattern() is necessary. The issue here is just that the testcase assumes the return value is locale-independent, so I think Richard's patch is OK. Further, from the test perspective, maybe(just maybe) test case on only one locale is not enough to check Harmony's toPattern() logic, tests on more different locale(especially the 'exceptional' case like en_UK) are better. Also FYI, I tried the original test case with RI on en_UK locale, and it failed exactly as Harmony. Regards, Tim Geir Magnusson Jr wrote: This is nuts. We need to chase down the commit that broke this, and reverse it. We can't have a broken build persisting this long. geir Tim Ellison wrote: (1) Linux build/tests are passing again, but for some reason the 'BUILD SUCCESSFUL' note didn't go to the commit list? (2) Windows build/test is still failing with: Wrong full date pattern expected:...full... but was:...long... junit.framework.ComparisonFailure: Wrong full date pattern expected:...full... but was:...long... at org.apache.harmony.text.tests.java.text.MessageFormatTest.test_applyPatternLjava_lang_String(MessageFormatTest.java:244) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) Regards, Tim - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build] status
I think Richard's patch is fine, i.e., specify a locale to the test, what we want to test is toPattern()'s logic, not the locale data or something, and the specified locale is OK to test the logic. And I also think maybe one locale is not enough, so we may want to include some more exceptional locale, say, en_UK in this case, by which, we can try to follow RI as possible. Loose the test by removing the assertion here is dangerous, just like any other cases without clear spec. Geir Magnusson Jr wrote: What do you suggest then? Paulex Yang wrote: Geir Magnusson Jr wrote: Then I guess we just fix the test. Agree, just think we should not fix the test by removing the assertion. geir Paulex Yang wrote: Tim Ellison wrote: Geir Magnusson Jr wrote: Now, on my windows box I got a clean build, no failures hm. The test works on en_US locale and fails on en_UK. I'm guessing that your machine is set up as en_US. Richard offered a patch that sets the locale to en_US for all MessageFormatTest-s, but I suggested that was not a suitable solution. For now I suggest we remove the assertion, since it is beyond the spec requirements for this type. Tim, Should we also consider the principle of follow the RI here? I think it is a sample of unclear spec, and we should assert if our implementation follows RI, i.e., the assert about return value of toPattern() is necessary. The issue here is just that the testcase assumes the return value is locale-independent, so I think Richard's patch is OK. Further, from the test perspective, maybe(just maybe) test case on only one locale is not enough to check Harmony's toPattern() logic, tests on more different locale(especially the 'exceptional' case like en_UK) are better. Also FYI, I tried the original test case with RI on en_UK locale, and it failed exactly as Harmony. Regards, Tim Geir Magnusson Jr wrote: This is nuts. We need to chase down the commit that broke this, and reverse it. We can't have a broken build persisting this long. geir Tim Ellison wrote: (1) Linux build/tests are passing again, but for some reason the 'BUILD SUCCESSFUL' note didn't go to the commit list? (2) Windows build/test is still failing with: Wrong full date pattern expected:...full... but was:...long... junit.framework.ComparisonFailure: Wrong full date pattern expected:...full... but was:...long... at org.apache.harmony.text.tests.java.text.MessageFormatTest.test_applyPatternLjava_lang_String(MessageFormatTest.java:244) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) Regards, Tim - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build] status
Paulex Yang wrote: I think Richard's patch is fine, i.e., specify a locale to the test, what we want to test is toPattern()'s logic, not the locale data or something, and the specified locale is OK to test the logic. And I also think maybe one locale is not enough, so we may want to include some more exceptional locale, say, en_UK in this case, by which, we can try to follow RI as possible. Loose the test by removing the assertion here is dangerous, just like any other cases without clear spec. I think what this proved to us is that our testing matrix must include WinXP en_US, en_UK, en_RU etc. IOW, we want to run our test suite on as many locale's as possible, and have it pass on every one of them. We may choose local-specific tests, btw, which is what I think you are suggesting. geir Geir Magnusson Jr wrote: What do you suggest then? Paulex Yang wrote: Geir Magnusson Jr wrote: Then I guess we just fix the test. Agree, just think we should not fix the test by removing the assertion. geir Paulex Yang wrote: Tim Ellison wrote: Geir Magnusson Jr wrote: Now, on my windows box I got a clean build, no failures hm. The test works on en_US locale and fails on en_UK. I'm guessing that your machine is set up as en_US. Richard offered a patch that sets the locale to en_US for all MessageFormatTest-s, but I suggested that was not a suitable solution. For now I suggest we remove the assertion, since it is beyond the spec requirements for this type. Tim, Should we also consider the principle of follow the RI here? I think it is a sample of unclear spec, and we should assert if our implementation follows RI, i.e., the assert about return value of toPattern() is necessary. The issue here is just that the testcase assumes the return value is locale-independent, so I think Richard's patch is OK. Further, from the test perspective, maybe(just maybe) test case on only one locale is not enough to check Harmony's toPattern() logic, tests on more different locale(especially the 'exceptional' case like en_UK) are better. Also FYI, I tried the original test case with RI on en_UK locale, and it failed exactly as Harmony. Regards, Tim Geir Magnusson Jr wrote: This is nuts. We need to chase down the commit that broke this, and reverse it. We can't have a broken build persisting this long. geir Tim Ellison wrote: (1) Linux build/tests are passing again, but for some reason the 'BUILD SUCCESSFUL' note didn't go to the commit list? (2) Windows build/test is still failing with: Wrong full date pattern expected:...full... but was:...long... junit.framework.ComparisonFailure: Wrong full date pattern expected:...full... but was:...long... at org.apache.harmony.text.tests.java.text.MessageFormatTest.test_applyPatternLjava_lang_String(MessageFormatTest.java:244) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) Regards, Tim - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [build] status
-Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Paulex Yang wrote: I think Richard's patch is fine, i.e., specify a locale to the test, what we want to test is toPattern()'s logic, not the locale data or something, and the specified locale is OK to test the logic. And I also think maybe one locale is not enough, so we may want to include some more exceptional locale, say, en_UK in this case, by which, we can try to follow RI as possible. Loose the test by removing the assertion here is dangerous, just like any other cases without clear spec. I think what this proved to us is that our testing matrix must include WinXP en_US, en_UK, en_RU etc. Locale-sensitive testing is pragmatically only necessary on a small subset of Harmony's modules (for example, text); this could be isolated to the build scripts of those modules. A trivial implementation would be to setup a list of locales to test, iterate the modules suite of tests for each locale and set the default locale respective to the iteration. -Nathan IOW, we want to run our test suite on as many locale's as possible, and have it pass on every one of them. We may choose local-specific tests, btw, which is what I think you are suggesting. geir Geir Magnusson Jr wrote: What do you suggest then? Paulex Yang wrote: Geir Magnusson Jr wrote: Then I guess we just fix the test. Agree, just think we should not fix the test by removing the assertion. geir Paulex Yang wrote: Tim Ellison wrote: Geir Magnusson Jr wrote: Now, on my windows box I got a clean build, no failures hm. The test works on en_US locale and fails on en_UK. I'm guessing that your machine is set up as en_US. Richard offered a patch that sets the locale to en_US for all MessageFormatTest-s, but I suggested that was not a suitable solution. For now I suggest we remove the assertion, since it is beyond the spec requirements for this type. Tim, Should we also consider the principle of follow the RI here? I think it is a sample of unclear spec, and we should assert if our implementation follows RI, i.e., the assert about return value of toPattern() is necessary. The issue here is just that the testcase assumes the return value is locale-independent, so I think Richard's patch is OK. Further, from the test perspective, maybe(just maybe) test case on only one locale is not enough to check Harmony's toPattern() logic, tests on more different locale(especially the 'exceptional' case like en_UK) are better. Also FYI, I tried the original test case with RI on en_UK locale, and it failed exactly as Harmony. Regards, Tim Geir Magnusson Jr wrote: This is nuts. We need to chase down the commit that broke this, and reverse it. We can't have a broken build persisting this long. geir Tim Ellison wrote: (1) Linux build/tests are passing again, but for some reason the 'BUILD SUCCESSFUL' note didn't go to the commit list? (2) Windows build/test is still failing with: Wrong full date pattern expected:...full... but was:...long... junit.framework.ComparisonFailure: Wrong full date pattern expected:...full... but was:...long... at org.apache.harmony.text.tests.java.text.MessageFormatTest.test_applyPatter nLjava_lang_String(MessageFormatTest.java:244) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) Regards, Tim - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- --- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: harmony-dev- [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
Re: [build] status
Nathan Beyer wrote: -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Paulex Yang wrote: I think Richard's patch is fine, i.e., specify a locale to the test, what we want to test is toPattern()'s logic, not the locale data or something, and the specified locale is OK to test the logic. And I also think maybe one locale is not enough, so we may want to include some more exceptional locale, say, en_UK in this case, by which, we can try to follow RI as possible. Loose the test by removing the assertion here is dangerous, just like any other cases without clear spec. I think what this proved to us is that our testing matrix must include WinXP en_US, en_UK, en_RU etc. Locale-sensitive testing is pragmatically only necessary on a small subset of Harmony's modules (for example, text); this could be isolated to the build scripts of those modules. A trivial implementation would be to setup a list of locales to test, iterate the modules suite of tests for each locale and set the default locale respective to the iteration. Sure, although I don't know how to flip locale programmatically from ant in windows :) I do know how to ask Tim, Stephan, Paulex and myself to run the same tests :) geir -Nathan IOW, we want to run our test suite on as many locale's as possible, and have it pass on every one of them. We may choose local-specific tests, btw, which is what I think you are suggesting. geir Geir Magnusson Jr wrote: What do you suggest then? Paulex Yang wrote: Geir Magnusson Jr wrote: Then I guess we just fix the test. Agree, just think we should not fix the test by removing the assertion. geir Paulex Yang wrote: Tim Ellison wrote: Geir Magnusson Jr wrote: Now, on my windows box I got a clean build, no failures hm. The test works on en_US locale and fails on en_UK. I'm guessing that your machine is set up as en_US. Richard offered a patch that sets the locale to en_US for all MessageFormatTest-s, but I suggested that was not a suitable solution. For now I suggest we remove the assertion, since it is beyond the spec requirements for this type. Tim, Should we also consider the principle of follow the RI here? I think it is a sample of unclear spec, and we should assert if our implementation follows RI, i.e., the assert about return value of toPattern() is necessary. The issue here is just that the testcase assumes the return value is locale-independent, so I think Richard's patch is OK. Further, from the test perspective, maybe(just maybe) test case on only one locale is not enough to check Harmony's toPattern() logic, tests on more different locale(especially the 'exceptional' case like en_UK) are better. Also FYI, I tried the original test case with RI on en_UK locale, and it failed exactly as Harmony. Regards, Tim Geir Magnusson Jr wrote: This is nuts. We need to chase down the commit that broke this, and reverse it. We can't have a broken build persisting this long. geir Tim Ellison wrote: (1) Linux build/tests are passing again, but for some reason the 'BUILD SUCCESSFUL' note didn't go to the commit list? (2) Windows build/test is still failing with: Wrong full date pattern expected:...full... but was:...long... junit.framework.ComparisonFailure: Wrong full date pattern expected:...full... but was:...long... at org.apache.harmony.text.tests.java.text.MessageFormatTest.test_applyPatter nLjava_lang_String(MessageFormatTest.java:244) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) Regards, Tim - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- --- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: harmony-dev- [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To
[admin] Build status messages
Can one of the list admins for the -commits list check to see why the new build (and test) status messages are not getting through to the list? The From address will be: Apache Harmony Build [EMAIL PROTECTED] and the subjects will be one of: Subject: [continuum] BUILD FAILURE: Classlib/win.ia32 Build/Test Subject: [continuum] BUILD SUCCESSFUL: Classlib/win.ia32 Build/Test Subject: [continuum] BUILD FAILURE: Classlib/linux.ia32 Build/Test Subject: [continuum] BUILD SUCCESSFUL: Classlib/linux.ia32 Build/Test If it helps, the last messages would have been around the same time as the test notifications that go to my gmail account. The most recent of these were atTue, 25 Apr 06 08:21:15 +0100 and Tue, 25 Apr 06 09:20:48 +0100. (Nothing serious just the unstable test failing and then passing.) Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [admin] Build status messages
I got [continuum] BUILD ERROR: Classlib/win.ia32 Build/Test about 38 mins ago w/ Message-ID : [EMAIL PROTECTED] Mark Hindess wrote: Can one of the list admins for the -commits list check to see why the new build (and test) status messages are not getting through to the list? The From address will be: Apache Harmony Build [EMAIL PROTECTED] and the subjects will be one of: Subject: [continuum] BUILD FAILURE: Classlib/win.ia32 Build/Test Subject: [continuum] BUILD SUCCESSFUL: Classlib/win.ia32 Build/Test Subject: [continuum] BUILD FAILURE: Classlib/linux.ia32 Build/Test Subject: [continuum] BUILD SUCCESSFUL: Classlib/linux.ia32 Build/Test If it helps, the last messages would have been around the same time as the test notifications that go to my gmail account. The most recent of these were atTue, 25 Apr 06 08:21:15 +0100 and Tue, 25 Apr 06 09:20:48 +0100. (Nothing serious just the unstable test failing and then passing.) Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [admin] Build status messages
Seems that SVN was unreachable from here for a while. I see it is building now so fingers-crossed for a BUILD SUCCESSFUL message any time soon. Regards, Tim Geir Magnusson Jr wrote: I got [continuum] BUILD ERROR: Classlib/win.ia32 Build/Test about 38 mins ago w/ Message-ID : [EMAIL PROTECTED] Mark Hindess wrote: Can one of the list admins for the -commits list check to see why the new build (and test) status messages are not getting through to the list? The From address will be: Apache Harmony Build [EMAIL PROTECTED] and the subjects will be one of: Subject: [continuum] BUILD FAILURE: Classlib/win.ia32 Build/Test Subject: [continuum] BUILD SUCCESSFUL: Classlib/win.ia32 Build/Test Subject: [continuum] BUILD FAILURE: Classlib/linux.ia32 Build/Test Subject: [continuum] BUILD SUCCESSFUL: Classlib/linux.ia32 Build/Test If it helps, the last messages would have been around the same time as the test notifications that go to my gmail account. The most recent of these were atTue, 25 Apr 06 08:21:15 +0100 and Tue, 25 Apr 06 09:20:48 +0100. (Nothing serious just the unstable test failing and then passing.) Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [admin] Build status messages
From my nag system messages, there was a problem in infra, but things look like they are back together. geir -- Geir Magnusson Jr SSG/MPD [EMAIL PROTECTED] +1 203 665 6437 -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 25, 2006 11:09 AM To: harmony-dev@incubator.apache.org Subject: Re: [admin] Build status messages Seems that SVN was unreachable from here for a while. I see it is building now so fingers-crossed for a BUILD SUCCESSFUL message any time soon. Regards, Tim Geir Magnusson Jr wrote: I got [continuum] BUILD ERROR: Classlib/win.ia32 Build/Test about 38 mins ago w/ Message-ID : [EMAIL PROTECTED] Mark Hindess wrote: Can one of the list admins for the -commits list check to see why the new build (and test) status messages are not getting through to the list? The From address will be: Apache Harmony Build [EMAIL PROTECTED] and the subjects will be one of: Subject: [continuum] BUILD FAILURE: Classlib/win.ia32 Build/Test Subject: [continuum] BUILD SUCCESSFUL: Classlib/win.ia32 Build/Test Subject: [continuum] BUILD FAILURE: Classlib/linux.ia32 Build/Test Subject: [continuum] BUILD SUCCESSFUL: Classlib/linux.ia32 Build/Test If it helps, the last messages would have been around the same time as the test notifications that go to my gmail account. The most recent of these were atTue, 25 Apr 06 08:21:15 +0100 and Tue, 25 Apr 06 09:20:48 +0100. (Nothing serious just the unstable test failing and then passing.) Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [admin] Build status messages
So note that there may be delay in recovery - gettting the mail that queued up back out... geir -- Geir Magnusson Jr SSG/MPD [EMAIL PROTECTED] +1 203 665 6437 -Original Message- From: Magnusson, Geir [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 25, 2006 11:13 AM To: harmony-dev@incubator.apache.org Subject: RE: [admin] Build status messages From my nag system messages, there was a problem in infra, but things look like they are back together. geir -- Geir Magnusson Jr SSG/MPD [EMAIL PROTECTED] +1 203 665 6437 -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 25, 2006 11:09 AM To: harmony-dev@incubator.apache.org Subject: Re: [admin] Build status messages Seems that SVN was unreachable from here for a while. I see it is building now so fingers-crossed for a BUILD SUCCESSFUL message any time soon. Regards, Tim Geir Magnusson Jr wrote: I got [continuum] BUILD ERROR: Classlib/win.ia32 Build/Test about 38 mins ago w/ Message-ID : [EMAIL PROTECTED] Mark Hindess wrote: Can one of the list admins for the -commits list check to see why the new build (and test) status messages are not getting through to the list? The From address will be: Apache Harmony Build [EMAIL PROTECTED] and the subjects will be one of: Subject: [continuum] BUILD FAILURE: Classlib/win.ia32 Build/Test Subject: [continuum] BUILD SUCCESSFUL: Classlib/win.ia32 Build/Test Subject: [continuum] BUILD FAILURE: Classlib/linux.ia32 Build/Test Subject: [continuum] BUILD SUCCESSFUL: Classlib/linux.ia32 Build/Test If it helps, the last messages would have been around the same time as the test notifications that go to my gmail account. The most recent of these were atTue, 25 Apr 06 08:21:15 +0100 and Tue, 25 Apr 06 09:20:48 +0100. (Nothing serious just the unstable test failing and then passing.) Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Update on build status
Hi Mark, On 3/16/06, Mark Hindess wrote: Our local builds now complete a two stage build. First with a certified JDK and then with the eclipse compiler running on the VME and deploy directory from the first stage build. They then run the tests. I'm also generating some reports as part of the build. The JAPI reports currently show: JDKGood Bad Missing Abs-add jdk14 17.56% 0.01% 82.42%0% jdk15 15.37% 0.52% 84.09%- I'm also reporting against some manually created class lists [1] for running a number of applications. These are currently reporting: Application JRE Classes % Found/Total derby 99.64 277/278 tomcat 93.22 330/354 continuum 92.94 408/439 axis90.93 361/397 geronimo-jetty 81.68 495/606 I'll put the missing classes lists on the wiki shortly (under http://wiki.apache.org/harmony/ClassLibrary). I found that some classes from javax.crypto (for example, SecretKey) in the list of required classes for continuum and geronimo. I verified that they are present in the repository. What is wrong with them? Thanks, Stepan. Geir, these builds are relatively stable now so I'd be happy to consider what can be done to get them running on Apache infrastructure? Regards, Mark. -- Mark Hindess [EMAIL PROTECTED] IBM Java Technology Centre, UK. -- Thanks, Stepan Mishura Intel Middleware Products Division
Re: Update on build status
Stepan Mishura wrote: I found that some classes from javax.crypto (for example, SecretKey) in the list of required classes for continuum and geronimo. I verified that they are present in the repository. What is wrong with them? They are being built into crypto.jar in the SECURITY module build script, but not in the bootstrap build (in make/build-java.xml). I'll hack it now -- but the crypto code should be moved into its own module. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: Update on build status
Stefano Mazzocchi wrote: Mark Hindess wrote: Our local builds now complete a two stage build. First with a certified JDK and then with the eclipse compiler running on the VME and deploy directory from the first stage build. They then run the tests. I'm also generating some reports as part of the build. The JAPI reports currently show: JDKGood Bad Missing Abs-add jdk14 17.56% 0.01% 82.42%0% jdk15 15.37% 0.52% 84.09%- I'm also reporting against some manually created class lists [1] for running a number of applications. These are currently reporting: Application JRE Classes % Found/Total derby 99.64 277/278 tomcat 93.22 330/354 continuum 92.94 408/439 axis90.93 361/397 geronimo-jetty 81.68 495/606 I'll put the missing classes lists on the wiki shortly (under http://wiki.apache.org/harmony/ClassLibrary). Geir, these builds are relatively stable now so I'd be happy to consider what can be done to get them running on Apache infrastructure? We could, in theory, ask infra@ to give us a solaris zone, but I'm not sure this is kosher since we are under incubation, I guess the incubator PMC would have to be responsible for that. I've already asked, and there was no objection. The problem we have is that the J9 VM doesn't run on Solaris, unless Solaris has a good linux emulation/support mode. If that's the case, we're golden. If not, I would suggest we ask the Gump PMC (of which leo, sam and I are part of) and maybe we can run that on vmgump.apache.org thoughts? The latter would work... geir
Re: Update on build status
Mark Hindess wrote: Our local builds now complete a two stage build. First with a certified JDK and then with the eclipse compiler running on the VME and deploy directory from the first stage build. They then run the tests. I'm also generating some reports as part of the build. The JAPI reports currently show: JDKGood Bad Missing Abs-add jdk14 17.56% 0.01% 82.42%0% jdk15 15.37% 0.52% 84.09%- I'm also reporting against some manually created class lists [1] for running a number of applications. These are currently reporting: Application JRE Classes % Found/Total derby 99.64 277/278 tomcat 93.22 330/354 continuum 92.94 408/439 axis90.93 361/397 geronimo-jetty 81.68 495/606 I'll put the missing classes lists on the wiki shortly (under http://wiki.apache.org/harmony/ClassLibrary). Geir, these builds are relatively stable now so I'd be happy to consider what can be done to get them running on Apache infrastructure? We could, in theory, ask infra@ to give us a solaris zone, but I'm not sure this is kosher since we are under incubation, I guess the incubator PMC would have to be responsible for that. If not, I would suggest we ask the Gump PMC (of which leo, sam and I are part of) and maybe we can run that on vmgump.apache.org thoughts? -- Stefano.
Re: Update on build status
Mark Hindess mark.hindess at googlemail.com writes: Our local builds now complete a two stage build. First with a certified JDK and then with the eclipse compiler running on the VME and deploy directory from the first stage build. They then run the tests. This seems a good point to jump in and say that I'm now generating nightly Japi reports based on the latest CVS too. I'm also producing nightly diff emails (whenever something changes) that are being sent in the general direction of this list, but presumably being refused because the address they're being sent from ([EMAIL PROTECTED]) isn't a subscriber (in fact, I don't even receive mail there so I couldn't subscribe it if I wanted to). If someone could unblock it, that'd be great. Sometimes the results change as a result of bugfixes in Japi itself (I'm looking into two suspicious lines in the Classpath output right now that might need Japi changes), but for the most part you'll only get emails based on changes to Harmony. Thanks, Stuart.
Re: classlib build status emails?
So I (ahem) 'tested' the build machine by checking in some code that would not compile, at 16:23 GMT today -- but no complaint sent on the dev list? Regards, Tim Mark Hindess wrote: On 21/02/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Mark Hindess wrote: On 21/02/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Mark Hindess wrote: Hi, Is there any interest in having build status emails sent to this list? I'm building classlib trunk with continuum and it would be simple for me to have messages like the following sent to the list whenever the status of our builds change. Currently I'm building only on linux but I plan to get windows builds running in the next few days. Cool. Please, only send changes (pass-fail, fail-pass). Agreed. Done. (Will the non-subscriber [EMAIL PROTECTED] be able to send to the list or is there something that needs to be done to avoid moderation/spam filtering?) We can certainly add that.. Thanks. Currently the builds are running the default target in make/build.xml but if there was a top-level build-and-test target then I could run that instead. This might produce more useful results. Ah. Can you do a sequence : $ cd make $ ant $ cd .. $ ant -f build-test.xml The current build is just a direct svn co and ant project at present. My next step is to use a local repository with svn:externals pulling in the harmony trunk so I'll have more flexibility. However, I suspect more people might run the test target if this process was simplified. Of course, as Tim mentioned it's not trivial because of the requirement for a VM and other dependencies so perhaps it is not worth it. I think it is. It's great that you have a private version of this running now for us, but we want to get to a point where a) anyone can do it b) The one that we reun for the project is running here on apache infrastructure I agree. I'd be happy to run it on apache infrastructure. I'd be happy to move development of the build-test-publish wrapper to apache infrastructure but that might slow things down a little. I'm going to concentrate on testing first - since the test results are probably more important than the actual build artifacts at this point - but wrapping the build should also allow me to add a publish step to our parent build if there was somewhere I could publish to? Lets get that working - we can then run it here and have it publish locally to the infrastructure... Agreed. Nothing we are doing here is really private except in that it is currently running on a private server. That's really a matter of getting results while avoiding the logistical issues - hardware, access, compiler licenses, etc - of running it on apache infrastructure. When it is working we can resolve those issues. Until it is working there isn't really much incentive. Regards, Mark. -- Forwarded message -- From: Apache Harmony Build [EMAIL PROTECTED] Date: 20-Feb-0006 11:04 Subject: [continuum] BUILD SUCCESSFUL: Classlib/linux.ia32 To: [EMAIL PROTECTED] Online report : http://ibmonly.hursley.ibm.com/continuum/linux.ia32/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/1/buildId/44 Build statistics: State: Ok Previous State: Failed Started at: Mon, 20 Feb 2006 11:03:46 + Finished at: Mon, 20 Feb 2006 11:04:56 + Total time: 1m 9s Build Trigger: Forced Exit code: 0 Building machine hostname: hy2 Operating system : Linux Java version : 1.4.2(IBM Corporation) Changes No files changed Output: [snip] -- Mark Hindess [EMAIL PROTECTED] IBM Java Technology Centre, UK. -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: classlib build status emails?
On 27/02/06, Tim Ellison [EMAIL PROTECTED] wrote: So I (ahem) 'tested' the build machine by checking in some code that would not compile, at 16:23 GMT today -- but no complaint sent on the dev list? Thanks Tim. It's about time someone tested it! ;-) The mail logs show the message leaving the build machine and being delivered to the smarthost that should have delivered it. I've just sent a test message from the build machine and that reach an external host without a problem so I guess the build messages must be getting spam filtered or moderated? I wonder if someone can check the logs for the list host for message from [EMAIL PROTECTED] ? Regards, Mark. -- Mark Hindess [EMAIL PROTECTED] IBM Java Technology Centre, UK.
Re: classlib build status emails?
Yup, got to echo Tims words - very cool :) It's great for us to be able to see how near/far we are from a full J2SE implementation, and provides a simple way for people to find areas that need work. Thanks! Stuart Ballard wrote: Stuart Ballard stuart.a.ballard at gmail.com writes: If you can give me an url that will always point to the latest jar file(s), I can set up nightly japi results and mail diffs to this list. Geir gave me a pointer to the latest snapshots, so the japi results are now online: http://www.kaffe.org/~stuart/japi/htmlout/h-jdk10-harmony http://www.kaffe.org/~stuart/japi/htmlout/h-jdk11-harmony http://www.kaffe.org/~stuart/japi/htmlout/h-jdk12-harmony http://www.kaffe.org/~stuart/japi/htmlout/h-jdk13-harmony http://www.kaffe.org/~stuart/japi/htmlout/h-jdk14-harmony http://www.kaffe.org/~stuart/japi/htmlout/h-jdk15-harmony http://www.kaffe.org/~stuart/japi/htmlout/h-harmony-jdk15 The last report triggers a recently-discovered bug in japitools that causes some StringBuffer methods to be incorrectly reported as missing in jdk15 (which would mean that they are extra methods in harmony). I suggest ignoring the last report for now, or at least verifying anything it claims against Sun's documentation before acting on it. Other than that the reports should give correct information about Harmony's coverage of the API defined in each JDK version. Whenever these results change for better or worse, (unless I've screwed something up), an email will be sent to this list with the differences. Stuart. -- Oliver Deakin IBM United Kingdom Limited
Re: classlib build status emails?
Mark Hindess wrote: On 21/02/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Mark Hindess wrote: Hi, Is there any interest in having build status emails sent to this list? I'm building classlib trunk with continuum and it would be simple for me to have messages like the following sent to the list whenever the status of our builds change. Currently I'm building only on linux but I plan to get windows builds running in the next few days. Cool. Please, only send changes (pass-fail, fail-pass). Agreed. Done. (Will the non-subscriber [EMAIL PROTECTED] be able to send to the list or is there something that needs to be done to avoid moderation/spam filtering?) We can certainly add that.. Currently the builds are running the default target in make/build.xml but if there was a top-level build-and-test target then I could run that instead. This might produce more useful results. Ah. Can you do a sequence : $ cd make $ ant $ cd .. $ ant -f build-test.xml The current build is just a direct svn co and ant project at present. My next step is to use a local repository with svn:externals pulling in the harmony trunk so I'll have more flexibility. However, I suspect more people might run the test target if this process was simplified. Of course, as Tim mentioned it's not trivial because of the requirement for a VM and other dependencies so perhaps it is not worth it. I think it is. It's great that you have a private version of this running now for us, but we want to get to a point where a) anyone can do it b) The one that we reun for the project is running here on apache infrastructure I was thinking we might be able to have standard assumptions (encoded in ant properties) about the location of dependencies and document setting up the build and test process - much as Tim has done for the classlib build. Obviously we'd want a mechanism for overriding the standard assumptions - perhaps a local (optional) included property file. Yep Perhaps once I have setup the test run I'll have a better idea about how this could be simplified. I'm going to concentrate on testing first - since the test results are probably more important than the actual build artifacts at this point - but wrapping the build should also allow me to add a publish step to our parent build if there was somewhere I could publish to? Lets get that working - we can then run it here and have it publish locally to the infrastructure... On a related note, removing the output attributes from the targets that exec make (and thus allowing the output to go to stdout/console) would produce much more helpful results and probably result in more constructive bug reports if/when the native builds fail. Yes indeedy. I never understood why they were off in a file by default. We've already had one person get confused there... Thanks. Regards, Mark. -- Forwarded message -- From: Apache Harmony Build [EMAIL PROTECTED] Date: 20-Feb-0006 11:04 Subject: [continuum] BUILD SUCCESSFUL: Classlib/linux.ia32 To: [EMAIL PROTECTED] Online report : http://ibmonly.hursley.ibm.com/continuum/linux.ia32/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/1/buildId/44 Build statistics: State: Ok Previous State: Failed Started at: Mon, 20 Feb 2006 11:03:46 + Finished at: Mon, 20 Feb 2006 11:04:56 + Total time: 1m 9s Build Trigger: Forced Exit code: 0 Building machine hostname: hy2 Operating system : Linux Java version : 1.4.2(IBM Corporation) Changes No files changed Output: [snip] -- Mark Hindess [EMAIL PROTECTED] IBM Java Technology Centre, UK.
Re: classlib build status emails?
On 21/02/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Mark Hindess wrote: On 21/02/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Mark Hindess wrote: Hi, Is there any interest in having build status emails sent to this list? I'm building classlib trunk with continuum and it would be simple for me to have messages like the following sent to the list whenever the status of our builds change. Currently I'm building only on linux but I plan to get windows builds running in the next few days. Cool. Please, only send changes (pass-fail, fail-pass). Agreed. Done. (Will the non-subscriber [EMAIL PROTECTED] be able to send to the list or is there something that needs to be done to avoid moderation/spam filtering?) We can certainly add that.. Thanks. Currently the builds are running the default target in make/build.xml but if there was a top-level build-and-test target then I could run that instead. This might produce more useful results. Ah. Can you do a sequence : $ cd make $ ant $ cd .. $ ant -f build-test.xml The current build is just a direct svn co and ant project at present. My next step is to use a local repository with svn:externals pulling in the harmony trunk so I'll have more flexibility. However, I suspect more people might run the test target if this process was simplified. Of course, as Tim mentioned it's not trivial because of the requirement for a VM and other dependencies so perhaps it is not worth it. I think it is. It's great that you have a private version of this running now for us, but we want to get to a point where a) anyone can do it b) The one that we reun for the project is running here on apache infrastructure I agree. I'd be happy to run it on apache infrastructure. I'd be happy to move development of the build-test-publish wrapper to apache infrastructure but that might slow things down a little. I'm going to concentrate on testing first - since the test results are probably more important than the actual build artifacts at this point - but wrapping the build should also allow me to add a publish step to our parent build if there was somewhere I could publish to? Lets get that working - we can then run it here and have it publish locally to the infrastructure... Agreed. Nothing we are doing here is really private except in that it is currently running on a private server. That's really a matter of getting results while avoiding the logistical issues - hardware, access, compiler licenses, etc - of running it on apache infrastructure. When it is working we can resolve those issues. Until it is working there isn't really much incentive. Regards, Mark. -- Forwarded message -- From: Apache Harmony Build [EMAIL PROTECTED] Date: 20-Feb-0006 11:04 Subject: [continuum] BUILD SUCCESSFUL: Classlib/linux.ia32 To: [EMAIL PROTECTED] Online report : http://ibmonly.hursley.ibm.com/continuum/linux.ia32/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/1/buildId/44 Build statistics: State: Ok Previous State: Failed Started at: Mon, 20 Feb 2006 11:03:46 + Finished at: Mon, 20 Feb 2006 11:04:56 + Total time: 1m 9s Build Trigger: Forced Exit code: 0 Building machine hostname: hy2 Operating system : Linux Java version : 1.4.2(IBM Corporation) Changes No files changed Output: [snip] -- Mark Hindess [EMAIL PROTECTED] IBM Java Technology Centre, UK.
Re: classlib build status emails?
Stuart Ballard stuart.a.ballard at gmail.com writes: If you can give me an url that will always point to the latest jar file(s), I can set up nightly japi results and mail diffs to this list. Geir gave me a pointer to the latest snapshots, so the japi results are now online: http://www.kaffe.org/~stuart/japi/htmlout/h-jdk10-harmony http://www.kaffe.org/~stuart/japi/htmlout/h-jdk11-harmony http://www.kaffe.org/~stuart/japi/htmlout/h-jdk12-harmony http://www.kaffe.org/~stuart/japi/htmlout/h-jdk13-harmony http://www.kaffe.org/~stuart/japi/htmlout/h-jdk14-harmony http://www.kaffe.org/~stuart/japi/htmlout/h-jdk15-harmony http://www.kaffe.org/~stuart/japi/htmlout/h-harmony-jdk15 The last report triggers a recently-discovered bug in japitools that causes some StringBuffer methods to be incorrectly reported as missing in jdk15 (which would mean that they are extra methods in harmony). I suggest ignoring the last report for now, or at least verifying anything it claims against Sun's documentation before acting on it. Other than that the reports should give correct information about Harmony's coverage of the API defined in each JDK version. Whenever these results change for better or worse, (unless I've screwed something up), an email will be sent to this list with the differences. Stuart.
Re: classlib build status emails?
These are very cool -- thanks Stuart. We need to figure out a way that we can run the japitools on a regular basis to track progress. It is also a great way to indicate where people can help round-out a particular package for example. How should I interpret a line whose percentage figures don't add up to 100% ? For example, looking at: http://www.kaffe.org/~stuart/japi/htmlout/h-jdk14-harmony The packages java.security.interfaces and java.text are flagged as less than 100% good, but without any minor/bad/missing/abs.add sins. Regards, Tim Stuart Ballard wrote: Stuart Ballard stuart.a.ballard at gmail.com writes: If you can give me an url that will always point to the latest jar file(s), I can set up nightly japi results and mail diffs to this list. Geir gave me a pointer to the latest snapshots, so the japi results are now online: http://www.kaffe.org/~stuart/japi/htmlout/h-jdk10-harmony http://www.kaffe.org/~stuart/japi/htmlout/h-jdk11-harmony http://www.kaffe.org/~stuart/japi/htmlout/h-jdk12-harmony http://www.kaffe.org/~stuart/japi/htmlout/h-jdk13-harmony http://www.kaffe.org/~stuart/japi/htmlout/h-jdk14-harmony http://www.kaffe.org/~stuart/japi/htmlout/h-jdk15-harmony http://www.kaffe.org/~stuart/japi/htmlout/h-harmony-jdk15 The last report triggers a recently-discovered bug in japitools that causes some StringBuffer methods to be incorrectly reported as missing in jdk15 (which would mean that they are extra methods in harmony). I suggest ignoring the last report for now, or at least verifying anything it claims against Sun's documentation before acting on it. Other than that the reports should give correct information about Harmony's coverage of the API defined in each JDK version. Whenever these results change for better or worse, (unless I've screwed something up), an email will be sent to this list with the differences. Stuart. -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
classlib build status emails?
Hi, Is there any interest in having build status emails sent to this list? I'm building classlib trunk with continuum and it would be simple for me to have messages like the following sent to the list whenever the status of our builds change. Currently I'm building only on linux but I plan to get windows builds running in the next few days. Currently the builds are running the default target in make/build.xml but if there was a top-level build-and-test target then I could run that instead. This might produce more useful results. On a related note, removing the output attributes from the targets that exec make (and thus allowing the output to go to stdout/console) would produce much more helpful results and probably result in more constructive bug reports if/when the native builds fail. Regards, Mark. -- Forwarded message -- From: Apache Harmony Build [EMAIL PROTECTED] Date: 20-Feb-0006 11:04 Subject: [continuum] BUILD SUCCESSFUL: Classlib/linux.ia32 To: [EMAIL PROTECTED] Online report : http://ibmonly.hursley.ibm.com/continuum/linux.ia32/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/1/buildId/44 Build statistics: State: Ok Previous State: Failed Started at: Mon, 20 Feb 2006 11:03:46 + Finished at: Mon, 20 Feb 2006 11:04:56 + Total time: 1m 9s Build Trigger: Forced Exit code: 0 Building machine hostname: hy2 Operating system : Linux Java version : 1.4.2(IBM Corporation) Changes No files changed Output: Buildfile: make/build.xml default: [echo] [echo] [echo] Building Java component archives... [echo] clean-bin: [delete] Deleting 1649 files from /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/bin [delete] Deleted 101 directories from /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/bin clean-layout: [delete] Deleting 34 files from /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/deploy clean-package: [delete] Deleting 11 files from /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/components [delete] Deleted 1 directory from /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/components clean: copy-resources: [mkdir] Created dir: /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/bin [copy] Copying 7 files to /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/bin compile: [javac] Compiling 1280 source files to /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/bin [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -deprecation for details. package: [mkdir] Created dir: /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/components [jar] Building jar: /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/components/archive.jar [jar] Building jar: /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/components/kernel-stubs.jar [jar] Building jar: /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/components/luni.jar [jar] Building jar: /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/components/nio.jar [jar] Building jar: /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/components/nio_char.jar [jar] Building jar: /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/components/security.jar [jar] Building jar: /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/components/x-net.jar [jar] Building jar: /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/components/text.jar [jar] Building jar: /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/components/math.jar [jar] Building jar: /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/components/regex.jar [jar] Building jar: /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/components/sql.jar layout: [copy] Copying 2 files to /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/deploy/jre/lib/boot [copy] Copying 11 files to /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/deploy/jre/lib/boot [copy] Copying 1 file to /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/deploy/jre/lib/boot [copy] Copying 18 files to /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/deploy/jre/bin [copy] Copying 1 file to /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/deploy/jre/lib/security [copy] Copying 1 file to /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/deploy/jre/lib/security default: [echo] [echo
Re: classlib build status emails?
Mark Hindess wrote: Hi, Is there any interest in having build status emails sent to this list? Well we've discussed this privately, but for the record yes! I'd like to see build results posted to the dev list when the build is broken/repaired. I'm building classlib trunk with continuum and it would be simple for me to have messages like the following sent to the list whenever the status of our builds change. Right, we don't need to see the results of every build, just when it goes from working to broken, or broken to working again. Currently I'm building only on linux but I plan to get windows builds running in the next few days. Currently the builds are running the default target in make/build.xml but if there was a top-level build-and-test target then I could run that instead. This might produce more useful results. Sure, use the default for now, and I'll add a 'continuum' target for you. I presume you will handle adding in some dependencies like Bouncy Castle and a VM? On a related note, removing the output attributes from the targets that exec make (and thus allowing the output to go to stdout/console) would produce much more helpful results and probably result in more constructive bug reports if/when the native builds fail. yep, that's better than hunting for the output file. Thanks. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: classlib build status emails?
Mark Hindess mark.hindess at googlemail.com writes: Is there any interest in having build status emails sent to this list? I'm building classlib trunk with continuum and it would be simple for me to have messages like the following sent to the list whenever the status of our builds change. Currently I'm building only on linux but I plan to get windows builds running in the next few days. Are the resulting rt.jar (and/or jce.jar and/or jsse.jar, or equivalent) files available anywhere? If so (as discussed previously on this list) I'd be interested in producing japi comparisons to show API coverage and errors against the various JDK versions. If you can give me an url that will always point to the latest jar file(s), I can set up nightly japi results and mail diffs to this list. (please keep me CC'd on responses, I can't keep up with the harmony list and only check the archives intermittently) Stuart.
Re: classlib build status emails?
Mark Hindess wrote: Hi, Is there any interest in having build status emails sent to this list? I'm building classlib trunk with continuum and it would be simple for me to have messages like the following sent to the list whenever the status of our builds change. Currently I'm building only on linux but I plan to get windows builds running in the next few days. Cool. Please, only send changes (pass-fail, fail-pass). Currently the builds are running the default target in make/build.xml but if there was a top-level build-and-test target then I could run that instead. This might produce more useful results. Ah. Can you do a sequence : $ cd make $ ant $ cd .. $ ant -f build-test.xml On a related note, removing the output attributes from the targets that exec make (and thus allowing the output to go to stdout/console) would produce much more helpful results and probably result in more constructive bug reports if/when the native builds fail. Yes indeedy. I never understood why they were off in a file by default. We've already had one person get confused there... Regards, Mark. -- Forwarded message -- From: Apache Harmony Build [EMAIL PROTECTED] Date: 20-Feb-0006 11:04 Subject: [continuum] BUILD SUCCESSFUL: Classlib/linux.ia32 To: [EMAIL PROTECTED] Online report : http://ibmonly.hursley.ibm.com/continuum/linux.ia32/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/1/buildId/44 Build statistics: State: Ok Previous State: Failed Started at: Mon, 20 Feb 2006 11:03:46 + Finished at: Mon, 20 Feb 2006 11:04:56 + Total time: 1m 9s Build Trigger: Forced Exit code: 0 Building machine hostname: hy2 Operating system : Linux Java version : 1.4.2(IBM Corporation) Changes No files changed Output: Buildfile: make/build.xml default: [echo] [echo] [echo] Building Java component archives... [echo] clean-bin: [delete] Deleting 1649 files from /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/bin [delete] Deleted 101 directories from /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/bin clean-layout: [delete] Deleting 34 files from /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/deploy clean-package: [delete] Deleting 11 files from /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/components [delete] Deleted 1 directory from /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/components clean: copy-resources: [mkdir] Created dir: /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/bin [copy] Copying 7 files to /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/bin compile: [javac] Compiling 1280 source files to /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/bin [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -deprecation for details. package: [mkdir] Created dir: /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/components [jar] Building jar: /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/components/archive.jar [jar] Building jar: /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/components/kernel-stubs.jar [jar] Building jar: /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/components/luni.jar [jar] Building jar: /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/components/nio.jar [jar] Building jar: /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/components/nio_char.jar [jar] Building jar: /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/components/security.jar [jar] Building jar: /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/components/x-net.jar [jar] Building jar: /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/components/text.jar [jar] Building jar: /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/components/math.jar [jar] Building jar: /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/components/regex.jar [jar] Building jar: /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/components/sql.jar layout: [copy] Copying 2 files to /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/deploy/jre/lib/boot [copy] Copying 11 files to /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/deploy/jre/lib/boot [copy] Copying 1 file to /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/deploy/jre/lib/boot [copy] Copying 18 files to /home/hybld/continuum-1.0.2/apps/continuum/working-directory/1/deploy/jre/bin
Re: classlib build status emails?
Stuart Ballard wrote: Mark Hindess mark.hindess at googlemail.com writes: Is there any interest in having build status emails sent to this list? I'm building classlib trunk with continuum and it would be simple for me to have messages like the following sent to the list whenever the status of our builds change. Currently I'm building only on linux but I plan to get windows builds running in the next few days. Are the resulting rt.jar (and/or jce.jar and/or jsse.jar, or equivalent) files available anywhere? If so (as discussed previously on this list) I'd be interested in producing japi comparisons to show API coverage and errors against the various JDK versions. The latest can be found here : http://cvs.apache.org/dist/incubator/harmony/snapshots/ Look for the latest-harmony. We'll be publishing them much more regularly going forward. If you can give me an url that will always point to the latest jar file(s), I can set up nightly japi results and mail diffs to this list. (please keep me CC'd on responses, I can't keep up with the harmony list and only check the archives intermittently) wimp :) Thanks for doing this. geir Stuart.
Re: classlib build status emails?
On 21/02/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Mark Hindess wrote: Hi, Is there any interest in having build status emails sent to this list? I'm building classlib trunk with continuum and it would be simple for me to have messages like the following sent to the list whenever the status of our builds change. Currently I'm building only on linux but I plan to get windows builds running in the next few days. Cool. Please, only send changes (pass-fail, fail-pass). Agreed. Done. (Will the non-subscriber [EMAIL PROTECTED] be able to send to the list or is there something that needs to be done to avoid moderation/spam filtering?) Currently the builds are running the default target in make/build.xml but if there was a top-level build-and-test target then I could run that instead. This might produce more useful results. Ah. Can you do a sequence : $ cd make $ ant $ cd .. $ ant -f build-test.xml The current build is just a direct svn co and ant project at present. My next step is to use a local repository with svn:externals pulling in the harmony trunk so I'll have more flexibility. However, I suspect more people might run the test target if this process was simplified. Of course, as Tim mentioned it's not trivial because of the requirement for a VM and other dependencies so perhaps it is not worth it. I was thinking we might be able to have standard assumptions (encoded in ant properties) about the location of dependencies and document setting up the build and test process - much as Tim has done for the classlib build. Obviously we'd want a mechanism for overriding the standard assumptions - perhaps a local (optional) included property file. Perhaps once I have setup the test run I'll have a better idea about how this could be simplified. I'm going to concentrate on testing first - since the test results are probably more important than the actual build artifacts at this point - but wrapping the build should also allow me to add a publish step to our parent build if there was somewhere I could publish to? On a related note, removing the output attributes from the targets that exec make (and thus allowing the output to go to stdout/console) would produce much more helpful results and probably result in more constructive bug reports if/when the native builds fail. Yes indeedy. I never understood why they were off in a file by default. We've already had one person get confused there... Thanks. Regards, Mark. -- Forwarded message -- From: Apache Harmony Build [EMAIL PROTECTED] Date: 20-Feb-0006 11:04 Subject: [continuum] BUILD SUCCESSFUL: Classlib/linux.ia32 To: [EMAIL PROTECTED] Online report : http://ibmonly.hursley.ibm.com/continuum/linux.ia32/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/1/buildId/44 Build statistics: State: Ok Previous State: Failed Started at: Mon, 20 Feb 2006 11:03:46 + Finished at: Mon, 20 Feb 2006 11:04:56 + Total time: 1m 9s Build Trigger: Forced Exit code: 0 Building machine hostname: hy2 Operating system : Linux Java version : 1.4.2(IBM Corporation) Changes No files changed Output: [snip] -- Mark Hindess [EMAIL PROTECTED] IBM Java Technology Centre, UK.
