+1 votes from Catherine, Oliver, Tim, Nathan and myself. No other
votes, so the vote passes.
Thanks for testing the artefacts and voting.
The federated build trunk is now open for commits again but the java6
branch will remain frozen until the 6.0M2 vote is concluded.
I have uploaded binaries
On 26/May/2010 22:40, Oliver Deakin wrote:
I'm seeing only recognised failures in the 6.0 tree now apart from:
org.apache.harmony.nio.tests.java.nio.channels.SocketChannelTest.test_write$LByteBuffer_writes
fails consistently even when run on its own with:
In message 4bfe248c.7050...@gmail.com, Tim Ellison writes:
On 26/May/2010 22:40, Oliver Deakin wrote:
I'm seeing only recognised failures in the 6.0 tree now apart from:
org.apache.harmony.nio.tests.java.nio.channels.SocketChannelTest.test_write
$LByteBuffer_writes
fails consistently
On 26/May/2010 18:24, Mark Hindess wrote:
In message 201005261641.o4qgf7hx023...@d06av03.portsmouth.uk.ibm.com,
Mark Hindess writes:
In message 4bfb875a.6000...@googlemail.com, Oliver Deakin writes:
On 25/05/2010 09:13, Tim Ellison wrote:
I tested on Windows XP, MS VS 2003, Ant 1.7.0
Same
This candidate looks good to me so I'm +1 to declaring the milestone.
Tested on Win XP/VS2003/Ant1.7.0
Regards,
Tim
On 23/May/2010 18:13, Mark Hindess wrote:
I have created signed source archives for revision r946981 of the java6
branch and made them available at:
On 27/05/2010 09:02, Mark Hindess wrote:
In message4bfe248c.7050...@gmail.com, Tim Ellison writes:
On 26/May/2010 22:40, Oliver Deakin wrote:
I'm seeing only recognised failures in the 6.0 tree now apart from:
Built and tested on Linux/x86, following test failed.
org.apache.harmony.jpda.tests.jdwp.Events.ClassPrepareTest (has been
disscussed above)
org.apache.harmony.luni.tests.java.io.UnixFileTest
org.apache.harmony.nio.tests.java.nio.channels.SocketChannelTest
And
1.
In message aanlktil0oxoywifnbmldmuaczelefyraxjz64t7g3...@mail.gmail.com,
Ray Chen writes:
Built and tested on Linux/x86, following test failed.
org.apache.harmony.jpda.tests.jdwp.Events.ClassPrepareTest (has been
disscussed above)
org.apache.harmony.luni.tests.java.io.UnixFileTest
OK, thanks.
So +1 for me.
On Thu, May 27, 2010 at 5:31 PM, Mark Hindess
mark.hind...@googlemail.com wrote:
In message aanlktil0oxoywifnbmldmuaczelefyraxjz64t7g3...@mail.gmail.com,
Ray Chen writes:
Built and tested on Linux/x86, following test failed.
Hi Alexei,
That is very kind of you to remind the risk of this proposal, really
appreciate!
Yes we'd learn a lot from Alexey Petrenko's great work. Why a
successful combination with harmony don't catch customers' eyes? Was its
footprint a bit large? Or it performance cannot compete with
Hi,
Just study a little in the Hadoop project - it seems it mainly focus
on Linux platform and windows is not suggested. I guess for Hadoop we can
test on Linux only, save time for tuning it best :)
2010/5/26 Jimmy,Jing Lv firep...@gmail.com
Hi,
2010/5/25 Jim Yu junjie0...@gmail.com
Hi Jimmy,
How about we give different snapshots for different famous application
like HarmonySelect-Tomcat-snapshot, HarmonySelect-Hadoop-sanpshot...
When a application is fully tested, we can make a special jre for it.
Any comments?
2010/5/27 Jimmy,Jing Lv firep...@gmail.com:
Hi Alexei,
In message aanlktinstzwtsomqjj8parb422ki2gcscyea1lhqg...@mail.gmail.com,
Ray Chen writes:
Hi Jimmy,
How about we give different snapshots for different famous application
like HarmonySelect-Tomcat-snapshot, HarmonySelect-Hadoop-sanpshot...
When a application is fully tested, we can make a
Hi,
Ray, I guess this may be a choice - but not sure if we shall make it so
specific - there is so many applications existing! And I guess there won't
be very much differences between each of them.
I think maybe we can find out some other solutions, e.g setup a base and
make some
In r948753, I've made a change to the federated build.xml so that if
-Dhy.select=true then the names of the built artefacts will be:
apache-harmony-select-5.0-...
rather than:
apache-harmony-5.0-...
I've also changed the directories that these artefacts expand into when
they are
I've just committed r948764 to remove the clean dependency from the
bundle-src target (since it does an svn export which ignores the
built files so the cleaning is irrelevant). I had to update the hudson
builds from using targets:
bundle-src fetch-depends build bundle-hdk
to:
bundle-src
+1 votes from Catherine, Tim, Ray, Oliver and myself. No other votes,
so the vote passes.
Thanks for testing the artefacts and voting.
The java6 branch is now open for commits again.
I have uploaded binaries created from the signed sources to:
http://people.apache.org/~hindessm/rc/6.0/M2/
Just changing the subject to make this more visible.
-Mark.
In message 20100527.o4rbbilu008...@d12av01.megacenter.de.ibm.com,
Mark Hindess writes:
+1 votes from Catherine, Tim, Ray, Oliver and myself. No other votes,
so the vote passes.
Thanks for testing the artefacts and voting.
Hi Nathan, I also met this problem. cast DWORD to a DWORDLONG will fix this.
I will try to upload the patch.
On Thu, May 27, 2010 at 10:10 AM, Nathan Beyer ndbe...@apache.org wrote:
On Wed, May 26, 2010 at 9:08 PM, Nathan Beyer ndbe...@apache.org wrote:
It seems VS 2008 doesn't compile any
In message 201005271025.o4rappbb016...@d06av03.portsmouth.uk.ibm.com,
Mark Hindess writes:
[snip]
However, the federated build for -Dhy.select=true currently fails
because, for example, the serialver -show implementation requires
some modules that aren't included in select.
I think we
In message aanlktikemrmbiyqva2fnpkr4vcvaw7af6lwmig8ns...@mail.gmail.com,
Nathan Beyer writes:
On Wed, May 26, 2010 at 4:59 AM, Mark Hindess
mark.hind...@googlemail.com wrote:
Last night I decided to try to implement this simple exclude list
mechanism in my build-improvement branch.
In message 201005271258.o4rcwkd7006...@d06av02.portsmouth.uk.ibm.com,
Mark Hindess writes:
In message 201005271025.o4rappbb016...@d06av03.portsmouth.uk.ibm.com,
Mark Hindess writes:
[snip]
However, the federated build for -Dhy.select=true currently fails
because, for example, the
On Thu, May 27, 2010 at 4:04 PM, Joshua Bloch j...@google.com wrote:
I was a bit surprised to see efforts being made to improve Android docs.
The previous common wisdom had been ignore them; everyone with any sense
will read JDK JavaDocs instead.
The new goal of our team is, write better
it turned out that developers are using our documentation because they
need to use it for the Android-specific classes, and it's just
convenient for them to get all their documentation from the same
place. plus a large proportion of external bugs are basically only
solvable via better
On Thu, May 27, 2010 at 9:12 AM, Mark Hindess
mark.hind...@googlemail.com wrote:
In message aanlktikemrmbiyqva2fnpkr4vcvaw7af6lwmig8ns...@mail.gmail.com,
Nathan Beyer writes:
On Wed, May 26, 2010 at 4:59 AM, Mark Hindess
mark.hind...@googlemail.com wrote:
Last night I decided to try to
25 matches
Mail list logo