You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Tim Ellison <t....@gmail.com> on 2009/11/23 21:19:14 UTC
Re: svn commit: r883478 - in /harmony/enhanced/classlib/trunk: modules/archive/make/exclude.common
modules/archive/src/test/java/org/apache/harmony/archive/tests/java/util/jar/JarFileTest.java
support/src/test/java/tests/resources/hyts_flushed.jar
Code freeze. No commits without a second committer's agreement until
the milestone is declared. Including excluded tests.
The goal is to ensure we have a stable codebase on which we are all testing.
The freeze is also an incentive for everyone to help with the testing
and get the milestone declared <g>.
Regards,
Tim
On 23/Nov/2009 20:03, jessewilson@apache.org wrote:
> Author: jessewilson
> Date: Mon Nov 23 20:03:06 2009
> New Revision: 883478
>
> URL: http://svn.apache.org/viewvc?rev=883478&view=rev
> Log:
> Adding a test case that demonstrates a bug in JAR file decoding.
>
> The specific problem discovered indirectly by the Pack200 test, which ran into problems with jar files created using the now-rolled back flush() support in DeflaterOutputStream. The RI passes this test.
>
> The test is suppressed in exclude.common.
>
> Added:
> harmony/enhanced/classlib/trunk/support/src/test/java/tests/resources/hyts_flushed.jar (with props)
> Modified:
> harmony/enhanced/classlib/trunk/modules/archive/make/exclude.common
> harmony/enhanced/classlib/trunk/modules/archive/src/test/java/org/apache/harmony/archive/tests/java/util/jar/JarFileTest.java
>
> Modified: harmony/enhanced/classlib/trunk/modules/archive/make/exclude.common
> URL: http://svn.apache.org/viewvc/harmony/enhanced/classlib/trunk/modules/archive/make/exclude.common?rev=883478&r1=883477&r2=883478&view=diff
> ==============================================================================
> --- harmony/enhanced/classlib/trunk/modules/archive/make/exclude.common (original)
> +++ harmony/enhanced/classlib/trunk/modules/archive/make/exclude.common Mon Nov 23 20:03:06 2009
> @@ -0,0 +1 @@
> +org/apache/harmony/archive/tests/java/util/jar/JarFileTest.java
> \ No newline at end of file
>
> Modified: harmony/enhanced/classlib/trunk/modules/archive/src/test/java/org/apache/harmony/archive/tests/java/util/jar/JarFileTest.java
> URL: http://svn.apache.org/viewvc/harmony/enhanced/classlib/trunk/modules/archive/src/test/java/org/apache/harmony/archive/tests/java/util/jar/JarFileTest.java?rev=883478&r1=883477&r2=883478&view=diff
> ==============================================================================
> --- harmony/enhanced/classlib/trunk/modules/archive/src/test/java/org/apache/harmony/archive/tests/java/util/jar/JarFileTest.java (original)
> +++ harmony/enhanced/classlib/trunk/modules/archive/src/test/java/org/apache/harmony/archive/tests/java/util/jar/JarFileTest.java Mon Nov 23 20:03:06 2009
> @@ -661,4 +661,12 @@
> res = jarFile.getInputStream(zipEntry).read();
> assertEquals("Wrong length of empty jar entry", -1, res);
> }
> +
> + public void testJarWrittenWithFlush() throws IOException {
> + File f = new File(resources, "hyts_flushed.jar");
> + Support_Resources.copyFile(resources, null, "hyts_flushed.jar");
> +
> + // Harmony crashes with ZipException: Central Directory Entry not found
> + new JarFile(f);
> + }
> }
>
> Added: harmony/enhanced/classlib/trunk/support/src/test/java/tests/resources/hyts_flushed.jar
> URL: http://svn.apache.org/viewvc/harmony/enhanced/classlib/trunk/support/src/test/java/tests/resources/hyts_flushed.jar?rev=883478&view=auto
> ==============================================================================
> Binary file - no diff available.
>
> Propchange: harmony/enhanced/classlib/trunk/support/src/test/java/tests/resources/hyts_flushed.jar
> ------------------------------------------------------------------------------
> svn:mime-type = application/octet-stream
>
>
>
Re: svn commit: r883478 - in /harmony/enhanced/classlib/trunk: modules/archive/make/exclude.common
modules/archive/src/test/java/org/apache/harmony/archive/tests/java/util/jar/JarFileTest.java
support/src/test/java/tests/resources/hyts_flushed.jar
Posted by Regis <xu...@gmail.com>.
sebb wrote:
> On 23/11/2009, Jesse Wilson <je...@google.com> wrote:
>
> On the other hand, if there are lots of failing tests, it can be
> difficult to spot tests that fail occasionally.
>
> Test cases that are known to fail could document this, e.g. by
> printing a message to say that the failure is expected.
>
> If Harmony uses JUnit4, then the @Ignored annotation could be used for
> tests that are not expected to pass; AIUI the test summary shows how
> many tests have been ignored.
> There are probably similar features in other unit test implementations.
>
It sounds good. I'm not familiar with this "new" feature, does @ignored
annotation could separate tests by OS and JVM? Currently we have different
exclude lists on different JVM and OS.
--
Best Regards,
Regis.
Re: [classlib] junit4 @Ignore and reporting (was svn commit: r883478...)
Posted by Tim Ellison <t....@gmail.com>.
On 24/Nov/2009 08:06, Mark Hindess wrote:
> In message <3b...@mail.gmail.com>,
> Nathan Beyer writes:
>> I'd love to see the exclude files dropped in favor of JUnit @Ignore +
>> reporting for those ignored tests. That would be extremely helpful in
>> pointing out all of the excluded tests.
>
> +1 provided we can record details of why the test is ignored.
Just pass a string in the annotation constructor,
e.g. @Ignore("It's the wrong colour")
> We'll also need a mechanism to support the os/vm combinations the
> exclude lists support too though. Any ideas?
I guess it will require some (modest) extensions to the test framework.
Maybe some combination of our own annotations and
org.junit.runner.manipulation.Filter ?
Regards,
Tim
[classlib] junit4 @Ignore and reporting (was svn commit: r883478...)
Posted by Mark Hindess <ma...@googlemail.com>.
In message <3b...@mail.gmail.com>,
Nathan Beyer writes:
>
> I'd love to see the exclude files dropped in favor of JUnit @Ignore +
> reporting for those ignored tests. That would be extremely helpful in
> pointing out all of the excluded tests.
+1 provided we can record details of why the test is ignored. We'll
also need a mechanism to support the os/vm combinations the exclude
lists support too though. Any ideas?
Regards,
Mark.
Re: svn commit: r883478 - in /harmony/enhanced/classlib/trunk:
modules/archive/make/exclude.common modules/archive/src/test/java/org/apache/harmony/archive/tests/java/util/jar/JarFileTest.java
support/src/test/java/tests/resources/hyts_flushed.jar
Posted by Jesse Wilson <je...@google.com>.
On Mon, Nov 23, 2009 at 6:01 PM, Nathan Beyer <nd...@apache.org> wrote:
> I'd love to see the exclude files dropped in favor of JUnit @Ignore +
> reporting for those ignored tests. That would be extremely helpful in
> pointing out all of the excluded tests.
>
Yes!
Re: svn commit: r883478 - in /harmony/enhanced/classlib/trunk:
modules/archive/make/exclude.common modules/archive/src/test/java/org/apache/harmony/archive/tests/java/util/jar/JarFileTest.java
support/src/test/java/tests/resources/hyts_flushed.jar
Posted by Nathan Beyer <nd...@apache.org>.
On Mon, Nov 23, 2009 at 5:08 PM, sebb <se...@gmail.com> wrote:
> On 23/11/2009, Jesse Wilson <je...@google.com> wrote:
>> On Mon, Nov 23, 2009 at 2:29 PM, Tim Ellison <t....@gmail.com> wrote:
>>
>> > On 23/Nov/2009 20:27, Jesse Wilson wrote:
>> > > My bad for committing during the code freeze.
>> >
>> > So you're going to rollback, esp. so we don't exclude all the other
>> > tests in that type?
>> >
>>
>>
>> I can certainly rollback the changes to the exclude.common file.
>>
>>
>>
>> > > Does it make sense to limit test changes during the code freeze? I don't
>> > see
>> > > any benefit.
>> >
>> > We ensure that the tests pass and we ship the tests as part of our
>> > Milestone deliveries. The benefit of including them in the code freeze
>> > is that we are not trying to hit a moving target and/or introducing new
>> > bugs (i.e. the same reasons the implementation code stays frozen during
>> > final test/release).
>> >
>>
>>
>> It's dysfunctional to not checkin a test just because we don't currently
>> pass it. If anything, we need a better mechanism to manage which failures we
>> have. My personal preference is to just let them fail, and to watch Hudson
>> for unexpected failures. Suppressing a test as it gets added to avoid seeing
>> red in Hudson is bogus: our implementation is not perfect and our tools
>> should relay that back to us.
>
> On the other hand, if there are lots of failing tests, it can be
> difficult to spot tests that fail occasionally.
>
> Test cases that are known to fail could document this, e.g. by
> printing a message to say that the failure is expected.
>
> If Harmony uses JUnit4, then the @Ignored annotation could be used for
> tests that are not expected to pass; AIUI the test summary shows how
> many tests have been ignored.
> There are probably similar features in other unit test implementations.
>
We've had JUnit4 capability for a long time - we even have the
Hamcrest Matchers available. This has been the case for long enough
that I'd say we can begin depending upon it at any time. I'm not sure
what the reports that Ant generates look like, but I presume we can
modify that as we see fit.
I'd love to see the exclude files dropped in favor of JUnit @Ignore +
reporting for those ignored tests. That would be extremely helpful in
pointing out all of the excluded tests.
Re: svn commit: r883478 - in /harmony/enhanced/classlib/trunk:
modules/archive/make/exclude.common modules/archive/src/test/java/org/apache/harmony/archive/tests/java/util/jar/JarFileTest.java
support/src/test/java/tests/resources/hyts_flushed.jar
Posted by sebb <se...@gmail.com>.
On 23/11/2009, Jesse Wilson <je...@google.com> wrote:
> On Mon, Nov 23, 2009 at 2:29 PM, Tim Ellison <t....@gmail.com> wrote:
>
> > On 23/Nov/2009 20:27, Jesse Wilson wrote:
> > > My bad for committing during the code freeze.
> >
> > So you're going to rollback, esp. so we don't exclude all the other
> > tests in that type?
> >
>
>
> I can certainly rollback the changes to the exclude.common file.
>
>
>
> > > Does it make sense to limit test changes during the code freeze? I don't
> > see
> > > any benefit.
> >
> > We ensure that the tests pass and we ship the tests as part of our
> > Milestone deliveries. The benefit of including them in the code freeze
> > is that we are not trying to hit a moving target and/or introducing new
> > bugs (i.e. the same reasons the implementation code stays frozen during
> > final test/release).
> >
>
>
> It's dysfunctional to not checkin a test just because we don't currently
> pass it. If anything, we need a better mechanism to manage which failures we
> have. My personal preference is to just let them fail, and to watch Hudson
> for unexpected failures. Suppressing a test as it gets added to avoid seeing
> red in Hudson is bogus: our implementation is not perfect and our tools
> should relay that back to us.
On the other hand, if there are lots of failing tests, it can be
difficult to spot tests that fail occasionally.
Test cases that are known to fail could document this, e.g. by
printing a message to say that the failure is expected.
If Harmony uses JUnit4, then the @Ignored annotation could be used for
tests that are not expected to pass; AIUI the test summary shows how
many tests have been ignored.
There are probably similar features in other unit test implementations.
[general] Code freeze or branching (was svn commit: r883478...)
Posted by Mark Hindess <ma...@googlemail.com>.
In message <3b...@mail.gmail.com>,
Nathan Beyer writes:
>
> Let's separate the two issues here -
> * excluding failing tests - i'd agree that our current exclusion
> approach isn't optimal - how can we make it better?
> * extent of code freeze - should all commits be stopped? i'd suggest
> that we consider for the next milestone, use branching and freeze that
> code.
-1. As Tim says, the code freeze is about forcing everyone to stop
working on new code and concentrate on what needs to be fixed to get a
good quality release out the door. I'm not sure it really works but I'm
sure branching wouldn't help.
Regards,
Mark.
Re: svn commit: r883478 - in /harmony/enhanced/classlib/trunk:
modules/archive/make/exclude.common modules/archive/src/test/java/org/apache/harmony/archive/tests/java/util/jar/JarFileTest.java
support/src/test/java/tests/resources/hyts_flushed.jar
Posted by Ray Chen <cl...@gmail.com>.
Sounds good for "use branching and freeze that code."
--
Regards,
Ray Chen
Re: svn commit: r883478 - in /harmony/enhanced/classlib/trunk:
modules/archive/make/exclude.common modules/archive/src/test/java/org/apache/harmony/archive/tests/java/util/jar/JarFileTest.java
support/src/test/java/tests/resources/hyts_flushed.jar
Posted by Nathan Beyer <nd...@apache.org>.
On Mon, Nov 23, 2009 at 4:40 PM, Jesse Wilson <je...@google.com> wrote:
> On Mon, Nov 23, 2009 at 2:29 PM, Tim Ellison <t....@gmail.com> wrote:
>
>> On 23/Nov/2009 20:27, Jesse Wilson wrote:
>> > My bad for committing during the code freeze.
>>
>> So you're going to rollback, esp. so we don't exclude all the other
>> tests in that type?
>>
>
> I can certainly rollback the changes to the exclude.common file.
>
>
>> > Does it make sense to limit test changes during the code freeze? I don't
>> see
>> > any benefit.
>>
>> We ensure that the tests pass and we ship the tests as part of our
>> Milestone deliveries. The benefit of including them in the code freeze
>> is that we are not trying to hit a moving target and/or introducing new
>> bugs (i.e. the same reasons the implementation code stays frozen during
>> final test/release).
>>
>
> It's dysfunctional to not checkin a test just because we don't currently
> pass it. If anything, we need a better mechanism to manage which failures we
> have. My personal preference is to just let them fail, and to watch Hudson
> for unexpected failures. Suppressing a test as it gets added to avoid seeing
> red in Hudson is bogus: our implementation is not perfect and our tools
> should relay that back to us.
>
Let's separate the two issues here -
* excluding failing tests - i'd agree that our current exclusion
approach isn't optimal - how can we make it better?
* extent of code freeze - should all commits be stopped? i'd suggest
that we consider for the next milestone, use branching and freeze that
code.
Re: svn commit: r883478 - in /harmony/enhanced/classlib/trunk:
modules/archive/make/exclude.common modules/archive/src/test/java/org/apache/harmony/archive/tests/java/util/jar/JarFileTest.java
support/src/test/java/tests/resources/hyts_flushed.jar
Posted by Jesse Wilson <je...@google.com>.
On Mon, Nov 23, 2009 at 2:29 PM, Tim Ellison <t....@gmail.com> wrote:
> On 23/Nov/2009 20:27, Jesse Wilson wrote:
> > My bad for committing during the code freeze.
>
> So you're going to rollback, esp. so we don't exclude all the other
> tests in that type?
>
I can certainly rollback the changes to the exclude.common file.
> > Does it make sense to limit test changes during the code freeze? I don't
> see
> > any benefit.
>
> We ensure that the tests pass and we ship the tests as part of our
> Milestone deliveries. The benefit of including them in the code freeze
> is that we are not trying to hit a moving target and/or introducing new
> bugs (i.e. the same reasons the implementation code stays frozen during
> final test/release).
>
It's dysfunctional to not checkin a test just because we don't currently
pass it. If anything, we need a better mechanism to manage which failures we
have. My personal preference is to just let them fail, and to watch Hudson
for unexpected failures. Suppressing a test as it gets added to avoid seeing
red in Hudson is bogus: our implementation is not perfect and our tools
should relay that back to us.
Re: svn commit: r883478 - in /harmony/enhanced/classlib/trunk: modules/archive/make/exclude.common
modules/archive/src/test/java/org/apache/harmony/archive/tests/java/util/jar/JarFileTest.java
support/src/test/java/tests/resources/hyts_flushed.jar
Posted by Tim Ellison <t....@gmail.com>.
On 23/Nov/2009 20:27, Jesse Wilson wrote:
> My bad for committing during the code freeze.
So you're going to rollback, esp. so we don't exclude all the other
tests in that type?
> Does it make sense to limit test changes during the code freeze? I don't see
> any benefit.
We ensure that the tests pass and we ship the tests as part of our
Milestone deliveries. The benefit of including them in the code freeze
is that we are not trying to hit a moving target and/or introducing new
bugs (i.e. the same reasons the implementation code stays frozen during
final test/release).
Regards,
Tim
Re: svn commit: r883478 - in /harmony/enhanced/classlib/trunk:
modules/archive/make/exclude.common modules/archive/src/test/java/org/apache/harmony/archive/tests/java/util/jar/JarFileTest.java
support/src/test/java/tests/resources/hyts_flushed.jar
Posted by Jesse Wilson <je...@google.com>.
My bad for committing during the code freeze.
Does it make sense to limit test changes during the code freeze? I don't see
any benefit.