From mark@klomp.org Sun Jan 1 20:41:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Sun, 01 Jan 2006 20:41:00 -0000 Subject: patch to run 1 testlet with "classpath" fakejdk In-Reply-To: <200512250927.55279.raif@swiftdsl.com.au> References: <200512250927.55279.raif@swiftdsl.com.au> Message-ID: <1136148081.3250.78.camel@localhost.localdomain> Hi Raif, On Sun, 2005-12-25 at 09:27 +1100, Raif S. Naffah wrote: > pls. find attached a patch to add to Eclipse a Runner that runs one > selected Mauve testlet with the "fakejdk" named "classpath." Nice! committed. I see you added a description of how to setup the fakejdk to the wiki. The wiki also has a desciption on how to add a Runner. But couldn't find a way to export/import that so others could use that. Is an external tool the preferred way to do this? Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From raif@swiftdsl.com.au Sun Jan 1 21:54:00 2006 From: raif@swiftdsl.com.au (Raif S. Naffah) Date: Sun, 01 Jan 2006 21:54:00 -0000 Subject: patch to run 1 testlet with "classpath" fakejdk In-Reply-To: <1136148081.3250.78.camel@localhost.localdomain> References: <200512250927.55279.raif@swiftdsl.com.au> <1136148081.3250.78.camel@localhost.localdomain> Message-ID: <200601020856.09419.raif@swiftdsl.com.au> hello Mark, happy new year! On Monday 02 January 2006 07:41, Mark Wielaard wrote: > Hi Raif, > > On Sun, 2005-12-25 at 09:27 +1100, Raif S. Naffah wrote: > > pls. find attached a patch to add to Eclipse a Runner that runs one > > selected Mauve testlet with the "fakejdk" named "classpath." > > Nice! committed. thanks. > I see you added a description of how to setup the fakejdk to the > wiki. The wiki also has a desciption on how to add a Runner. But > couldn't find a way to export/import that so others could use that. > Is an external tool the preferred way to do this? besides the usual project CVS update, i don't know of any obvious way to share these tools among users --who most likely would have their projects created in locations that differ from one user to another. other more proficient Eclipse users may know better. cheers; rsn -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 216 bytes Desc: not available URL: From raif@swiftdsl.com.au Sun Jan 1 23:11:00 2006 From: raif@swiftdsl.com.au (Raif S. Naffah) Date: Sun, 01 Jan 2006 23:11:00 -0000 Subject: patches to ensure names w/ extra spaces are recognized Message-ID: <200601021012.54773.raif@swiftdsl.com.au> hello there, pls find attached a patch to existing MessageDigest.getInstance14.java and a new Engine.getInstance file to ensure that Provider, Service and Algorithm names should be recognized even when they contain extra space characters. the corresponding ChangeLog entry follows: 2006-01-02 Raif S. Naffah * gnu/testlet/java/security/MessageDigest/getInstance14.java (test): Corrected string literal used in harness.checkPoint(). Added 2 new testcases to test passing Provider and Algorithm names with extra spaces. * gnu/testlet/java/security/Engine/getInstance.java: new file. -- cheers; rsn -------------- next part -------------- A non-text attachment was scrubbed... Name: mauve-20060102.patch Type: text/x-diff Size: 5054 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 216 bytes Desc: not available URL: From raif@swiftdsl.com.au Sun Jan 1 23:35:00 2006 From: raif@swiftdsl.com.au (Raif S. Naffah) Date: Sun, 01 Jan 2006 23:35:00 -0000 Subject: patch to ensure hostnames w/ extra spaces are recognized Message-ID: <200601021036.57527.raif@swiftdsl.com.au> hello there, pls. find attached a patch to InetAddress.getAllByName that tests for hostname strings with extra space characters. the corresponding ChangeLog entry follows: 2006-01-01 Raif S. Naffah * gnu/testlet/java/net/InetAddress/getAllByName.java (test): Ensure hostname strings with extra spaces are recognized. cheers; rsn -------------- next part -------------- A non-text attachment was scrubbed... Name: mauve-20060102b.patch Type: text/x-diff Size: 2044 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 216 bytes Desc: not available URL: From mark@klomp.org Mon Jan 2 12:29:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Mon, 02 Jan 2006 12:29:00 -0000 Subject: patches to ensure names w/ extra spaces are recognized In-Reply-To: <200601021012.54773.raif@swiftdsl.com.au> References: <200601021012.54773.raif@swiftdsl.com.au> Message-ID: <1136204978.8118.4.camel@localhost> Hi Raif, On Mon, 2006-01-02 at 10:12 +1100, Raif S. Naffah wrote: > pls find attached a patch to existing MessageDigest.getInstance14.java > and a new Engine.getInstance file to ensure that Provider, Service and > Algorithm names should be recognized even when they contain extra space > characters. This and your next patch for hostnames look good to me. Tom said you should already have cvs access for Mauve so please feel free to check these in. (I am currently packing up my machines for moving so I don't have a good setup atm for quickly doing it myself.) Thanks, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From raif@swiftdsl.com.au Mon Jan 2 14:10:00 2006 From: raif@swiftdsl.com.au (Raif S. Naffah) Date: Mon, 02 Jan 2006 14:10:00 -0000 Subject: patches to ensure names w/ extra spaces are recognized In-Reply-To: <1136204978.8118.4.camel@localhost> References: <200601021012.54773.raif@swiftdsl.com.au> <1136204978.8118.4.camel@localhost> Message-ID: <200601030112.22578.raif@swiftdsl.com.au> hello Mark, On Monday 02 January 2006 23:29, Mark Wielaard wrote: > Hi Raif, > > On Mon, 2006-01-02 at 10:12 +1100, Raif S. Naffah wrote: > > pls find attached a patch to existing > > MessageDigest.getInstance14.java and a new Engine.getInstance file > > to ensure that Provider, Service and Algorithm names should be > > recognized even when they contain extra space characters. > > This and your next patch for hostnames look good to me. > Tom said you should already have cvs access for Mauve so please feel > free to check these in. (I am currently packing up my machines for > moving so I don't have a good setup atm for quickly doing it myself.) i do have write access to Mauve CVS and have already checked the two patches (as one commit) in. cheers; rsn -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 216 bytes Desc: not available URL: From roman@kennke.org Sat Jan 14 21:33:00 2006 From: roman@kennke.org (Roman Kennke) Date: Sat, 14 Jan 2006 21:33:00 -0000 Subject: Updating Mauve tags Message-ID: <1137274393.7808.6.camel@localhost.localdomain> Hi there, (BTW: This is a Mauve topic, I CC the classpath list because the mauve-discuss list seems so dead). I see that we have a concept of tags in Mauve. That is a collection of keys at the top of each test class. This way we can filter the tests. ATM we have tags for the JDK versions like JDK1.4 JDK1.3 and so on and a couple of other tags. However, it seems that they are not maintained in a usable way, so most people simply include every tag that they can think of (that is what's done in batch_run for example) to run all tests. I would like to fix the tagging of the tests with regard to the JDK versions. And since the current reference is JDK1.5, I would naturally start with this one. What I propose to do is run all the tests under JDK1.5 and set the JDK1.5 tag for all tests that pass there. For all tests that FAIL and have the JDK1.5 tag set, this tag would have to be removed. Later I would like to do the same for JDK1.4 and JDK1.3. (I have no JDK1.2 JDK1.1 or JDK1.0 available, otherwise I would probably do the same for these). What do you think about this? Maybe I completely misunderstand the concept and working of the tags? Cheers, /Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From mark@klomp.org Sun Jan 15 22:08:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Sun, 15 Jan 2006 22:08:00 -0000 Subject: Updating Mauve tags In-Reply-To: <1137274393.7808.6.camel@localhost.localdomain> References: <1137274393.7808.6.camel@localhost.localdomain> Message-ID: <1137361555.9102.78.camel@localhost.localdomain> Hi Roman, On Sat, 2006-01-14 at 22:33 +0100, Roman Kennke wrote: > (BTW: This is a Mauve topic, I CC the classpath list because the > mauve-discuss list seems so dead). Once upon a time there were lots of standard class library projects (kaffe, gcj, classpath) and we started cooperating by sharing a test suite. When most of these libraries merged together the test suite became a bit more the "gnu classpath" testsuite, but there are still independent users out there (although most of them are indeed pretty quiet - acunia used it for wonka, hp used it for chai, ibm used it for j9 and of course aicas uses it for jamaica, there are probably some others out there that never publicly announced their usage of the test suite.). > I see that we have a concept of tags in Mauve. That is a collection of > keys at the top of each test class. This way we can filter the tests. > ATM we have tags for the JDK versions like JDK1.4 JDK1.3 and so on and a > couple of other tags. However, it seems that they are not maintained in > a usable way, so most people simply include every tag that they can > think of (that is what's done in batch_run for example) to run all > tests. Why do you feel they aren't maintained in a usable way? A test should mention the minimum version that it should work against. And can mention newer versions for which the tests isn't valid anymore (although I don't know of many examples of that). The README explains as follows: Tags must all appear on a single line beginning "// Tags: ". Many files test functionality that has existed since JDK1.0. The corresponding line in the source: // Tags: JDK1.0 Here is how you would tag something that first appeared in JDK1.2: // Tags: JDK1.2 Here is how you would tag something that was eliminated in JDK1.2: // Tags: JDK1.0 !JDK1.2 The idea behind this scheme is that it is undesirable to update all the files whenever we add a tag. So instead most tags are defined in terms of primitive tags, and then we note the exceptions. The reason the batch_run script lists all the tags is simply because it wants to run all the tests. > I would like to fix the tagging of the tests with regard to the JDK > versions. And since the current reference is JDK1.5, I would naturally > start with this one. What I propose to do is run all the tests under > JDK1.5 and set the JDK1.5 tag for all tests that pass there. For all > tests that FAIL and have the JDK1.5 tag set, this tag would have to be > removed. Later I would like to do the same for JDK1.4 and JDK1.3. (I > have no JDK1.2 JDK1.1 or JDK1.0 available, otherwise I would probably do > the same for these). It might be interesting to know what tests fail against which version of the reference implementation, but the reference implementation does have bugs, some of which aren't present in other implementations. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From roman@kennke.org Sun Jan 15 23:59:00 2006 From: roman@kennke.org (Roman Kennke) Date: Sun, 15 Jan 2006 23:59:00 -0000 Subject: Updating Mauve tags In-Reply-To: <1137361555.9102.78.camel@localhost.localdomain> References: <1137274393.7808.6.camel@localhost.localdomain> <1137361555.9102.78.camel@localhost.localdomain> Message-ID: <1137369579.7846.32.camel@localhost.localdomain> Hi Mark, > > I see that we have a concept of tags in Mauve. That is a collection of > > keys at the top of each test class. This way we can filter the tests. > > ATM we have tags for the JDK versions like JDK1.4 JDK1.3 and so on and a > > couple of other tags. However, it seems that they are not maintained in > > a usable way, so most people simply include every tag that they can > > think of (that is what's done in batch_run for example) to run all > > tests. > > Why do you feel they aren't maintained in a usable way? This was caused by a misunderstanding of the usage/meaning of those tags. I was thinking that when a test has the tag JDK1.x, that this test is meant to PASS under a JDK1.x-ish JDK. As Michael and others have pointed out on IRC this is not the case. If I want to test a JDK1.3-sh (for example) environment I should include JDK1.0 JDK1.1 JDK1.2 and JDK1.3 tags in my keys. The problem that I am seeing is when a test that is written to PASS under 1.4 fails under 1.5. There are lots of those tests in the testsuite for the javax.swing package. So my plan would have been to tag all tests that pass under JDK1.5 with the 1.5 tag and those that don't only with JDK1.4 or whatever is ok. Since the tags are not meant to be used that way, maybe we can do it different. Could we extend the choose-classes script to detect !JDK1.x tags in the tag header of java source files and don't include the test in a JDK1.x test run? /Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From izecksohn@yahoo.com Mon Jan 16 02:46:00 2006 From: izecksohn@yahoo.com (Pedro Izecksohn) Date: Mon, 16 Jan 2006 02:46:00 -0000 Subject: Proposed Mauve test: childNodesLength Message-ID: <200601160047.59642.izecksohn@yahoo.com> Two files are attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: test.xml Type: text/xml Size: 285 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: childNodesLength.java Type: text/x-java Size: 3426 bytes Desc: not available URL: From audriusa@bluewin.ch Mon Jan 16 10:25:00 2006 From: audriusa@bluewin.ch (Meskauskas Audrius) Date: Mon, 16 Jan 2006 10:25:00 -0000 Subject: Updating Mauve tags In-Reply-To: <1137369579.7846.32.camel@localhost.localdomain> References: <1137274393.7808.6.camel@localhost.localdomain> <1137361555.9102.78.camel@localhost.localdomain> <1137369579.7846.32.camel@localhost.localdomain> Message-ID: <43CB74BF.9040708@bluewin.ch> The Sun's swing did have as many as 6514 bugs through the history, despite many of them are fixed now. Together with the new features and improvements, each new major release inevitably brings some regressions that are later fixed. J2SE 5.0 already had six updates in the past. They do make some mistakes, same as we do, same as any java development group inevitably does. This may be especially true for tests that were succeeding in the past but fail with the newest version. Because of that reason I would not suggest any automated removal or inactivation of the tests just because they fail on Sun's or any other java implementation. If the implemented behavior clearly mismatches the Sun's API specification, this is probably just a bug that is likely to be fixed - probably in the next minor release. Some tests can be invalid and can be inactivated or removed (probably better altered, making them valid). However I think that this work (a difficult work) must be done manually. The typical reason can be if we find the similar problem in the Sun's bug reports and the Sun states that this is not a bug or it will never be fixed, or if we realize that the former author of the test clearly misinterprets the Sun's API standard. If needed, we could probably simply have and use the list of tests that are known to pass with the final releases of the JDK 1.2, 1.3 and 1.4 (for the 1.5, such list would need the regular updates). Audrius. Roman Kennke wrote: >Hi Mark, > > > >>>I see that we have a concept of tags in Mauve. That is a collection of >>>keys at the top of each test class. This way we can filter the tests. >>>ATM we have tags for the JDK versions like JDK1.4 JDK1.3 and so on and a >>>couple of other tags. However, it seems that they are not maintained in >>>a usable way, so most people simply include every tag that they can >>>think of (that is what's done in batch_run for example) to run all >>>tests. >>> >>> >>Why do you feel they aren't maintained in a usable way? >> >> > >This was caused by a misunderstanding of the usage/meaning of those >tags. I was thinking that when a test has the tag JDK1.x, that this test >is meant to PASS under a JDK1.x-ish JDK. As Michael and others have >pointed out on IRC this is not the case. If I want to test a JDK1.3-sh >(for example) environment I should include JDK1.0 JDK1.1 JDK1.2 and >JDK1.3 tags in my keys. > >The problem that I am seeing is when a test that is written to PASS >under 1.4 fails under 1.5. There are lots of those tests in the >testsuite for the javax.swing package. So my plan would have been to tag >all tests that pass under JDK1.5 with the 1.5 tag and those that don't >only with JDK1.4 or whatever is ok. Since the tags are not meant to be >used that way, maybe we can do it different. Could we extend the >choose-classes script to detect !JDK1.x tags in the tag header of java >source files and don't include the test in a JDK1.x test run? > >/Roman > > From mark@klomp.org Mon Jan 16 10:32:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Mon, 16 Jan 2006 10:32:00 -0000 Subject: Updating Mauve tags In-Reply-To: <1137369579.7846.32.camel@localhost.localdomain> References: <1137274393.7808.6.camel@localhost.localdomain> <1137361555.9102.78.camel@localhost.localdomain> <1137369579.7846.32.camel@localhost.localdomain> Message-ID: <1137404915.5615.14.camel@localhost.localdomain> Hi Roman, On Mon, 2006-01-16 at 00:59 +0100, Roman Kennke wrote: > The problem that I am seeing is when a test that is written to PASS > under 1.4 fails under 1.5. There are lots of those tests in the > testsuite for the javax.swing package. To be honest, I would just remove those tests and concentrate on the 1.5 ones. > So my plan would have been to tag > all tests that pass under JDK1.5 with the 1.5 tag and those that don't > only with JDK1.4 or whatever is ok. Since the tags are not meant to be > used that way, maybe we can do it different. Could we extend the > choose-classes script to detect !JDK1.x tags in the tag header of java > source files and don't include the test in a JDK1.x test run? I always thought it already worked that way (see the README), so if it doesn't and you can make it actually do that then that would be great. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From david.gilbert@object-refinery.com Mon Jan 16 10:59:00 2006 From: david.gilbert@object-refinery.com (David Gilbert) Date: Mon, 16 Jan 2006 10:59:00 -0000 Subject: Updating Mauve tags In-Reply-To: <1137369579.7846.32.camel@localhost.localdomain> References: <1137274393.7808.6.camel@localhost.localdomain> <1137361555.9102.78.camel@localhost.localdomain> <1137369579.7846.32.camel@localhost.localdomain> Message-ID: <43CB7CA1.6040602@object-refinery.com> Roman Kennke wrote: >The problem that I am seeing is when a test that is written to PASS >under 1.4 fails under 1.5. There are lots of those tests in the >testsuite for the javax.swing package. > Hi Roman, Did I write those tests (or some of them)? If so, send me the file names and I'll see if I can clean them up a bit. When I wrote them, I checked the results only against Sun JDK 1.4.2 (*), but recently I have started to use JDK 1.5 more regularly so now I can work on bringing the tests up to date. Regards, Dave (*) One of the problems with Swing is that the API docs are very much underspecified (completely missing in many cases), so it becomes necessary to make educated guesses when writing the tests, then confirm these against a specific implementation (in my case Sun's 1.4.2). From mark@klomp.org Mon Jan 16 15:15:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Mon, 16 Jan 2006 15:15:00 -0000 Subject: Proposed Mauve test: childNodesLength In-Reply-To: <200601160047.59642.izecksohn@yahoo.com> References: <200601160047.59642.izecksohn@yahoo.com> Message-ID: <1137424497.8135.10.camel@localhost.localdomain> Hi Pedro, On Mon, 2006-01-16 at 00:47 -0400, Pedro Izecksohn wrote: > Two files are attached. Thanks! I have committed them as follows: 2006-01-16 Pedro Izecksohn * gnu/testlet/org/w3c/dom/childNodesLength.java: New test. * gnu/testlet/org/w3c/dom/test.xml: New data file. Of course a couple of these tests still fail against GNU Classpath dom implementation till we get your patch for that in. BTW. We are trying to setup the DOM test suites are at http://www.w3.org/DOM/Test/ We currently test against Level 3 Core (although we could test against Level 2 HTML and Level 3 Load and Save as well). See our current results at: http://builder.classpath.org/xml/dom.html It would be ideal if we can turn these tests into mauve like PASS/FAIL results. Then we can more easily create automatic regression reports with the existing scripts on builder.classpath.org. Maybe you are interesting at looking at the tests and the results (we still have a lot of failures there)? Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mark@klomp.org Tue Jan 17 08:08:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Tue, 17 Jan 2006 08:08:00 -0000 Subject: childNodesLength patch update Message-ID: <1137485325.8135.38.camel@localhost.localdomain> Hi, Pedro noticed that an old boolean variable was still used from an older revision of the test. This is not needed anymore. So here is the patch to remove it: 2006-01-17 Pedro Izecksohn * gnu/testlet/org/w3c/dom/childNodesLength.java (passed): Removed. (checkNode): Don't check passed variable. Committed, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: childNodesLength-passed.patch Type: text/x-patch Size: 1076 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From edwin.steiner@gmx.net Fri Jan 20 19:59:00 2006 From: edwin.steiner@gmx.net (Edwin Steiner) Date: Fri, 20 Jan 2006 19:59:00 -0000 Subject: misleading output "PASS: Error: ..." Message-ID: <20060120195947.GA8058@localhost.localdomain> Hallo! During my work with tgolem I found many lines in the mauve output like this: PASS: gnu.testlet.java.lang.Byte.ByteTest: Error: test_Basics failed - 1 (number 1) They are produced by such code: harness.check(!( Byte.MIN_VALUE != -128 ), "Error: test_Basics failed - 1" ); Would you accept patches turning this into harness.check(!( Byte.MIN_VALUE != -128 ), "test_Basics - 1" ); ? (Only changing the string. Changing the double negation seems too error prone for the many cases I found.) BTW I already promised patches for a similar problem. Unfortunately I had very little spare time recently. I hope this will get better now. Cheers, -Edwin From mark@klomp.org Sun Jan 22 17:50:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Sun, 22 Jan 2006 17:50:00 -0000 Subject: misleading output "PASS: Error: ..." In-Reply-To: <20060120195947.GA8058@localhost.localdomain> References: <20060120195947.GA8058@localhost.localdomain> Message-ID: <1137858855.4418.4.camel@localhost> Hi Edwin, On Fri, 2006-01-20 at 20:59 +0100, Edwin Steiner wrote: > During my work with tgolem I found many lines in the mauve output like > this: > > PASS: gnu.testlet.java.lang.Byte.ByteTest: Error: test_Basics failed - 1 (number 1) > > They are produced by such code: > > harness.check(!( Byte.MIN_VALUE != -128 ), > "Error: test_Basics failed - 1" ); > > Would you accept patches turning this into > > harness.check(!( Byte.MIN_VALUE != -128 ), > "test_Basics - 1" ); > > ? (Only changing the string. Changing the double negation seems too > error prone for the many cases I found.) Yes please! I have found these message strings confusing myself in the past. If you do decide to change the double negation then please rewrite these as actual checks: harness.check(Byte.MIN_VALUE, -128, "test_Basics - 1" ); That way one sees the expected value if the the test would ever fail. But just changing the message strings would already be an improvement. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From david.gilbert@object-refinery.com Tue Jan 31 21:32:00 2006 From: david.gilbert@object-refinery.com (David Gilbert) Date: Tue, 31 Jan 2006 21:32:00 -0000 Subject: Mauve / StatCVS (running free!) Message-ID: <43DFD8A6.8020103@object-refinery.com> Here is the latest StatCVS report showing excellent growth for Mauve: http://www.object-refinery.com/classpath/mauve/statcvs/ This report has been generated using JamVM, GNU Classpath, StatCVS, Cairo, the cairo-java bindings and a little bit of custom code - for details see: http://www.object-refinery.com/classpath/statcvs.html I'll be talking about this in an "end-user" talk at FOSDEM, and look forward to seeing some of you there. Regards, Dave From raif@swiftdsl.com.au Fri Feb 3 10:04:00 2006 From: raif@swiftdsl.com.au (Raif S. Naffah) Date: Fri, 03 Feb 2006 10:04:00 -0000 Subject: latest relocation of crypto tests Message-ID: <200602032107.07846.raif@swiftdsl.com.au> hello there, when i relocated the crypto tests from gnu/testlet/java[x] to gnu/testlet/gnu/java[x] (ChangeLog dated 2006-01-29) it seems that i forgot to commit the deletion of the old copies (in gnu/testlet/java[x]). i just committed the deletion now but had to do it in 3 consecutive steps. my apologies if this has caused any problems. cheers; rsn -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 216 bytes Desc: not available URL: From langel@redhat.com Fri Feb 3 16:29:00 2006 From: langel@redhat.com (Lillian Angel) Date: Fri, 03 Feb 2006 16:29:00 -0000 Subject: DefaultStyledDocument.ElementBuffer regressions Message-ID: <1138984187.5743.443.camel@tow.toronto.redhat.com> Hello, I submitted a final patch to Classpath to fix the ElementBuffer's structure. The structure is correct for all the mauve tests in gnu/testlet/javax/swing/text/DefaultStyledDocument/ElementBuffer. There are still some regressions that are showing up. These are caused because we are creating our elements differently than Sun (in a different order or more elements are being created). Overall, these should not be considered regressions, they should be changed to _just_ failures. They can be fixed later on. The important thing is that the structure is correct for ElementBuffer. Right now it works identical to Sun :) Thanks, Lillian From robilad@kaffe.org Sun Feb 12 18:25:00 2006 From: robilad@kaffe.org (Dalibor Topic) Date: Sun, 12 Feb 2006 18:25:00 -0000 Subject: FYI: New test for files with Unicode characters in name outside basic plane Message-ID: <1139768751.4899.1.camel@amy.domain.wg> Hi all, the test is attached. For Kaffe bug #16 and Classpath bug #26128. cheers, dalibor topic 2006-02-12 Dalibor Topic * gnu/testlet/java/io/File/UnicodeURI.java: New test for Files with Unicode characters above \u007F in names. -------------- next part -------------- A non-text attachment was scrubbed... Name: UnicodeURI.java Type: text/x-java Size: 2025 bytes Desc: not available URL: From izecksohn@yahoo.com Mon Feb 13 05:06:00 2006 From: izecksohn@yahoo.com (Pedro Izecksohn) Date: Mon, 13 Feb 2006 05:06:00 -0000 Subject: ResourceBundle Mauve test. Message-ID: <20060213050641.88047.qmail@web50112.mail.yahoo.com> gnu/testlet/java/util/ResourceBundle/getBundle.java: at lines 177 and 187: references to java.util.ResourceBundle.getBundle (String, null) is ambiguous at Sun's JDK 1.6, as there are the following two methods: getBundle(java.lang.String,java.util.Locale) getBundle(java.lang.String,java.util.ResourceBundle.Control) So it does not compile any more. Who fix this? (I did not try to fix it yet.) From izecksohn@yahoo.com Mon Feb 13 05:30:00 2006 From: izecksohn@yahoo.com (Pedro Izecksohn) Date: Mon, 13 Feb 2006 05:30:00 -0000 Subject: ResourceBundle Mauve test. In-Reply-To: <20060213050641.88047.qmail@web50112.mail.yahoo.com> Message-ID: <20060213053025.1079.qmail@web50102.mail.yahoo.com> Proposed fix: To add a (Locale) before both null appearances. As the .diff attached. What do you think about it? -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: getBundle.java.diff URL: From ddaney@avtrex.com Mon Feb 13 07:53:00 2006 From: ddaney@avtrex.com (David Daney) Date: Mon, 13 Feb 2006 07:53:00 -0000 Subject: ResourceBundle Mauve test. In-Reply-To: <20060213053025.1079.qmail@web50102.mail.yahoo.com> References: <20060213053025.1079.qmail@web50102.mail.yahoo.com> Message-ID: <43F03ACC.4020607@avtrex.com> Pedro Izecksohn wrote: > Proposed fix: To add a (Locale) before both null appearances. As the > .diff attached. > > What do you think about it? > I think it is correct. That is how I was going to recommend fixing it. > > ------------------------------------------------------------------------ > > --- getBundle.java~ 2006-02-13 07:14:14.000000000 +0000 > +++ getBundle.java 2006-02-13 07:14:14.000000000 +0000 > @@ -174,7 +174,7 @@ > > try > { > - ResourceBundle.getBundle (c ("Resource1"), null); > + ResourceBundle.getBundle (c ("Resource1"), (Locale)null); > harness.check (false); > } > catch (NullPointerException ex) > @@ -184,7 +184,7 @@ > > try > { > - ResourceBundle.getBundle ("no such resource", null); > + ResourceBundle.getBundle ("no such resource", (Locale)null); > harness.check (false); > } > catch (NullPointerException ex) From tromey@redhat.com Mon Feb 13 21:58:00 2006 From: tromey@redhat.com (Tom Tromey) Date: Mon, 13 Feb 2006 21:58:00 -0000 Subject: ResourceBundle Mauve test. In-Reply-To: <20060213053025.1079.qmail@web50102.mail.yahoo.com> References: <20060213053025.1079.qmail@web50102.mail.yahoo.com> Message-ID: >>>>> "Pedro" == Pedro Izecksohn writes: Pedro> Proposed fix: To add a (Locale) before both null appearances. As the Pedro> .diff attached. Pedro> What do you think about it? I checked it in. Thanks. Tom From izecksohn@yahoo.com Wed Feb 15 00:35:00 2006 From: izecksohn@yahoo.com (Pedro Izecksohn) Date: Wed, 15 Feb 2006 00:35:00 -0000 Subject: Generics, BigInteger. Message-ID: <20060215003529.49798.qmail@web50102.mail.yahoo.com> As it is known, gnu/testlet/java/math/BigInteger/compareTo.java does not compile with Generics. It is a useful test, even to Generics implementations, since it tests the library implementation, but Generics is forced by the compiler. To be able to compile it with all other tests, I was needed to change Makefile.am as the .diff attached. But I don't think it is good, as other compilers may not understand the -source option, and future tests may use some language feature not implemented at version 1.4. So I propose some kind of change, to compile tests separately, according to the language features used by them. But it is not urgent, and I did not imagine how to do it yet. gnu/testlet/java/math/BigInteger/compareTo.java: The tag JDK1.1 is wrong, according to http://java.sun.com/j2se/1.4.2/docs/api/java/math/BigInteger.html the method compareTo(Object) is there since version 1.2 . -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Makefile.am.diff URL: From stuart.a.ballard@gmail.com Thu Feb 16 15:55:00 2006 From: stuart.a.ballard@gmail.com (Stuart Ballard) Date: Thu, 16 Feb 2006 15:55:00 -0000 Subject: Mauve license Message-ID: (including the Classpath list as well as Mauve list here as I don't know how many people actually read the mauve list) Recently on the Harmony list there's been some discussion of how tests should be written and where they should be put. I chimed in pointing out what I thought would be a no-brainer - tests for public APIs should be in Mauve of course. I only just made that post and I haven't seen the responses yet, but it occurred to me to look and see what Mauve's license is just to make sure that wouldn't be a showstopper, and, well, as I'm sure many of you know, it's GPL. This is slightly strange to me. We (the Free Software community) are forced to make our own test suite because Sun won't release theirs under terms we can use, but when we do write our own, we put it under a license that prevents even other Free Software projects from working with it. Our test suite is under a stronger copyleft than Classpath itself is! I understand why we want Classpath itself to be copyleft. But what on earth benefit are we getting from preventing people from "proprietarizing" our testsuite? My understanding is that a license change could be difficult to effect at this point because I don't think a copyright assignment has been required for Mauve contributions and therefore there are probably a lot of copyright holders, some of whom may be difficult to track down. But if it *could* be managed (and if the Harmony hackers could be persuaded to put their tests there), I think it would be a major win for everybody. Mauve gets a bunch of new contributors (Harmony certainly seems to have a fair bit of momentum at this point) and code (I believe some of Harmony's big contributions came with test suites that could be integrated). Classpath and Harmony both get a bunch of new tests. Harmony hackers get to see that Classpath hackers aren't inflexible GPL-zealots, and both groups of hackers get used to working together on a project that benefits both. I don't think it's a coincidence that all the projects that originally collaborated on Mauve ended up combining their class libraries, either. Once people get used to working together, the level of collaboration can only go up from there... Stuart. PS I didn't include the Harmony list on this post mainly because my understanding is it's of absolutely no interest to them unless there *is* some way for Mauve to make this change. "GPL software is a nonstarter for us" is a quote I saw on the Harmony mailing list a couple of days ago... -- http://sab39.dev.netreach.com/ From audriusa@bluewin.ch Thu Feb 16 16:17:00 2006 From: audriusa@bluewin.ch (Audrius Meskauskas) Date: Thu, 16 Feb 2006 16:17:00 -0000 Subject: Mauve license: How with COST.OMG.ORG? In-Reply-To: References: Message-ID: <43F4A580.1080203@bluewin.ch> The packages for testing org.omg classes contain the source code from the currently the most probably dead cost.omg.org CORBA open source testing suite that was originally released under LGPL license. To integrate into Mauve, I of course needed to modify the code (the original test versions just prints messages to console). This means the license conversion into GPL. If we change the license, all such tests should probably be removed, and the Harmony project should also think about this. Event if they get the alternative CORBA implementation from somewhere else, it still needs a test suite to prevent degradation due subsequent develompent. cost.omg.org is written by several serious companies. I would take for me another year to write such thing from scratch, it is not much simplier than the implementation itself. The opponents of GPL license should think if they really want to reject this valuable resource as well. Audrius Meskauskas From david.gilbert@object-refinery.com Thu Feb 16 16:41:00 2006 From: david.gilbert@object-refinery.com (David Gilbert) Date: Thu, 16 Feb 2006 16:41:00 -0000 Subject: Mauve license In-Reply-To: References: Message-ID: <43F4AB1C.3000705@object-refinery.com> Stuart Ballard wrote: >(including the Classpath list as well as Mauve list here as I don't >know how many people actually read the mauve list) > >Recently on the Harmony list there's been some discussion of how tests >should be written and where they should be put. I chimed in pointing >out what I thought would be a no-brainer - tests for public APIs >should be in Mauve of course. > > Indeed. >I only just made that post and I haven't seen the responses yet, but >it occurred to me to look and see what Mauve's license is just to make >sure that wouldn't be a showstopper, and, well, as I'm sure many of >you know, it's GPL. > >This is slightly strange to me. We (the Free Software community) are >forced to make our own test suite because Sun won't release theirs >under terms we can use, but when we do write our own, we put it under >a license that prevents even other Free Software projects from working >with it. Our test suite is under a stronger copyleft than Classpath >itself is! > >I understand why we want Classpath itself to be copyleft. But what on >earth benefit are we getting from preventing people from >"proprietarizing" our testsuite? > > Free to use, free to redistribute, and since you'll never want to combine Mauve with anything else, I can't see why the GPL is considered a showstopper. >My understanding is that a license change could be difficult to effect >at this point because I don't think a copyright assignment has been >required for Mauve contributions and therefore there are probably a >lot of copyright holders, some of whom may be difficult to track down. >But if it *could* be managed (and if the Harmony hackers could be >persuaded to put their tests there), I think it would be a major win >for everybody. > > I think a more significant "problem" is practical: Mauve, which predates JUnit, uses its own test harness and Harmony is using JUnit. Integrating the two is a pile of work that you're not going to find anyone willing to spend time on. I think we should just accept that there are going to be two separate test suites, that will overlap in some places. It's not that big a deal in the scheme of things. >Mauve gets a bunch of new contributors (Harmony certainly seems to >have a fair bit of momentum at this point) and code (I believe some of >Harmony's big contributions came with test suites that could be >integrated). > >Classpath and Harmony both get a bunch of new tests. > > We have those tests now, just in separate places. Regards, Dave From aph@gcc.gnu.org Thu Feb 16 16:52:00 2006 From: aph@gcc.gnu.org (Andrew Haley) Date: Thu, 16 Feb 2006 16:52:00 -0000 Subject: Mauve license In-Reply-To: References: Message-ID: <17396.44584.791570.253834@zapata.pink> Stuart Ballard writes: > (including the Classpath list as well as Mauve list here as I don't > know how many people actually read the mauve list) > > Recently on the Harmony list there's been some discussion of how tests > should be written and where they should be put. I chimed in pointing > out what I thought would be a no-brainer - tests for public APIs > should be in Mauve of course. > > I only just made that post and I haven't seen the responses yet, but > it occurred to me to look and see what Mauve's license is just to make > sure that wouldn't be a showstopper, and, well, as I'm sure many of > you know, it's GPL. > > This is slightly strange to me. We (the Free Software community) are > forced to make our own test suite because Sun won't release theirs > under terms we can use, but when we do write our own, we put it under > a license that prevents even other Free Software projects from working > with it. Our test suite is under a stronger copyleft than Classpath > itself is! Err, we created Mauve with a GNU licence because we're GNU maintainers. Hard as it may seem to believe, some of us *like* the GPL. > I understand why we want Classpath itself to be copyleft. But what on > earth benefit are we getting from preventing people from > "proprietarizing" our testsuite? > > My understanding is that a license change could be difficult to effect > at this point because I don't think a copyright assignment has been > required for Mauve contributions and therefore there are probably a > lot of copyright holders, some of whom may be difficult to track down. > But if it *could* be managed (and if the Harmony hackers could be > persuaded to put their tests there), I think it would be a major win > for everybody. > > Mauve gets a bunch of new contributors (Harmony certainly seems to > have a fair bit of momentum at this point) and code (I believe some of > Harmony's big contributions came with test suites that could be > integrated). > > Classpath and Harmony both get a bunch of new tests. > > Harmony hackers get to see that Classpath hackers aren't inflexible > GPL-zealots, and both groups of hackers get used to working together > on a project that benefits both. > > I don't think it's a coincidence that all the projects that originally > collaborated on Mauve ended up combining their class libraries, > either. Once people get used to working together, the level of > collaboration can only go up from there... Sure. But in the case of a test suite, none of us could think of a reason not to use GPL. Andrew. From archie@dellroad.org Thu Feb 16 17:14:00 2006 From: archie@dellroad.org (Archie Cobbs) Date: Thu, 16 Feb 2006 17:14:00 -0000 Subject: Mauve license In-Reply-To: References: Message-ID: <43F4B2F9.9090801@dellroad.org> Stuart Ballard wrote: > Harmony hackers get to see that Classpath hackers aren't inflexible > GPL-zealots, and both groups of hackers get used to working together > on a project that benefits both. This Apache/Harmony thing vs. Claspath/GPL debate is just so tempting.. :-) But let's talk practicalities.. here's a simple thing I don't understand. What exactly prevents Harmony from using Mauve as a test suite? Would Apache want to create it's own copy of Mauve and check that into SVN? That seems like a bad idea -- i.e, creating a "code fork". So then if Apache only wants to run Mauve tests, what impact does Mauve being GPL have? Why can Apache folks just download Mauve and run it, the same way Classpath hackers do? Mauve is its own self-contained project. As to the issue of converting Mauve to JUnit, that's surely a lot of work any way you slice it, and in any case that seems like an orthogonal issue. -Archie __________________________________________________________________________ Archie Cobbs * CTO, Awarix * http://www.awarix.com From stuart.a.ballard@gmail.com Thu Feb 16 17:25:00 2006 From: stuart.a.ballard@gmail.com (Stuart Ballard) Date: Thu, 16 Feb 2006 17:25:00 -0000 Subject: Mauve license In-Reply-To: <43F4B2F9.9090801@dellroad.org> References: <43F4B2F9.9090801@dellroad.org> Message-ID: On 2/16/06, Archie Cobbs wrote: > This Apache/Harmony thing vs. Claspath/GPL debate is just so tempting.. :-) Heh. > But let's talk practicalities.. here's a simple thing I don't understand. > > What exactly prevents Harmony from using Mauve as a test suite? Nothing, and in fact I think they plan to do just that. But as I understand it their current plan is to use Mauve *in addition to* (and secondary to) their own test suite and only develop their own tests in their own repository. So we end up with two test suites being developed by two disjoint groups, both of whom are free to (and likely to) *run* the other group's suite against their own implementation, but still no actual cooperation. > So then if Apache only wants to run Mauve tests, what impact does Mauve > being GPL have? Why can Apache folks just download Mauve and run it, > the same way Classpath hackers do? Mauve is its own self-contained project. They can, but the Classpath hackers don't just run it, they write it too. Basically, I just don't see why Mauve *should* be GPL. There's absolutely no benefit in claiming copyleft on it and a considerable benefit from not doing so. Other than the issue of finding copyright holders, why *shouldn't* it be X11 or modified-BSD licensed so that anyone can use it as they see fit? I'm a GPL supporter in general but using it on a testsuite seems really wrong to me. > As to the issue of converting Mauve to JUnit, that's surely a lot of work > any way you slice it, and in any case that seems like an orthogonal issue. Yes, at this moment I'm only concerned with political issues. Technical issues are so much easier that they can be deferred for now ;) Stuart. -- http://sab39.dev.netreach.com/ From stuart.a.ballard@gmail.com Thu Feb 16 17:34:00 2006 From: stuart.a.ballard@gmail.com (Stuart Ballard) Date: Thu, 16 Feb 2006 17:34:00 -0000 Subject: Mauve license In-Reply-To: <43F4AB1C.3000705@object-refinery.com> References: <43F4AB1C.3000705@object-refinery.com> Message-ID: On 2/16/06, David Gilbert wrote: > Free to use, free to redistribute, and since you'll never want to > combine Mauve with anything else, I can't see why the GPL is considered > a showstopper. Politics don't have to make sense ;) The logical conclusion of your statements, though, is that the GPL isn't actually making any practical difference. And if that's the case, what's the point of using it? > I think a more significant "problem" is practical: Mauve, which > predates JUnit, uses its own test harness and Harmony is using JUnit. > Integrating the two is a pile of work that you're not going to find > anyone willing to spend time on. I think we should just accept that > there are going to be two separate test suites, that will overlap in > some places. It's not that big a deal in the scheme of things. AIUI currently you couldn't integrate the two if you wanted to because JUnit is under a non-GPL-compatible license. Another reason why a Mauve license change would be a benefit. From a practical point of view, if the license issues disappeared, it would presumably be easy enough to create a "junit" directory in mauve, have the mauve launcher scripts run both junit *and* the existing harness, pull the harmony tests into the new folder, everybody write new tests as junit tests, and gradually convert the old tests one-at-a-time over time. It wouldn't have to be a once-off "convert the world" operation. > We have those tests now, just in separate places. True. The current situation isn't a disaster. It would just be nice to get some cooperation in a place where, IMO, it clearly *does* make sense and the showstoppers seem to be entirely unnecessary. Stuart. -- http://sab39.dev.netreach.com/ From aph@redhat.com Thu Feb 16 17:35:00 2006 From: aph@redhat.com (Andrew Haley) Date: Thu, 16 Feb 2006 17:35:00 -0000 Subject: Mauve license In-Reply-To: References: <43F4B2F9.9090801@dellroad.org> Message-ID: <17396.47174.135058.560960@zapata.pink> I don't really understand your reasoning here. You haven't explained why all the usual reasons in favour of GPL don't apply to testsuites. Andrew. From archie@dellroad.org Thu Feb 16 17:40:00 2006 From: archie@dellroad.org (Archie Cobbs) Date: Thu, 16 Feb 2006 17:40:00 -0000 Subject: Mauve license In-Reply-To: References: <43F4B2F9.9090801@dellroad.org> Message-ID: <43F4B90E.9030209@dellroad.org> Stuart Ballard wrote: > But as I understand it their current plan is to use Mauve *in addition > to* (and secondary to) their own test suite and only develop their own > tests in their own repository. > > So we end up with two test suites being developed by two disjoint > groups, both of whom are free to (and likely to) *run* the other > group's suite against their own implementation, but still no actual > cooperation. This can make sense if the Harmony tests are Harmony-specific. Otherwise I don't see what the point is. > Basically, I just don't see why Mauve *should* be GPL. There's > absolutely no benefit in claiming copyleft on it and a considerable > benefit from not doing so. Other than the issue of finding copyright > holders, why *shouldn't* it be X11 or modified-BSD licensed so that > anyone can use it as they see fit? There may be no real reason it should be GPL, but in any case it is... so.. what's the problem with that? I mean, from a practical standpoint. But you seem also to be asking the religious question "why GPL"? Like most religious questions that one has no objective "answer".. If you really want to hear an "answer" then you can read the "official" one in the GPL FAQ... -Archie __________________________________________________________________________ Archie Cobbs * CTO, Awarix * http://www.awarix.com From stuart.a.ballard@gmail.com Thu Feb 16 17:51:00 2006 From: stuart.a.ballard@gmail.com (Stuart Ballard) Date: Thu, 16 Feb 2006 17:51:00 -0000 Subject: Mauve license In-Reply-To: <43F4B90E.9030209@dellroad.org> References: <43F4B2F9.9090801@dellroad.org> <43F4B90E.9030209@dellroad.org> Message-ID: On 2/16/06, Archie Cobbs wrote: > This can make sense if the Harmony tests are Harmony-specific. Some are, some aren't. They plan to have a separation between the two though. So Classpath will be able to use the non-specific part of Harmony's testsuite. > Otherwise I don't see what the point is. The point is that, for whatever reasons (rational or irrational), some people simply won't contribute to a GPL-licensed project. Some of those people are Harmony contributors. If those people want to contribute to a Java testsuite, which they do, it won't be Mauve as long as Mauve is GPL. > There may be no real reason it should be GPL, but in any case it is... > so.. what's the problem with that? I mean, from a practical standpoint. From a practical standpoint it's deterring a fairly large body of potential contributors... > But you seem also to be asking the religious question "why GPL"? Not at all. I like the GPL. I think the GPL-with-exception license of Classpath is the perfect license for what Classpath does. I use the GPL on almost all my own code (although I prefer the LGPL for things that are designed to be used as libraries). Even RMS points out that using non-copyleft licenses can be beneficial when it's a net gain for Free Software as a whole (eg Ogg). And in this case I think there is such a gain, because the GPL is buying us nothing (since there's no practical reason why anyone would *want* to take Mauve proprietary) but costing us contributors. I seem to be in a minority though, so I'll drop the issue I guess. Stuart. -- http://sab39.dev.netreach.com/ From aph@redhat.com Thu Feb 16 17:59:00 2006 From: aph@redhat.com (Andrew Haley) Date: Thu, 16 Feb 2006 17:59:00 -0000 Subject: Mauve license In-Reply-To: References: <43F4B2F9.9090801@dellroad.org> <43F4B90E.9030209@dellroad.org> Message-ID: <17396.48600.174009.756765@zapata.pink> Stuart Ballard writes: > > Even RMS points out that using non-copyleft licenses can be beneficial > when it's a net gain for Free Software as a whole (eg Ogg). > > And in this case I think there is such a gain, because the GPL is > buying us nothing (since there's no practical reason why anyone would > *want* to take Mauve proprietary) Oh, I see your meaning. > but costing us contributors. This part is the mystery. If, as you say, there's no practical reason why anyone would *want* to take Mauve proprietary, why does it matter that Mauve is GPL? > I seem to be in a minority though, so I'll drop the issue I guess. It's not that. I just don't understand. Andrew. From theBohemian@gmx.net Thu Feb 16 18:00:00 2006 From: theBohemian@gmx.net (Robert Schuster) Date: Thu, 16 Feb 2006 18:00:00 -0000 Subject: Mauve license In-Reply-To: <43F4B90E.9030209@dellroad.org> References: <43F4B2F9.9090801@dellroad.org> <43F4B90E.9030209@dellroad.org> Message-ID: <43F4BD80.6010201@gmx.net> Hi. > But you seem also to be asking the religious question "why GPL"? > Like most religious questions that one has no objective "answer".. I dont think that "why GPL" is a religious question. The one who asks deserves an answer and here is mine: > If you really want to hear an "answer" then you can read the "official" > one in the GPL FAQ... Not in the FAQ but clearly in this essay: http://www.gnu.org/philosophy/freedom-or-power.html How is that related to our testsuite? Users of Sun's TCK have to abide to certain rules: Eg. they are not allowed to talk about the results in detail and such things. I think Dalibor can explain this better as he seems to have a natural interest in Licensing Circuses. ;) Giving a testsuite away under a non-copylefted license allows others to implement such powers over their users. At least for me I am against giving someone this kind of freedom. Sorry. cya Robert -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From archie@dellroad.org Thu Feb 16 18:01:00 2006 From: archie@dellroad.org (Archie Cobbs) Date: Thu, 16 Feb 2006 18:01:00 -0000 Subject: Mauve license In-Reply-To: References: <43F4B2F9.9090801@dellroad.org> <43F4B90E.9030209@dellroad.org> Message-ID: <43F4BDF1.4030402@dellroad.org> Stuart Ballard wrote: > The point is that, for whatever reasons (rational or irrational), some > people simply won't contribute to a GPL-licensed project. Some of > those people are Harmony contributors. If those people want to > contribute to a Java testsuite, which they do, it won't be Mauve as > long as Mauve is GPL. Well then IMHO those people are the ones who are being "difficult" and putting politics over progress. Saying you won't contribute to a GPL project is more a political statement than the result of some reasonable decision-making process, because even if you do contribute to GPL software, you still own the copyright so you can also release your code under any other license you choose. Personally I don't love the GPL because it imposes more restrictions than a BSD style license (making, in my opinion, GPL software less free). But I respect others' religious beliefs. So if the GPL is not otherwise in the way, I have no problem working with it, etc. "Can't we all just get along?" :-) -Archie __________________________________________________________________________ Archie Cobbs * CTO, Awarix * http://www.awarix.com From stuart.a.ballard@gmail.com Thu Feb 16 18:19:00 2006 From: stuart.a.ballard@gmail.com (Stuart Ballard) Date: Thu, 16 Feb 2006 18:19:00 -0000 Subject: Mauve license In-Reply-To: References: <43F4B2F9.9090801@dellroad.org> <43F4B90E.9030209@dellroad.org> Message-ID: (this is going to show up in the wrong place in the thread - for some reason I can see mails showing up in the archives but I'm not receiving them myself till much later, so I don't have this one myself to respond to yet) Andrew Haley wrote: > > but costing us contributors. > > This part is the mystery. If, as you say, there's no practical reason > why anyone would *want* to take Mauve proprietary, why does it matter > that Mauve is GPL? There are quite a few reasons, some logical, some not, why people won't contribute to GPL projects. Some corporations have policies prohibiting employees from looking at GPL code. I don't believe there's any *good* reason for an organization to have such a policy, but some do. It appears there's at least one contributor on the Harmony list who is unable to look at Classpath code for this reason. Some corporations may have weaker policies that would still prohibit employees from actually writing GPL code on company time. Some people see the GPL as an endorsement of a political position they don't agree with and won't work on software licensed under it for that reason. Some people philosophically oppose the idea of copyleft and don't want their work under such a license. The Apache organization has policies against distributing GPL code and I believe also against requiring it as a dependency. (Even if everyone at Apache could be persuaded that changing this was a good idea, their procedures for doing so seem to take a while). A test suite isn't strictly a dependency but I think they'd at least have strong reservations against making it official policy that if you're writing tests for Harmony that test public APIs they should go in this GPL project. Another reason I feel test suites shouldn't be copyleft is similar to RMS's reasoning about Ogg: the greatest benefit to Free Software is obtained by having all implementations be compatible and compatible with the existing proprietary solution to help people escape the trap. The best way to achieve that is by getting good tests as widely disseminated and used as possible (analagous to getting Ogg support as widely used as possible to help people escape the mp3 trap). (another email I'm seeing in the archives but haven't received myself - Andrius's point about the OMG tests. I believe it should be possible to convert the license back to LGPL if we have permission from the copyright holders of all the code that was changed since, which would then mean that as long as the OMG tests are self-contained, they could be linked happily with a non-copyleft Mauve even if they themselves are still copyleft). Stuart. -- http://sab39.dev.netreach.com/ From audriusa@bluewin.ch Fri Feb 17 08:45:00 2006 From: audriusa@bluewin.ch (Audrius Meskauskas) Date: Fri, 17 Feb 2006 08:45:00 -0000 Subject: Mauve liscense:GPL 3? Message-ID: <43F58D08.5090307@bluewin.ch> Stupid idea this morning, but if the GPL 3 would be Apache compatible, maybe we could just show more intiative and merge the Java tests from THEY testing project? All we need is the JUnit adapter to Mauve that it is for sure possible to write. I was suggesting this idea long time ago. Audrius. From robilad@kaffe.org Sat Feb 18 16:57:00 2006 From: robilad@kaffe.org (Dalibor Topic) Date: Sat, 18 Feb 2006 16:57:00 -0000 Subject: Mauve liscense:GPL 3? In-Reply-To: <43F58D08.5090307@bluewin.ch> References: <43F58D08.5090307@bluewin.ch> Message-ID: <1140281844.4956.6.camel@amy.domain.wg> On Fri, 2006-02-17 at 09:44 +0100, Audrius Meskauskas wrote: > Stupid idea this morning, but if the GPL 3 would be Apache compatible, > maybe we could just show more intiative and merge the Java tests from > THEY testing project? All we need is the JUnit adapter to Mauve that it > is for sure possible to write. I was suggesting this idea long time ago. Sure, next year when the GPL3 is released, we could do that. cheers, dalibor topic From tromey@redhat.com Mon Feb 20 23:53:00 2006 From: tromey@redhat.com (Tom Tromey) Date: Mon, 20 Feb 2006 23:53:00 -0000 Subject: Mauve liscense:GPL 3? In-Reply-To: <1140281844.4956.6.camel@amy.domain.wg> References: <43F58D08.5090307@bluewin.ch> <1140281844.4956.6.camel@amy.domain.wg> Message-ID: <17402.21244.605800.963673@localhost.localdomain> >>>>> "Dalibor" == Dalibor Topic writes: Dalibor> On Fri, 2006-02-17 at 09:44 +0100, Audrius Meskauskas wrote: >> Stupid idea this morning, but if the GPL 3 would be Apache compatible, >> maybe we could just show more intiative and merge the Java tests from >> THEY testing project? All we need is the JUnit adapter to Mauve that it >> is for sure possible to write. I was suggesting this idea long time ago. Dalibor> Sure, next year when the GPL3 is released, we could do that. I'm not sure we even need that. Couldn't we have a single harness to run both sets of tests and distribute the result under a mixed license? Tom From tromey@redhat.com Tue Feb 21 00:09:00 2006 From: tromey@redhat.com (Tom Tromey) Date: Tue, 21 Feb 2006 00:09:00 -0000 Subject: Mauve license In-Reply-To: References: Message-ID: <17402.22192.931488.663308@localhost.localdomain> >>>>> "Stuart" == Stuart Ballard writes: Stuart> This is slightly strange to me. We (the Free Software community) are Stuart> forced to make our own test suite because Sun won't release theirs Stuart> under terms we can use, but when we do write our own, we put it under Stuart> a license that prevents even other Free Software projects from working Stuart> with it. Our test suite is under a stronger copyleft than Classpath Stuart> itself is! My recollection of our thinking, back when we started Mauve, was that surely the GPL would be fine, since nobody would be creating derived works and since we wanted the result to be free software. And, since we were heavily in the GNU world in those days, the default license was the GPL, and we saw no reason to change it. Of course we didn't anticipate today's weird world where people are working on free software but have an allergic reaction to the GPL, even for a package which has never had a release, and likely never will. Stuart> I understand why we want Classpath itself to be copyleft. But what on Stuart> earth benefit are we getting from preventing people from Stuart> "proprietarizing" our testsuite? I've actually had a query from a group that wanted to make a proprietary fork of mauve (after translating it to C++). Their plans didn't do much to induce me to want to change. Stuart> My understanding is that a license change could be difficult to effect Stuart> at this point because I don't think a copyright assignment has been Stuart> required for Mauve contributions and therefore there are probably a Stuart> lot of copyright holders, some of whom may be difficult to track down. Yes, I put the chances of this happening quite low. We've certainly had difficulty doing this with libffi, which is a much smaller project. Tom From robilad@kaffe.org Tue Feb 21 19:53:00 2006 From: robilad@kaffe.org (Dalibor Topic) Date: Tue, 21 Feb 2006 19:53:00 -0000 Subject: Mauve liscense:GPL 3? In-Reply-To: <17402.21244.605800.963673@localhost.localdomain> References: <43F58D08.5090307@bluewin.ch> <1140281844.4956.6.camel@amy.domain.wg> <17402.21244.605800.963673@localhost.localdomain> Message-ID: <1140551604.14397.2.camel@amy.domain.wg> On Tue, 2006-02-21 at 00:38 +0100, Tom Tromey wrote: > >>>>> "Dalibor" == Dalibor Topic writes: > > Dalibor> On Fri, 2006-02-17 at 09:44 +0100, Audrius Meskauskas wrote: > >> Stupid idea this morning, but if the GPL 3 would be Apache compatible, > >> maybe we could just show more intiative and merge the Java tests from > >> THEY testing project? All we need is the JUnit adapter to Mauve that it > >> is for sure possible to write. I was suggesting this idea long time ago. > > Dalibor> Sure, next year when the GPL3 is released, we could do that. > > I'm not sure we even need that. Couldn't we have a single harness to > run both sets of tests and distribute the result under a mixed > license? Uh ... sort of. You can have a harness that is both a) GPL-compatibly licensed and b) something-else-compatibly licensed, and distribute it as part of Mauve. GPL+linking exception would work well for anything, I think. cheers, dalibor topic From fitzsim@redhat.com Thu Feb 23 03:05:00 2006 From: fitzsim@redhat.com (Thomas Fitzsimmons) Date: Thu, 23 Feb 2006 03:05:00 -0000 Subject: FYI: new JFrame test Message-ID: <1140663923.1404.212.camel@tortoise.toronto.redhat.com> Hi, I committed this heavyweight-in-JFrame test. Tom 2006-02-22 Thomas Fitzsimmons * gnu/testlet/javax/swing/JFrame/HeavyweightComponent.java: New test. -------------- next part -------------- A non-text attachment was scrubbed... Name: mauve-jframe-heavyweight.patch Type: text/x-patch Size: 3050 bytes Desc: not available URL: From raif@swiftdsl.com.au Tue Feb 28 13:52:00 2006 From: raif@swiftdsl.com.au (Raif S. Naffah) Date: Tue, 28 Feb 2006 13:52:00 -0000 Subject: test with HTTPS url Message-ID: <200603010055.06417.raif@swiftdsl.com.au> hello all, i just checked in a new testlet (gnu.testlet.gnu.java.security.jce.TestOfHttps) that accesses the url https://www.paypal.com/ if there is a known https-accessible location that is/can be used for running such tests let me know and i'll amend the test accordingly. cheers; rsn -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 218 bytes Desc: not available URL: From mark@klomp.org Fri Mar 3 15:10:00 2006 From: mark@klomp.org (Mark Wielaard) Date: Fri, 03 Mar 2006 15:10:00 -0000 Subject: test with HTTPS url In-Reply-To: <200603010055.06417.raif@swiftdsl.com.au> References: <200603010055.06417.raif@swiftdsl.com.au> Message-ID: <1141398633.4959.69.camel@localhost.localdomain> Hi Raif, On Wed, 2006-03-01 at 00:54 +1100, Raif S. Naffah wrote: > i just checked in a new testlet > (gnu.testlet.gnu.java.security.jce.TestOfHttps) that accesses the url > > https://www.paypal.com/ > > if there is a known https-accessible location that is/can be used for > running such tests let me know and i'll amend the test accordingly. I think that is fine for now. We could install a https server on builder.classpath.org or maybe have something like Wolfgang just suggested a Mauve local https server. Three small comment on the test itself. - You seem to be using the eclipse templates. Not that it still contains a "FIXME: your info here" :) - It declares a GNU-CRYPTO Tag and explicitly installs the Jessie and GnuCrypto providers. But it really should just work for any JDK1.4 out of the box (and it actually does!) - It prints out all lines read to System.out. That isn't really necessary and obscures the output of the test. If you could correct those issue that would be great. Thanks, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From raif@swiftdsl.com.au Sat Mar 4 10:50:00 2006 From: raif@swiftdsl.com.au (Raif S. Naffah) Date: Sat, 04 Mar 2006 10:50:00 -0000 Subject: test with HTTPS url In-Reply-To: <1141398633.4959.69.camel@localhost.localdomain> References: <200603010055.06417.raif@swiftdsl.com.au> <1141398633.4959.69.camel@localhost.localdomain> Message-ID: <200603042153.46131.raif@swiftdsl.com.au> hello Mark, On Saturday 04 March 2006 02:10, Mark Wielaard wrote: > On Wed, 2006-03-01 at 00:54 +1100, Raif S. Naffah wrote: > > i just checked in a new testlet > > (gnu.testlet.gnu.java.security.jce.TestOfHttps) that accesses the > > url > > > > https://www.paypal.com/ > > > > if there is a known https-accessible location that is/can be used > > for running such tests let me know and i'll amend the test > > accordingly. > > I think that is fine for now. We could install a https server on > builder.classpath.org or maybe have something like Wolfgang just > suggested a Mauve local https server. > > Three small comment on the test itself. > - You seem to be using the eclipse templates. Not that it still > contains a "FIXME: your info here" :) noted. > - It declares a GNU-CRYPTO Tag and explicitly installs the Jessie and > GnuCrypto providers. But it really should just work for any JDK1.4 > out of the box (and it actually does!) it does with the JDK because the JDK contains export-controlled crypto. for us in Classpath to do that we would then break what A. Green asked for wrt. separating export-controlled from non-export-controlled crypto code. > - It prints out all lines read to System.out. That isn't really > necessary and obscures the output of the test. noted. > If you could correct those issue that would be great. i'm checking in a version that fixes the first and last issues. if we want to re-consider the export-controlled option let me know since we would have then to do more work in the Classpath tree before changing this testlet. cheers; rsn -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 218 bytes Desc: not available URL: From robilad@kaffe.org Mon Mar 6 01:18:00 2006 From: robilad@kaffe.org (Dalibor Topic) Date: Mon, 06 Mar 2006 01:18:00 -0000 Subject: FYI: another URI unicode test Message-ID: <1141611496.4923.10.camel@localhost> Hi all, I added another unicode URI test, and will check in the fix to Classpath soon. cheers, dalibor topic 2006-03-06 Dalibor Topic * gnu/testlet/java/net/URI/UnicodeURI.java: New file. -------------- next part -------------- A non-text attachment was scrubbed... Name: UnicodeURI.java Type: text/x-java Size: 1589 bytes Desc: not available URL: From david.gilbert@object-refinery.com Mon Mar 6 17:05:00 2006 From: david.gilbert@object-refinery.com (David Gilbert) Date: Mon, 06 Mar 2006 17:05:00 -0000 Subject: Running Mauve tests with JUnit Message-ID: <440C6BB8.90002@object-refinery.com> Hi All, A while back there was some discussion about converting Mauve tests to run under JUnit. I did some experimentation and have put together the following patch that shows one approach to making this work. I created a new JUnitRunnable class which makes it possible to run a Mauve testlet under JUnit (as well as continuing to support the standard Mauve runners). It requires that the existing testlets be modified to 'extend JUnitRunnable' (or, where this isn't possible, an alternative JUnitWrapper class can be used, see AttributeSetTests.java for an example). The patch includes conversion of the tests in the javax.swing.text.* package so you can at least try it out - if this patch is approved, I also have done the conversion of all the Swing tests (roughly 25% of Mauve I think). Here is a link to the patch, it's probably over the size limit for the mailing list (the ChangeLog entry is at the end of this e-mail): http://www.object-refinery.com/classpath/diff.txt I'm actually indifferent about whether or not this patch is accepted, I find Mauve slightly easier to work with relative to JUnit for the type of tests we write for GNU Classpath and plan to continue writing tests in the Mauve format. Anyway, here's the pros and cons that I can think of, please feel free to add to the list: Pros: - JUnit is integrated with Eclipse, so it can be used to run Mauve tests easily for developers that work in Eclipse; - most Java developers are familiar with JUnit, so Mauve may reach a wider audience; - other tools can work with JUnit (although I haven't used any of them - does anyone know of a JUnit runner that can produce comparisons of two runs? I'm interested in (a) regression reports (e.g. CVS vs last release) and (b) comparison reports (GNU Classpath vs Sun JDK1.5)); Cons: - a lot of work to modify the remaining tests in Mauve; - one extra step to make Mauve tests that run with both JUnit and Mauve test runners - it's pretty easy, but still a mental step that new contributors to Mauve will have to learn; - there is a possibility that some developers will write new tests against JUnit only, so we'll lose the ability to run all tests with the Mauve runners (which I think provide better detail on failures); Oh, and someone mentioned that the JUnit licence is not GPL compatible, so I compiled the tests against the GPLed code here: http://cvs.sourceforge.net/viewcvs.py/freenet/Contrib/junit/ I had to add a no-arg constructor for the TestCase class, then the tests compiled OK. And I can use the SimpleTestRunner to run a single test (this could do with some more work though). Please comment! Regards, Dave P.S. Here is the ChangeLog entry: 2006-03-06 David Gilbert * gnu/testlet/JUnitRunnable.java: New file, * gnu/testlet/JUnitTestHarness.java: Likewise, * gnu/testlet/JUnitTestWrapper.java: Likewise, * gnu/testlet/JUnitWrapper.java: Likewise, * gnu/testlet/javax/swing/text/PackageTestSuite.java: Likewise, * gnu/testlet/javax/swing/text/AbstractDocument/AbstractDocumentTest.java: Now extends JUnitRunnable, * gnu/testlet/javax/swing/text/AbstractDocument/AbstractDocumentTests.java: New file, * gnu/testlet/javax/swing/text/AbstractDocument/ElementChange.java: Now extends JUnitRunnable, * gnu/testlet/javax/swing/text/AbstractDocument/ElementChange2.java: Likewise, * gnu/testlet/javax/swing/text/AbstractDocument/BranchElement/BranchElementTest.java: Updated header, * gnu/testlet/javax/swing/text/AbstractDocument/BranchElement/BranchElementTests.java: New file, * gnu/testlet/javax/swing/text/AbstractDocument/BranchElement/getElementIndexNullPointer.java: Now extends JUnitRunnable, * gnu/testlet/javax/swing/text/AttributeSet/AttributeSetTests.java: New file, * gnu/testlet/javax/swing/text/BoxView/BoxViewTests.java: Likewise, * gnu/testlet/javax/swing/text/BoxView/spans.java: Now extends JUnitRunnable, * gnu/testlet/javax/swing/text/DefaultEditorKit/DefaultEditorKitTests.java: New file, * gnu/testlet/javax/swing/text/DefaultEditorKit/getActions.java: Now extends JUnitRunnable, * gnu/testlet/javax/swing/text/DefaultFormatter/DefaultFormatterTests.java: New file, * gnu/testlet/javax/swing/text/DefaultFormatter/getValueClass.java: Now extends JUnitRunnable, * gnu/testlet/javax/swing/text/DefaultStyledDocument/DefaultStyledDocumentTests.java: New file, * gnu/testlet/javax/swing/text/DefaultStyledDocument/insertString.java: Now extends JUnitRunnable, * gnu/testlet/javax/swing/text/DefaultStyledDocument/ElementBuffer/ElementBufferTests.java: New file, * gnu/testlet/javax/swing/text/DefaultStyledDocument/ElementBuffer/insert.java: Now extends JUnitRunnable, * gnu/testlet/javax/swing/text/ElementIterator/ElementIteratorTest.java: Likewise, * gnu/testlet/javax/swing/text/ElementIterator/ElementIteratorTests.java: New file, * gnu/testlet/javax/swing/text/FlowView/FlowViewTests.java: New file, * gnu/testlet/javax/swing/text/FlowView/getFlowAxis.java: Now extends JUnitRunnable, * gnu/testlet/javax/swing/text/GapContent/GapContentTest.java: Likewise, * gnu/testlet/javax/swing/text/GapContent/GapContentTests.java: New file, * gnu/testlet/javax/swing/text/GapContent/PositionTest.java: Now extends JUnitRunnable, * gnu/testlet/javax/swing/text/GapContent/constructors.java: Likewise, * gnu/testlet/javax/swing/text/GapContent/createPosition.java: Likewise, * gnu/testlet/javax/swing/text/GapContent/getChars.java: Likewise, * gnu/testlet/javax/swing/text/GapContent/getString.java: Likewise, * gnu/testlet/javax/swing/text/GapContent/insertString.java: Likewise, * gnu/testlet/javax/swing/text/GapContent/length.java: Likewise, * gnu/testlet/javax/swing/text/GapContent/remove.java: Likewise, * gnu/testlet/javax/swing/text/InternationalFormatter/InternationalFormatterTest.java: Likewise, * gnu/testlet/javax/swing/text/InternationalFormatter/InternationalFormatterTests.java: New file, * gnu/testlet/javax/swing/text/MaskFormatter/MaskFormatterTest.java: Now extends JUnitRunnable, * gnu/testlet/javax/swing/text/MaskFormatter/MaskFormatterTests.java: New file, * gnu/testlet/javax/swing/text/PlainDocument/PlainDocumentTest.java: Now extends JUnitRunnable, * gnu/testlet/javax/swing/text/PlainDocument/PlainDocumentTests.java: New file, * gnu/testlet/javax/swing/text/PlainDocument/createPosition.java: Now extends JUnitRunnable, * gnu/testlet/javax/swing/text/PlainDocument/getLength.java: Likewise, * gnu/testlet/javax/swing/text/PlainDocument/getRootElements.java: Likewise, * gnu/testlet/javax/swing/text/PlainDocument/getText.java: Likewise, * gnu/testlet/javax/swing/text/PlainDocument/insertString.java: Likewise, * gnu/testlet/javax/swing/text/PlainDocument/multipleLeafs.java: Likewise, * gnu/testlet/javax/swing/text/PlainDocument/remove.java: Likewise, * gnu/testlet/javax/swing/text/PlainDocument/removeJoinesLines.java: Likewise, * gnu/testlet/javax/swing/text/Segment/SegmentTests.java: New file, * gnu/testlet/javax/swing/text/Segment/clone.java: Now extends JUnitRunnable, * gnu/testlet/javax/swing/text/Segment/constructors.java: Likewise, * gnu/testlet/javax/swing/text/Segment/first.java: Likewise, * gnu/testlet/javax/swing/text/Segment/getBeginIndex.java: Likewise, * gnu/testlet/javax/swing/text/Segment/getEndIndex.java: Likewise, * gnu/testlet/javax/swing/text/Segment/getIndex.java: Likewise, * gnu/testlet/javax/swing/text/Segment/isPartialReturn.java: Likewise, * gnu/testlet/javax/swing/text/Segment/last.java: Likewise, * gnu/testlet/javax/swing/text/Segment/next.java: Likewise, * gnu/testlet/javax/swing/text/Segment/previous.java: Likewise, * gnu/testlet/javax/swing/text/Segment/setIndex.java: Likewise, * gnu/testlet/javax/swing/text/Segment/setPartialReturn.java: Likewise, * gnu/testlet/javax/swing/text/Segment/toString(), Likewise, * gnu/testlet/javax/swing/text/SimpleAttributeSet/SimpleAttributeSetTests.java: New file, * gnu/testlet/javax/swing/text/StringContent/BadLocationExceptionTest.java: Now extends JUnitRunnable, * gnu/testlet/javax/swing/text/StringContent/StringContentTest.java: Likewise, * gnu/testlet/javax/swing/text/StringContent/StringContentTests.java: New file, * gnu/testlet/javax/swing/text/StringContent/constructors.java: Now extends JUnitRunnable, * gnu/testlet/javax/swing/text/StringContent/createPosition.java: Likewise, * gnu/testlet/javax/swing/text/StringContent/getChars.java: Likewise, * gnu/testlet/javax/swing/text/StringContent/getString.java: Likewise, * gnu/testlet/javax/swing/text/StringContent/insertString.java: Likewise, * gnu/testlet/javax/swing/text/StringContent/insertUndo.java: Likewise, * gnu/testlet/javax/swing/text/StringContent/length.java: Likewise, * gnu/testlet/javax/swing/text/StringContent/remove.java: Likewise, * gnu/testlet/javax/swing/text/StringContent/removeUndo.java: Likewise, * gnu/testlet/javax/swing/text/StringContent/stickyPosition.java: Likewise, * gnu/testlet/javax/swing/text/StyleConstants/StyleConstantsTests.java: New file, * gnu/testlet/javax/swing/text/StyleConstants/constants.java: Now extends JUnitRunnable, * gnu/testlet/javax/swing/text/StyleConstants/getAlignment.java: Likewise, * gnu/testlet/javax/swing/text/StyleConstants/getBackground.java: Likewise, * gnu/testlet/javax/swing/text/StyleConstants/getBidiLevel.java: Likewise, * gnu/testlet/javax/swing/text/StyleConstants/getComponent.java: Likewise, * gnu/testlet/javax/swing/text/StyleConstants/getFirstLineIndent.java: Likewise, * gnu/testlet/javax/swing/text/StyleConstants/getFontFamily.java: Liekwise, * gnu/testlet/javax/swing/text/StyleConstants/getFontSize.java: Likewise, * gnu/testlet/javax/swing/text/StyleConstants/getForeground.java: Likewise, * gnu/testlet/javax/swing/text/StyleConstants/getIcon.java: Likewise, * gnu/testlet/javax/swing/text/StyleConstants/getLeftIndent.java: Likewise, * gnu/testlet/javax/swing/text/StyleConstants/getLineSpacing.java: Likewise, * gnu/testlet/javax/swing/text/StyleConstants/getRightIndent.java: Likewise, * gnu/testlet/javax/swing/text/StyleConstants/getSpaceAbove.java: Likewise, * gnu/testlet/javax/swing/text/StyleConstants/getSpaceBelow.java: Likewise, * gnu/testlet/javax/swing/text/StyleConstants/getTabSet.java: Likewise, * gnu/testlet/javax/swing/text/StyleConstants/isBold.java: Likewise, * gnu/testlet/javax/swing/text/StyleConstants/isItalic.java: Likewise, * gnu/testlet/javax/swing/text/StyleConstants/isStrikeThrough.java: Likewise, * gnu/testlet/javax/swing/text/StyleConstants/isSubscript.java: Likewise, * gnu/testlet/javax/swing/text/StyleConstants/isSuperscript.java: Likewise, * gnu/testlet/javax/swing/text/StyleConstants/isUnderline.java: Likewise, * gnu/testlet/javax/swing/text/StyleConstants/setAlignment.java: Likewise, * gnu/testlet/javax/swing/text/StyleConstants/setBackground.java: Likewise, * gnu/testlet/javax/swing/text/StyleConstants/setBidiLevel.java: Likewise, * gnu/testlet/javax/swing/text/StyleConstants/setBold.java: Likewise, * gnu/testlet/javax/swing/text/StyleConstants/setComponent.java: Likewise, * gnu/testlet/javax/swing/text/StyleConstants/setFirstLineIndent.java: Likewise, * gnu/testlet/javax/swing/text/StyleConstants/setFontFamily.java: Likewise, * gnu/testlet/javax/swing/text/StyleConstants/setFontSize.java: Likewise, * gnu/testlet/javax/swing/text/StyleConstants/setForeground.java: Likewise, * gnu/testlet/javax/swing/text/StyleConstants/setIcon.java: Likewise, * gnu/testlet/javax/swing/text/StyleConstants/setItalic.java: Likewise, * gnu/testlet/javax/swing/text/StyleConstants/setLeftIndent.java: Likewise, * gnu/testlet/javax/swing/text/StyleConstants/setLineSpacing.java: Likewise, * gnu/testlet/javax/swing/text/StyleConstants/setRightIndent.java: Likewise, * gnu/testlet/javax/swing/text/StyleConstants/setSpaceAbove.java: Likewise, * gnu/testlet/javax/swing/text/StyleConstants/setSpaceBelow.java: Likewise, * gnu/testlet/javax/swing/text/StyleConstants/setStrikeThrough.java: Likewise, * gnu/testlet/javax/swing/text/StyleConstants/setSubscript.java: Likewise, * gnu/testlet/javax/swing/text/StyleConstants/setSuperscript.java: Likewise, * gnu/testlet/javax/swing/text/StyleConstants/setTabSet.java: Likewise, * gnu/testlet/javax/swing/text/StyleConstants/setUnderline.java: Likewise, * gnu/testlet/javax/swing/text/StyleContext/NamedStyleInit.java: Likewise, * gnu/testlet/javax/swing/text/StyleContext/NamedStyleSetResolveParent.java: Likewise, * gnu/testlet/javax/swing/text/StyleContext/StyleContextTests.java: New file, * gnu/testlet/javax/swing/text/StyleContext/addAttribute.java: Now extends JUnitRunnable, * gnu/testlet/javax/swing/text/StyleContext/addStyle.java: Likewise, * gnu/testlet/javax/swing/text/StyledEditorKit/StyledEditorKitTests.java: New file, * gnu/testlet/javax/swing/text/StyledEditorKit/createInputAttributesTest.java: Now extends JUnitRunnable, * gnu/testlet/javax/swing/text/TextAction/TextActionTests.java: New file, * gnu/testlet/javax/swing/text/TextAction/augmentList.java: Now extends JUnitRunnable, * gnu/testlet/javax/swing/text/View/ViewTests.java: New file, * gnu/testlet/javax/swing/text/View/getAlignment.java: Now extends JUnitRunnable, * gnu/testlet/javax/swing/text/View/getMaximumSpan.java: Likewise, * gnu/testlet/javax/swing/text/View/getMinimumSpan.java: Likewise, * gnu/testlet/javax/swing/text/View/getResizeWeight.java: Likewise. From konqueror@gmx.de Tue Mar 7 18:34:00 2006 From: konqueror@gmx.de (Michael Koch) Date: Tue, 07 Mar 2006 18:34:00 -0000 Subject: Java 5 features Message-ID: <20060307193846.GL18158@asterix.konqueror.de> Hello people, What is the state of support for the Java 5 language features in Mauve? Is it okay to use Generics and Enums and such stuff in testcases that are tagged "1.5"? I would like to commit some testcases that use Generics and Enums to test some stuff in GNU classpath generics branch. What's your opinion? Cheers, Michael -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ From david.gilbert@object-refinery.com Wed Mar 8 10:40:00 2006 From: david.gilbert@object-refinery.com (David Gilbert) Date: Wed, 08 Mar 2006 10:40:00 -0000 Subject: Running Mauve tests with JUnit In-Reply-To: <440C6BB8.90002@object-refinery.com> References: <440C6BB8.90002@object-refinery.com> Message-ID: <440EB4B7.1020709@object-refinery.com> I didn't get any feedback about this...anyone think it is a good/bad idea? Regards, Dave David Gilbert wrote: > Hi All, > > A while back there was some discussion about converting Mauve tests to > run under JUnit. I did some experimentation and have put together the > following patch that shows one approach to making this work. I > created a new JUnitRunnable class which makes it possible to run a > Mauve testlet under JUnit (as well as continuing to support the > standard Mauve runners). It requires that the existing testlets be > modified to 'extend JUnitRunnable' (or, where this isn't possible, an > alternative JUnitWrapper class can be used, see AttributeSetTests.java > for an example). The patch includes conversion of the tests in the > javax.swing.text.* package so you can at least try it out - if this > patch is approved, I also have done the conversion of all the Swing > tests (roughly 25% of Mauve I think). > > Here is a link to the patch, it's probably over the size limit for the > mailing list (the ChangeLog entry is at the end of this e-mail): > > http://www.object-refinery.com/classpath/diff.txt > > I'm actually indifferent about whether or not this patch is accepted, > I find Mauve slightly easier to work with relative to JUnit for the > type of tests we write for GNU Classpath and plan to continue writing > tests in the Mauve format. Anyway, here's the pros and cons that I > can think of, please feel free to add to the list: > > Pros: > - JUnit is integrated with Eclipse, so it can be used to run Mauve > tests easily for developers that work in Eclipse; > - most Java developers are familiar with JUnit, so Mauve may reach a > wider audience; > - other tools can work with JUnit (although I haven't used any of them > - does anyone know of a JUnit runner that can produce comparisons of > two runs? I'm interested in (a) regression reports (e.g. CVS vs last > release) and (b) comparison reports (GNU Classpath vs Sun JDK1.5)); > > Cons: > - a lot of work to modify the remaining tests in Mauve; > - one extra step to make Mauve tests that run with both JUnit and > Mauve test runners - it's pretty easy, but still a mental step that > new contributors to Mauve will have to learn; > - there is a possibility that some developers will write new tests > against JUnit only, so we'll lose the ability to run all tests with > the Mauve runners (which I think provide better detail on failures); > > Oh, and someone mentioned that the JUnit licence is not GPL > compatible, so I compiled the tests against the GPLed code here: > > http://cvs.sourceforge.net/viewcvs.py/freenet/Contrib/junit/ > > I had to add a no-arg constructor for the TestCase class, then the > tests compiled OK. And I can use the SimpleTestRunner to run a single > test (this could do with some more work though). > > Please comment! > > Regards, > > Dave > > P.S. Here is the ChangeLog entry: > > 2006-03-06 David Gilbert > > * gnu/testlet/JUnitRunnable.java: New file, > * gnu/testlet/JUnitTestHarness.java: Likewise, > * gnu/testlet/JUnitTestWrapper.java: Likewise, > * gnu/testlet/JUnitWrapper.java: Likewise, > * gnu/testlet/javax/swing/text/PackageTestSuite.java: Likewise, > * > gnu/testlet/javax/swing/text/AbstractDocument/AbstractDocumentTest.java: > Now extends JUnitRunnable, > * > gnu/testlet/javax/swing/text/AbstractDocument/AbstractDocumentTests.java: > New file, > * gnu/testlet/javax/swing/text/AbstractDocument/ElementChange.java: > Now extends JUnitRunnable, > * > gnu/testlet/javax/swing/text/AbstractDocument/ElementChange2.java: > Likewise, > * > gnu/testlet/javax/swing/text/AbstractDocument/BranchElement/BranchElementTest.java: > Updated header, > * > gnu/testlet/javax/swing/text/AbstractDocument/BranchElement/BranchElementTests.java: > New file, > * > gnu/testlet/javax/swing/text/AbstractDocument/BranchElement/getElementIndexNullPointer.java: > Now extends JUnitRunnable, > * gnu/testlet/javax/swing/text/AttributeSet/AttributeSetTests.java: > New file, > * gnu/testlet/javax/swing/text/BoxView/BoxViewTests.java: Likewise, > * gnu/testlet/javax/swing/text/BoxView/spans.java: Now extends > JUnitRunnable, > * > gnu/testlet/javax/swing/text/DefaultEditorKit/DefaultEditorKitTests.java: > New file, > * gnu/testlet/javax/swing/text/DefaultEditorKit/getActions.java: > Now extends JUnitRunnable, > * > gnu/testlet/javax/swing/text/DefaultFormatter/DefaultFormatterTests.java: > New file, > * gnu/testlet/javax/swing/text/DefaultFormatter/getValueClass.java: > Now extends JUnitRunnable, > * > gnu/testlet/javax/swing/text/DefaultStyledDocument/DefaultStyledDocumentTests.java: > New file, > * > gnu/testlet/javax/swing/text/DefaultStyledDocument/insertString.java: > Now extends JUnitRunnable, > * > gnu/testlet/javax/swing/text/DefaultStyledDocument/ElementBuffer/ElementBufferTests.java: > New file, > * > gnu/testlet/javax/swing/text/DefaultStyledDocument/ElementBuffer/insert.java: > Now extends JUnitRunnable, > * > gnu/testlet/javax/swing/text/ElementIterator/ElementIteratorTest.java: > Likewise, > * > gnu/testlet/javax/swing/text/ElementIterator/ElementIteratorTests.java: > New file, > * gnu/testlet/javax/swing/text/FlowView/FlowViewTests.java: New file, > * gnu/testlet/javax/swing/text/FlowView/getFlowAxis.java: Now > extends JUnitRunnable, > * gnu/testlet/javax/swing/text/GapContent/GapContentTest.java: > Likewise, > * gnu/testlet/javax/swing/text/GapContent/GapContentTests.java: New > file, > * gnu/testlet/javax/swing/text/GapContent/PositionTest.java: Now > extends JUnitRunnable, > * gnu/testlet/javax/swing/text/GapContent/constructors.java: Likewise, > * gnu/testlet/javax/swing/text/GapContent/createPosition.java: > Likewise, > * gnu/testlet/javax/swing/text/GapContent/getChars.java: Likewise, > * gnu/testlet/javax/swing/text/GapContent/getString.java: Likewise, > * gnu/testlet/javax/swing/text/GapContent/insertString.java: Likewise, > * gnu/testlet/javax/swing/text/GapContent/length.java: Likewise, > * gnu/testlet/javax/swing/text/GapContent/remove.java: Likewise, > * > gnu/testlet/javax/swing/text/InternationalFormatter/InternationalFormatterTest.java: > Likewise, > * > gnu/testlet/javax/swing/text/InternationalFormatter/InternationalFormatterTests.java: > New file, > * > gnu/testlet/javax/swing/text/MaskFormatter/MaskFormatterTest.java: Now > extends JUnitRunnable, > * > gnu/testlet/javax/swing/text/MaskFormatter/MaskFormatterTests.java: > New file, > * > gnu/testlet/javax/swing/text/PlainDocument/PlainDocumentTest.java: Now > extends JUnitRunnable, > * > gnu/testlet/javax/swing/text/PlainDocument/PlainDocumentTests.java: > New file, > * gnu/testlet/javax/swing/text/PlainDocument/createPosition.java: > Now extends JUnitRunnable, > * gnu/testlet/javax/swing/text/PlainDocument/getLength.java: Likewise, > * gnu/testlet/javax/swing/text/PlainDocument/getRootElements.java: > Likewise, > * gnu/testlet/javax/swing/text/PlainDocument/getText.java: Likewise, > * gnu/testlet/javax/swing/text/PlainDocument/insertString.java: > Likewise, > * gnu/testlet/javax/swing/text/PlainDocument/multipleLeafs.java: > Likewise, > * gnu/testlet/javax/swing/text/PlainDocument/remove.java: Likewise, > * > gnu/testlet/javax/swing/text/PlainDocument/removeJoinesLines.java: > Likewise, > * gnu/testlet/javax/swing/text/Segment/SegmentTests.java: New file, > * gnu/testlet/javax/swing/text/Segment/clone.java: Now extends > JUnitRunnable, > * gnu/testlet/javax/swing/text/Segment/constructors.java: Likewise, > * gnu/testlet/javax/swing/text/Segment/first.java: Likewise, > * gnu/testlet/javax/swing/text/Segment/getBeginIndex.java: Likewise, > * gnu/testlet/javax/swing/text/Segment/getEndIndex.java: Likewise, > * gnu/testlet/javax/swing/text/Segment/getIndex.java: Likewise, > * gnu/testlet/javax/swing/text/Segment/isPartialReturn.java: Likewise, > * gnu/testlet/javax/swing/text/Segment/last.java: Likewise, > * gnu/testlet/javax/swing/text/Segment/next.java: Likewise, > * gnu/testlet/javax/swing/text/Segment/previous.java: Likewise, > * gnu/testlet/javax/swing/text/Segment/setIndex.java: Likewise, > * gnu/testlet/javax/swing/text/Segment/setPartialReturn.java: > Likewise, > * gnu/testlet/javax/swing/text/Segment/toString(), Likewise, > * > gnu/testlet/javax/swing/text/SimpleAttributeSet/SimpleAttributeSetTests.java: > New file, > * > gnu/testlet/javax/swing/text/StringContent/BadLocationExceptionTest.java: > Now extends JUnitRunnable, > * > gnu/testlet/javax/swing/text/StringContent/StringContentTest.java: > Likewise, > * > gnu/testlet/javax/swing/text/StringContent/StringContentTests.java: > New file, > * gnu/testlet/javax/swing/text/StringContent/constructors.java: Now > extends JUnitRunnable, > * gnu/testlet/javax/swing/text/StringContent/createPosition.java: > Likewise, > * gnu/testlet/javax/swing/text/StringContent/getChars.java: Likewise, > * gnu/testlet/javax/swing/text/StringContent/getString.java: Likewise, > * gnu/testlet/javax/swing/text/StringContent/insertString.java: > Likewise, > * gnu/testlet/javax/swing/text/StringContent/insertUndo.java: > Likewise, > * gnu/testlet/javax/swing/text/StringContent/length.java: Likewise, > * gnu/testlet/javax/swing/text/StringContent/remove.java: Likewise, > * gnu/testlet/javax/swing/text/StringContent/removeUndo.java: > Likewise, > * gnu/testlet/javax/swing/text/StringContent/stickyPosition.java: > Likewise, > * > gnu/testlet/javax/swing/text/StyleConstants/StyleConstantsTests.java: > New file, > * gnu/testlet/javax/swing/text/StyleConstants/constants.java: Now > extends JUnitRunnable, > * gnu/testlet/javax/swing/text/StyleConstants/getAlignment.java: > Likewise, > * gnu/testlet/javax/swing/text/StyleConstants/getBackground.java: > Likewise, > * gnu/testlet/javax/swing/text/StyleConstants/getBidiLevel.java: > Likewise, > * gnu/testlet/javax/swing/text/StyleConstants/getComponent.java: > Likewise, > * > gnu/testlet/javax/swing/text/StyleConstants/getFirstLineIndent.java: > Likewise, > * gnu/testlet/javax/swing/text/StyleConstants/getFontFamily.java: > Liekwise, > * gnu/testlet/javax/swing/text/StyleConstants/getFontSize.java: > Likewise, > * gnu/testlet/javax/swing/text/StyleConstants/getForeground.java: > Likewise, > * gnu/testlet/javax/swing/text/StyleConstants/getIcon.java: Likewise, > * gnu/testlet/javax/swing/text/StyleConstants/getLeftIndent.java: > Likewise, > * gnu/testlet/javax/swing/text/StyleConstants/getLineSpacing.java: > Likewise, > * gnu/testlet/javax/swing/text/StyleConstants/getRightIndent.java: > Likewise, > * gnu/testlet/javax/swing/text/StyleConstants/getSpaceAbove.java: > Likewise, > * gnu/testlet/javax/swing/text/StyleConstants/getSpaceBelow.java: > Likewise, > * gnu/testlet/javax/swing/text/StyleConstants/getTabSet.java: > Likewise, > * gnu/testlet/javax/swing/text/StyleConstants/isBold.java: Likewise, > * gnu/testlet/javax/swing/text/StyleConstants/isItalic.java: Likewise, > * gnu/testlet/javax/swing/text/StyleConstants/isStrikeThrough.java: > Likewise, > * gnu/testlet/javax/swing/text/StyleConstants/isSubscript.java: > Likewise, > * gnu/testlet/javax/swing/text/StyleConstants/isSuperscript.java: > Likewise, > * gnu/testlet/javax/swing/text/StyleConstants/isUnderline.java: > Likewise, > * gnu/testlet/javax/swing/text/StyleConstants/setAlignment.java: > Likewise, > * gnu/testlet/javax/swing/text/StyleConstants/setBackground.java: > Likewise, > * gnu/testlet/javax/swing/text/StyleConstants/setBidiLevel.java: > Likewise, > * gnu/testlet/javax/swing/text/StyleConstants/setBold.java: Likewise, > * gnu/testlet/javax/swing/text/StyleConstants/setComponent.java: > Likewise, > * > gnu/testlet/javax/swing/text/StyleConstants/setFirstLineIndent.java: > Likewise, > * gnu/testlet/javax/swing/text/StyleConstants/setFontFamily.java: > Likewise, > * gnu/testlet/javax/swing/text/StyleConstants/setFontSize.java: > Likewise, > * gnu/testlet/javax/swing/text/StyleConstants/setForeground.java: > Likewise, > * gnu/testlet/javax/swing/text/StyleConstants/setIcon.java: Likewise, > * gnu/testlet/javax/swing/text/StyleConstants/setItalic.java: > Likewise, > * gnu/testlet/javax/swing/text/StyleConstants/setLeftIndent.java: > Likewise, > * gnu/testlet/javax/swing/text/StyleConstants/setLineSpacing.java: > Likewise, > * gnu/testlet/javax/swing/text/StyleConstants/setRightIndent.java: > Likewise, > * gnu/testlet/javax/swing/text/StyleConstants/setSpaceAbove.java: > Likewise, > * gnu/testlet/javax/swing/text/StyleConstants/setSpaceBelow.java: > Likewise, > * > gnu/testlet/javax/swing/text/StyleConstants/setStrikeThrough.java: > Likewise, > * gnu/testlet/javax/swing/text/StyleConstants/setSubscript.java: > Likewise, > * gnu/testlet/javax/swing/text/StyleConstants/setSuperscript.java: > Likewise, > * gnu/testlet/javax/swing/text/StyleConstants/setTabSet.java: > Likewise, > * gnu/testlet/javax/swing/text/StyleConstants/setUnderline.java: > Likewise, > * gnu/testlet/javax/swing/text/StyleContext/NamedStyleInit.java: > Likewise, > * > gnu/testlet/javax/swing/text/StyleContext/NamedStyleSetResolveParent.java: > Likewise, > * gnu/testlet/javax/swing/text/StyleContext/StyleContextTests.java: > New file, > * gnu/testlet/javax/swing/text/StyleContext/addAttribute.java: Now > extends JUnitRunnable, > * gnu/testlet/javax/swing/text/StyleContext/addStyle.java: Likewise, > * > gnu/testlet/javax/swing/text/StyledEditorKit/StyledEditorKitTests.java: > New file, > * > gnu/testlet/javax/swing/text/StyledEditorKit/createInputAttributesTest.java: > Now extends JUnitRunnable, > * gnu/testlet/javax/swing/text/TextAction/TextActionTests.java: New > file, > * gnu/testlet/javax/swing/text/TextAction/augmentList.java: Now > extends JUnitRunnable, > * gnu/testlet/javax/swing/text/View/ViewTests.java: New file, > * gnu/testlet/javax/swing/text/View/getAlignment.java: Now extends > JUnitRunnable, > * gnu/testlet/javax/swing/text/View/getMaximumSpan.java: Likewise, > * gnu/testlet/javax/swing/text/View/getMinimumSpan.java: Likewise, > * gnu/testlet/javax/swing/text/View/getResizeWeight.java: Likewise. > > From konqueror@gmx.de Wed Mar 8 11:08:00 2006 From: konqueror@gmx.de (Michael Koch) Date: Wed, 08 Mar 2006 11:08:00 -0000 Subject: Running Mauve tests with JUnit In-Reply-To: <440EB4B7.1020709@object-refinery.com> References: <440C6BB8.90002@object-refinery.com> <440EB4B7.1020709@object-refinery.com> Message-ID: <20060308121256.GN18158@asterix.konqueror.de> On Wed, Mar 08, 2006 at 10:40:55AM +0000, David Gilbert wrote: > I didn't get any feedback about this...anyone think it is a good/bad idea? I think this is a good idea. JUnit is widely known and supported well by IDEs. Please go ahead. Cheers, Michael -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ From david.gilbert@object-refinery.com Wed Mar 8 13:21:00 2006 From: david.gilbert@object-refinery.com (David Gilbert) Date: Wed, 08 Mar 2006 13:21:00 -0000 Subject: Running Mauve tests with JUnit In-Reply-To: <20060308120721.GA7569@pogo.kaffe.org> References: <440C6BB8.90002@object-refinery.com> <440EB4B7.1020709@object-refinery.com> <20060308120721.GA7569@pogo.kaffe.org> Message-ID: <440EDA60.10802@object-refinery.com> Hi Dalibor, I had meant to keep this on the Mauve lists, but I'll reply to the Classpath list also... Dalibor Topic wrote: >On Wed, Mar 08, 2006 at 10:40:55AM +0000, David Gilbert wrote: > > >>I didn't get any feedback about this...anyone think it is a good/bad idea? >> >> >excellent idea in my opinion. Have you looked at graydon's junit mauve >bridge at >http://sources.redhat.com/ml/mauve-discuss/2003-q4/msg00003.html ? > > > I hadn't seen Graydon's bridge class, thanks for the link (and I should do more research next time). Looking over it, it has the advantage that it doesn't require any existing Mauve testlets to be modified (and we have a lot of testlets), but the disadvantage that it doesn't buy you much in terms of integration with IDEs (you still have to generate the test list ['classes'] file, for instance, which is the major stumbling block that people seem to have when trying to run Mauve). By modifying the Mauve testlets in the way that I proposed, you can (for example) run a single test in Eclipse just by selecting the source file and clicking 'Run as --> JUnit test'. I figured that was the sort of thing people were expecting. JUnit does seem to me to be less flexible in terms of selecting subsets of tests, and it's approach of reporting a pass/fail for each test method (only) makes it, in my opinion, less suitable for the type of testing we are doing on GNU Classpath. But I was careful in the "conversion" to retain the Mauve testlets so that we can continue running the tests in the traditional (Mauve) way. >If we do something like that. I'd like to see the junit code from >freenet merged in, to keep it simple to run mauve without external >dependencies. > > Agreed. I didn't have much trouble getting the tests to compile against the freenet code (a basic GPLed implementation of the JUnit API for those that don't know what it is) but didn't get any meaningful output from running the tests against it yet. I don't think that will be too hard to resolve. Regards, Dave From tromey@redhat.com Wed Mar 8 17:35:00 2006 From: tromey@redhat.com (Tom Tromey) Date: Wed, 08 Mar 2006 17:35:00 -0000 Subject: Java 5 features In-Reply-To: <20060307193846.GL18158@asterix.konqueror.de> References: <20060307193846.GL18158@asterix.konqueror.de> Message-ID: >>>>> "Michael" == Michael Koch writes: Michael> What is the state of support for the Java 5 language features Michael> in Mauve? Is it okay to use Generics and Enums and such Michael> stuff in testcases that are tagged "1.5"? I would like to Michael> commit some testcases that use Generics and Enums to test Michael> some stuff in GNU classpath generics branch. Michael> What's your opinion? The problem with doing this is that it means that parts of Mauve won't compile against classpath head. This in turn means that an eclipse checkout will always show errors. I suppose if we put these tests into a segregated part of the directory tree we could easily turn them off in the eclipse build. Perhaps we could just disable eclipse compilation of individual files, I haven't looked... Another idea would be to make a generics branch for mauve and then merge it when we do the merge for classpath. Tom From robilad@kaffe.org Wed Mar 8 19:07:00 2006 From: robilad@kaffe.org (Dalibor Topic) Date: Wed, 08 Mar 2006 19:07:00 -0000 Subject: Running Mauve tests with JUnit In-Reply-To: <440EDA60.10802@object-refinery.com> References: <440C6BB8.90002@object-refinery.com> <440EB4B7.1020709@object-refinery.com> <20060308120721.GA7569@pogo.kaffe.org> <440EDA60.10802@object-refinery.com> Message-ID: <1141848446.4929.16.camel@localhost> On Wed, 2006-03-08 at 13:21 +0000, David Gilbert wrote: > Hi Dalibor, > > I had meant to keep this on the Mauve lists, but I'll reply to the > Classpath list also... > Sorry about the cross-posting :/ I've taken the classpath list out again. > I hadn't seen Graydon's bridge class, thanks for the link (and I should > do more research next time). Looking over it, it has the advantage that > it doesn't require any existing Mauve testlets to be modified (and we > have a lot of testlets), but the disadvantage that it doesn't buy you > much in terms of integration with IDEs (you still have to generate the > test list ['classes'] file, for instance, which is the major stumbling > block that people seem to have when trying to run Mauve). OK, thanks for the explanation. I wasn't familiar with Graydon's code either, just remembered it was sitting in my mail box. > By modifying the Mauve testlets in the way that I proposed, you can (for > example) run a single test in Eclipse just by selecting the source file > and clicking 'Run as --> JUnit test'. I figured that was the sort of > thing people were expecting. That sounds very cool. Would it be possible to make that work without having to modify the existing tests, by (just trowing random ideas here) using a proxy to delegate to the junit Test runner, and having Testlet implement both the junit.Test interface and the Testlet interface? (I assume that a Junit test is recognized by an IDE by looking whether a class implements the junit.Test interface? Or do IDEs look for a class extending TestCase/TestSuite? I don't use IDEs much, so I hope the questions are not too stupid.) > Agreed. I didn't have much trouble getting the tests to compile against > the freenet code (a basic GPLed implementation of the JUnit API for > those that don't know what it is) but didn't get any meaningful output > from running the tests against it yet. I don't think that will be too > hard to resolve. Great, thanks for looking at that code. Sounds like it should be good enough for the basic needs. cheers, dalibor topic From olivier.jolly@pcedev.com Sat Mar 11 18:50:00 2006 From: olivier.jolly@pcedev.com (Olivier Jolly) Date: Sat, 11 Mar 2006 18:50:00 -0000 Subject: runFinalization in Classloader.initialize doesn't run on cacao Message-ID: <44131BEE.4080103@pcedev.com> Hi, while wandering around with Classloaders, I found that the teslet gnu.testlet.java.lang.Classloader.initialize wasn't running with Cacao. It seems that in the beginning of the test method, it creates an anonymous Classloader and then call System.gc() and System.runFinalization() and expects the finalizer to be ran to set a singleton like variable holder. While this is ok in jamvm and sun jre 1.5.0, cacao doesn't run the finalizer since runFinalization only gives a hint and not a mandatory order, so it is compliant. My question is whether I'm missing something and this way of doing brings something in this test or it could be rewritten in a simpler way, more compliant with the various jvm. Thanks in advance Cheers +Olivier From jeroen@sumatra.nl Sat Mar 11 19:07:00 2006 From: jeroen@sumatra.nl (Jeroen Frijters) Date: Sat, 11 Mar 2006 19:07:00 -0000 Subject: runFinalization in Classloader.initialize doesn't run on cacao Message-ID: Olivier Jolly wrote: > while wandering around with Classloaders, I found that the teslet > gnu.testlet.java.lang.Classloader.initialize wasn't running > with Cacao. > It seems that in the beginning of the test method, it creates an > anonymous Classloader and then call System.gc() and > System.runFinalization() and expects the finalizer to be ran to set a > singleton like variable holder. > While this is ok in jamvm and sun jre 1.5.0, cacao doesn't run the > finalizer since runFinalization only gives a hint and not a mandatory > order, so it is compliant. > My question is whether I'm missing something and this way of doing > brings something in this test or it could be rewritten in a > simpler way, more compliant with the various jvm. I'm obviously not aware of an easier (or more robust) way to do this, or I would have used it. However, this is a very important test (from a security pov), so it has to be in. If Cacao can't or won't support System.runFinalization(), I suggest skipping this test. Regards, Jeroen From olivier.jolly@pcedev.com Sat Mar 11 21:26:00 2006 From: olivier.jolly@pcedev.com (Olivier Jolly) Date: Sat, 11 Mar 2006 21:26:00 -0000 Subject: runFinalization in Classloader.initialize doesn't run on cacao In-Reply-To: References: Message-ID: <44134075.80902@pcedev.com> Jeroen Frijters a ??crit : >Olivier Jolly wrote: > > >> while wandering around with Classloaders, I found that the teslet >>gnu.testlet.java.lang.Classloader.initialize wasn't running >>with Cacao. >>It seems that in the beginning of the test method, it creates an >>anonymous Classloader and then call System.gc() and >>System.runFinalization() and expects the finalizer to be ran to set a >>singleton like variable holder. >> While this is ok in jamvm and sun jre 1.5.0, cacao doesn't run the >>finalizer since runFinalization only gives a hint and not a mandatory >>order, so it is compliant. >> My question is whether I'm missing something and this way of doing >>brings something in this test or it could be rewritten in a >>simpler way, more compliant with the various jvm. >> >> > >I'm obviously not aware of an easier (or more robust) way to do this, or >I would have used it. However, this is a very important test (from a >security pov), so it has to be in. If Cacao can't or won't support >System.runFinalization(), I suggest skipping this test. > > > Ok, I feared something like this. However, the way this test is written seems very obscure (to me at least). Could you advise me why is the class loader created with an exception thrown in the constructor and then the reference to the semi-created instance is retrieved in the finalizer. And then I wonder why it then raises SecurityException instead of ClassFormatError. I reread about the finalizer semantic and the ClassLoader api without finding a clue. Thanks a lot in advance >Regards, >Jeroen > > > Olivier From jeroen@sumatra.nl Sat Mar 11 21:58:00 2006 From: jeroen@sumatra.nl (Jeroen Frijters) Date: Sat, 11 Mar 2006 21:58:00 -0000 Subject: runFinalization in Classloader.initialize doesn't run on cacao Message-ID: Olivier Jolly wrote: > Ok, I feared something like this. However, the way this test > is written seems very obscure (to me at least). Could you advise me why > is the class loader created with an exception thrown in the constructor > and then the reference to the semi-created instance is retrieved in the > finalizer. And then I wonder why it then raises SecurityException > instead of ClassFormatError. I reread about the finalizer semantic and > the ClassLoader api without finding a clue. Read http://www.securingjava.com/chapter-five/chapter-five-8.html for a description of the class loader attack that this is simulating. Regards, Jeroen From olivier.jolly@pcedev.com Sat Mar 11 22:18:00 2006 From: olivier.jolly@pcedev.com (Olivier Jolly) Date: Sat, 11 Mar 2006 22:18:00 -0000 Subject: runFinalization in Classloader.initialize doesn't run on cacao In-Reply-To: References: Message-ID: <44134CC8.9020907@pcedev.com> Jeroen Frijters a ??crit : >Olivier Jolly wrote: > > >>Ok, I feared something like this. However, the way this test >>is written seems very obscure (to me at least). Could you advise me >> >> >why > > >>is the class loader created with an exception thrown in the >> >> >constructor > > >>and then the reference to the semi-created instance is retrieved in >> >> >the > > >>finalizer. And then I wonder why it then raises SecurityException >>instead of ClassFormatError. I reread about the finalizer semantic and >>the ClassLoader api without finding a clue. >> >> > >Read http://www.securingjava.com/chapter-five/chapter-five-8.html for a >description of the class loader attack that this is simulating. > > > Okey, it does make perfect sense now. Thanks for the test and the info. If you don't mind, I'll add comments to your testlet and link to this url. And, then, we don't have any test which checks ClassLoader.getPackages behaviour, I'm getting on this. >Regards, > > Thanks again, take care >Jeroen > > +Olivier From fitzsim@redhat.com Fri Mar 17 16:27:00 2006 From: fitzsim@redhat.com (Thomas Fitzsimmons) Date: Fri, 17 Mar 2006 16:27:00 -0000 Subject: Mauve wishlist Message-ID: <1142613140.3805.20.camel@rh-ibm-t41> Hi, Anthony Balkissoon has expressed interest in improving Mauve so we'd like to know what would be the best things to work on. Here are two items on my list: - A web reporting facility that generates JAPI-style bar graphs. Ideally the graphs would represent a code-coverage analysis but I have no idea how feasible that is using free tools. - A framework for testing VM invocations and the tools' command-line interfaces -- in other words, a framework that can exec commands. This may be best done as an independent module, separate from Mauve. There is also lots of room for improvement in how Mauve tests are selected and run. I'm hoping someone who better understands Mauve's design will elaborate. Tom From ddaney@avtrex.com Fri Mar 17 21:06:00 2006 From: ddaney@avtrex.com (David Daney) Date: Fri, 17 Mar 2006 21:06:00 -0000 Subject: Mauve wishlist In-Reply-To: <1142613140.3805.20.camel@rh-ibm-t41> References: <1142613140.3805.20.camel@rh-ibm-t41> Message-ID: <441B24D8.30304@avtrex.com> Thomas Fitzsimmons wrote: > Hi, > > Anthony Balkissoon has expressed interest in improving Mauve so we'd > like to know what would be the best things to work on. > > Here are two items on my list: > > - A web reporting facility that generates JAPI-style bar graphs. > Ideally the graphs would represent a code-coverage analysis but I have > no idea how feasible that is using free tools. > > - A framework for testing VM invocations and the tools' command-line > interfaces -- in other words, a framework that can exec commands. This > may be best done as an independent module, separate from Mauve. > > There is also lots of room for improvement in how Mauve tests are > selected and run. I'm hoping someone who better understands Mauve's > design will elaborate. > I would like to see a way to partition the different tests. Sometimes mauve will not build for gcj (and probably other compilers as well) because just a single file has some problem. It would be nice to still be able to run the majority of the tests in this situation. I also thought about running different groups of tests in their own ClassLoader, but cannot really think of a good reason right now to do it. David Daney From audriusa@bluewin.ch Fri Mar 17 22:34:00 2006 From: audriusa@bluewin.ch (Audrius Meskauskas) Date: Fri, 17 Mar 2006 22:34:00 -0000 Subject: Mauve wishlist In-Reply-To: <1142613140.3805.20.camel@rh-ibm-t41> References: <1142613140.3805.20.camel@rh-ibm-t41> Message-ID: <441B3990.6060306@bluewin.ch> 1. My largest problem was hangings during the tests. When an error report is just an error report, hanging blocks all testing process, requiring to remove such test manually. The problem is difficult to solve, but maybe the tests could run in the separate thread, and the threads of the normally terminated tests could be reused. JUnit, by the way, also has the same problem. 2. Probably the error reports could include the line, where the harness check failed. The stack trace of the newly constructed exception could be used to get the line information. The uncaught exception reports could also provide more information, not just "uncaught exception", as it is now. Regards Audrius Meskauskas. From konqueror@gmx.de Sat Mar 18 08:15:00 2006 From: konqueror@gmx.de (Michael Koch) Date: Sat, 18 Mar 2006 08:15:00 -0000 Subject: Mauve wishlist In-Reply-To: <441B24D8.30304@avtrex.com> References: <1142613140.3805.20.camel@rh-ibm-t41> <441B24D8.30304@avtrex.com> Message-ID: <20060318081524.GA29596@mail.konqueror.de> On Fri, Mar 17, 2006 at 01:06:32PM -0800, David Daney wrote: > Thomas Fitzsimmons wrote: > >Hi, > > > >Anthony Balkissoon has expressed interest in improving Mauve so we'd > >like to know what would be the best things to work on. > > > >Here are two items on my list: > > > >- A web reporting facility that generates JAPI-style bar graphs. > >Ideally the graphs would represent a code-coverage analysis but I have > >no idea how feasible that is using free tools. > > > >- A framework for testing VM invocations and the tools' command-line > >interfaces -- in other words, a framework that can exec commands. This > >may be best done as an independent module, separate from Mauve. > > > >There is also lots of room for improvement in how Mauve tests are > >selected and run. I'm hoping someone who better understands Mauve's > >design will elaborate. > > > > I would like to see a way to partition the different tests. Sometimes > mauve will not build for gcj (and probably other compilers as well) > because just a single file has some problem. It would be nice to still > be able to run the majority of the tests in this situation. That is what batch_run can do today. Cheers, Michael -- http://www.worldforge.org/ From avdyk@gnu.org Mon Mar 20 10:53:00 2006 From: avdyk@gnu.org (Arnaud Vandyck) Date: Mon, 20 Mar 2006 10:53:00 -0000 Subject: Mauve wishlist In-Reply-To: <1142613140.3805.20.camel@rh-ibm-t41> References: <1142613140.3805.20.camel@rh-ibm-t41> Message-ID: <441E8937.4030205@gnu.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thomas Fitzsimmons wrote: > Hi, [...] > There is also lots of room for improvement in how Mauve tests are > selected and run. I'm hoping someone who better understands Mauve's > design will elaborate. I had a very quick look at TestNG[0] and I think it could be a good approach: no need to change the mauve test classes, just invoke the tests with TestNG. There is an eclipse plugin that display the running tests like JUnit. TestNG use a tag feature like we have in mauve (JDK1.1, JDK1.2, ...) and we can add other groups like swing, nio, etc. Those tags can be annotations or javadoc comments (with @ and I think it's processed with xdoclet). As I understood (but I did not read all the documentation), the very big advantage Mauve can take in adopting TestNG (vs JUnit?) is that we shouldn't have to re-write all the test cases! [0] http://testng.org/doc/ - -- Arnaud Vandyck ,= ,-_-. =. ((_/)o o(\_)) `-'(. .)`-' \_/ Java Trap: http://www.gnu.org/philosophy/java-trap.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEHok24vzFZu62tMIRAmOoAJ9VI7oH+83wQ+FPJhvQjDfPNK+KFACbB5DS w3SFrZtDNCcjPNGEzJlDQLE= =7YEE -----END PGP SIGNATURE----- From abalkiss@redhat.com Mon Mar 20 16:51:00 2006 From: abalkiss@redhat.com (Anthony Balkissoon) Date: Mon, 20 Mar 2006 16:51:00 -0000 Subject: Mauve wishlist In-Reply-To: <1142613140.3805.20.camel@rh-ibm-t41> References: <1142613140.3805.20.camel@rh-ibm-t41> Message-ID: <1142873502.3112.16.camel@tony.toronto.redhat.com> On Fri, 2006-03-17 at 11:32 -0500, Thomas Fitzsimmons wrote: > Hi, > > Anthony Balkissoon has expressed interest in improving Mauve so we'd > like to know what would be the best things to work on. > Another suggestion that Tom Fitzsimmons had was to change the way we count the number of tests. Counting each invocation of the test() method rather than each call to harness.check() has two benefits: 1) constant number of tests, regardless of exceptions being thrown or which if-else branch is taken 2) more realistic number of tests, to accurately reflect the extent of our testing For point 1) this will help us see if we are making progress. Right now a Mauve run might say we have 113 fails out of 13200 tests and then a later run could say 200 fails out of 34000 tests. Is this an improvement? Hard to say. But if we count each call to test() as a test, and also detect hanging tests, then we should have a constant number of tests in each run and will be able to say if changes made have a positive impact on Mauve test results. Of course, if in one particular test file there are 1000 calls to harness.check() and only one of them fails, it's not helpful to just report that the entire test failed. So the output will have to pinpoint which call to harness.check failed (and preferably a line number). The negative side here is that the results will be overly pessimistic because any failing harness.check trumps all the passing harness.check calls and the test is reported as a failure. What do people have to say about this idea? --Tony From david.gilbert@object-refinery.com Tue Mar 21 16:58:00 2006 From: david.gilbert@object-refinery.com (David Gilbert) Date: Tue, 21 Mar 2006 16:58:00 -0000 Subject: Mauve wishlist In-Reply-To: <1142873502.3112.16.camel@tony.toronto.redhat.com> References: <1142613140.3805.20.camel@rh-ibm-t41> <1142873502.3112.16.camel@tony.toronto.redhat.com> Message-ID: <4420336F.4070602@object-refinery.com> Hi, Anthony Balkissoon wrote: >On Fri, 2006-03-17 at 11:32 -0500, Thomas Fitzsimmons wrote: > > >>Hi, >> >>Anthony Balkissoon has expressed interest in improving Mauve so we'd >>like to know what would be the best things to work on. >> >> >> > >Another suggestion that Tom Fitzsimmons had was to change the way we >count the number of tests. Counting each invocation of the test() >method rather than each call to harness.check() has two benefits: > > I think that would be a backward step (I like the detail that Mauve provides, especially when testing on subsets while developing on GNU Classpath). On the other hand, you can achieve this result without losing the current detail - for example, see my recent JUnit patch (not committed yet) - it effectively gives a pass/fail per test() call when you run via JUnit, without losing the ability to run in the usual Mauve way (counting check() results). >1) constant number of tests, regardless of exceptions being thrown or >which if-else branch is taken > > Mauve does have a design flaw where it can be tricky to automatically assign a unique identifier to each check(), and this makes it hard to compare two Mauve runs (say a test of the latest Classpath CVS vs the last release, or the Classpath vs JDK 1.5 - both of which would be interesting). We can work around that by ensuring that all the tests run linearly (no if-else branches - I've written a large number of tests this way and not found it to be a limitation, but I don't know what lurks in the depths of the older Mauve tests). There is still the problem that an exception being thrown during a test means some checks don't get run, but a new Mauve comparison report (not yet developed, although I've done a little experimenting with it) could highlight those. >2) more realistic number of tests, to accurately reflect the extent of >our testing > > I think the absolute number is meaningless however you count the tests, so I don't see this as an advantage. Test coverage reports are what we need to get some insight into the extent of our testing. >For point 1) this will help us see if we are making progress. Right now >a Mauve run might say we have 113 fails out of 13200 tests and then a >later run could say 200 fails out of 34000 tests. Is this an >improvement? Hard to say. > I have done a little bit of work on a comparison report to show the differences between two runs of the same set of Mauve tests, classifying them as follows: Type 1 (Normal): Passes on run A and B; Type 2 (Regression): Passes on run A, fails on run B; Type 3 (Improvement): Fails on run A, passes on run B; Type 4 (Bad): Fails on run A, fails on run B; In a comparison of JDK1.5 vs Classpath, Type 4 hints that the check is buggy. This is a work in progress, and I don't have any code to show anyone yet, but it is an approach that I think can be made to work. To make it work, each check has to be uniquely identified - I did this using the checkpoint and check index within a test(), so here it is important that if-else branches in the tests can't result in checks being skipped. This is the case for most of the javax.swing.* tests, but I can't speak for some of the older Mauve tests. >But if we count each call to test() as a >test, and also detect hanging tests, then we should have a constant >number of tests in each run and will be able to say if changes made have >a positive impact on Mauve test results. > You'll lose the ability to distinguish between an existing failure where (say) 1 out of 72 checks fail, and after some clever patch 43 out of 72 checks fail, but the new system reports both as 1 test failure. Regards, Dave From tromey@redhat.com Tue Mar 21 22:24:00 2006 From: tromey@redhat.com (Tom Tromey) Date: Tue, 21 Mar 2006 22:24:00 -0000 Subject: Mauve wishlist In-Reply-To: <4420336F.4070602@object-refinery.com> References: <1142613140.3805.20.camel@rh-ibm-t41> <1142873502.3112.16.camel@tony.toronto.redhat.com> <4420336F.4070602@object-refinery.com> Message-ID: >>>>> "David" == David Gilbert writes: >> Another suggestion that Tom Fitzsimmons had was to change the way we >> count the number of tests. Counting each invocation of the test() >> method rather than each call to harness.check() has two benefits: David> We can work around that by ensuring that all the tests run linearly David> (no if-else branches - I've written a large number of tests this way David> and not found it to be a limitation, but I don't know what lurks in David> the depths of the older Mauve tests). There is still the problem that David> an exception being thrown during a test means some checks don't get David> run, but a new Mauve comparison report (not yet developed, although David> I've done a little experimenting with it) could highlight those. I've always tried to write tests the way you suggest, but the exception problem turns out to be a real one, preventing test stability in some cases. One thing I like about this current proposal is that it automates test stability -- the only failure modes possible are if a test hangs or if the VM crashes. As far as having more granular information -- we can still print a message when a check() fails. A command line option to the test harness could control this, for instance. I think we don't want to just print a plain 'FAIL', we want some explanation; the detailed info could go there. Tom From mckinlay@redhat.com Tue Mar 21 23:08:00 2006 From: mckinlay@redhat.com (Bryce McKinlay) Date: Tue, 21 Mar 2006 23:08:00 -0000 Subject: Mauve wishlist In-Reply-To: <4420336F.4070602@object-refinery.com> References: <1142613140.3805.20.camel@rh-ibm-t41> <1142873502.3112.16.camel@tony.toronto.redhat.com> <4420336F.4070602@object-refinery.com> Message-ID: <4420874C.2090800@redhat.com> David Gilbert wrote: > 1) constant number of tests, regardless of exceptions being thrown or > Mauve does have a design flaw where it can be tricky to automatically > assign a unique identifier to each check(), and this makes it hard to > compare two Mauve runs (say a test of the latest Classpath CVS vs the > last release, or the Classpath vs JDK 1.5 - both of which would be > interesting). Right. We all understand the problem - its just the solution is what we need to agree on :) > I think the absolute number is meaningless however you count the > tests, so I don't see this as an advantage. Yes, numbers alone are meaningless, but with the current design, all the results are meaningless without a lot of context. The real issue is having a simple way to uniquely identify each test case for the purpose of identifying regressions. This becomes fundamentally much easier when 1 test() method corresponds to one test case. It is not reasonable to expect test case developers ensure that all tests "run linearly". Exceptions can potentially be thrown at any time, so to ensure linearity, every check() call would need wrapped with a try/catch. > You'll lose the ability to distinguish between an existing failure > where (say) 1 out of 72 checks fail, and after some clever patch 43 > out of 72 checks fail, but the new system reports both as 1 test failure. This is a valid concern. However, we will still track exactly which check() calls fail so that in the event of a test failure, a full diagnostic can be provided. In addition, we can still count the total number of check() calls executed, for statistical purposes. If the reduced test-case granularity does prove to be problematic in some cases - say some test() where a small number of checks fail for cases that are "hard to fix" problems and thus should be "xfailed" (to use gcc/dejagnu lingo), then that test case should probably be split. Alternatively, to avoid splitting things across multiple test classes, we could add JUnit-style support for multiple test() methods in a single test class. Bryce From david.gilbert@object-refinery.com Wed Mar 22 11:12:00 2006 From: david.gilbert@object-refinery.com (David Gilbert) Date: Wed, 22 Mar 2006 11:12:00 -0000 Subject: Mauve wishlist In-Reply-To: <4420874C.2090800@redhat.com> References: <1142613140.3805.20.camel@rh-ibm-t41> <1142873502.3112.16.camel@tony.toronto.redhat.com> <4420336F.4070602@object-refinery.com> <4420874C.2090800@redhat.com> Message-ID: <44213403.3020307@object-refinery.com> Bryce McKinlay wrote: > > It is not reasonable to expect test case developers ensure that all > tests "run linearly". Exceptions can potentially be thrown at any > time, so to ensure linearity, every check() call would need wrapped > with a try/catch. > If there is a linear sequence of checks in a test() method, and an (unexpected) exception causes the test() method to exit early (after, say, 3 checks out of 10), I don't consider that to be non-linear. If we are comparing run A to run B, and 10 checks complete in run A, but only 3 checks complete in run B, we can safely assume that checks 4 to 10 were not completed in run B, and report that. The majority of test() methods in Mauve are written that way, so I don't think it is an unreasonable requirement, especially if it means we can develop better comparison/regression reporting on top of the existing TestHarness. Regards, Dave From abalkiss@redhat.com Mon Mar 27 21:45:00 2006 From: abalkiss@redhat.com (Anthony Balkissoon) Date: Mon, 27 Mar 2006 21:45:00 -0000 Subject: Request for Comments: new Mauve harness Message-ID: <1143495948.3903.122.camel@tony.toronto.redhat.com> Attached is the start of the new Mauve test harness I've been working on. The features that are present so far include: 1. easier invocation: - from the mauve source folder type (using jamvm, for example), type "jamvm Harness" to run all tests. - "jamvm Harness -help" displays a help screen. - single test: "jamvm Harness javax.swing.JTable.isCellEditable" - folder of tests: "jamvm Harness javax.swing" Note that the Harness also accepts input from standard input, so any scripts you have locally will still work. Also, for the test name above, a "gnu.testlet." prefix would work as well, as would the name "gnu/testlet/javax/swing/JTable/isCellEditable", so tab-completion is possible. 2. line numbers for failures and minimal information for exceptions - rather than counting tests, when a call to harness.check() fails, a line number and a reason for the failure is given - type/location/point of origin are given for uncaught exceptions 3. constant number of tests - as discussed, by reporting each call to test() as one test, while still printing out all the failing calls to harness.check(), we're able to achieve a constant number of tests between successive runs, even if there are uncaught exceptions. *** NOTE: This harness is not done yet. There is no hang/crash detection, so you will notice problems if you try to run all tests. I'm hoping for feedback on the things it *can* do so far. This harness will eventually detect crashes/hangs and will also auto-compile tests, so new or updated tests will be run properly without having to compile them separately. Code coverage tools may also be added. So although right now the harness provides no more than what was already available, it eventually will and I'd like to develop it in stages, which is why I submit this patch for comments. Thanks, Tony -------------- next part -------------- A non-text attachment was scrubbed... Name: HarnessAddition.diff Type: text/x-patch Size: 32988 bytes Desc: not available URL: From robilad@kaffe.org Mon Mar 27 23:44:00 2006 From: robilad@kaffe.org (Dalibor Topic) Date: Mon, 27 Mar 2006 23:44:00 -0000 Subject: Request for Comments: new Mauve harness In-Reply-To: <1143495948.3903.122.camel@tony.toronto.redhat.com> References: <1143495948.3903.122.camel@tony.toronto.redhat.com> Message-ID: <1143503052.4903.16.camel@localhost> On Mon, 2006-03-27 at 16:45 -0500, Anthony Balkissoon wrote: > Attached is the start of the new Mauve test harness I've been working > on. The features that are present so far include: It sounds great, thank you for your work! cheers, dalibor topic From twisti@complang.tuwien.ac.at Tue Mar 28 09:19:00 2006 From: twisti@complang.tuwien.ac.at (Christian Thalinger) Date: Tue, 28 Mar 2006 09:19:00 -0000 Subject: Request for Comments: new Mauve harness In-Reply-To: <1143495948.3903.122.camel@tony.toronto.redhat.com> References: <1143495948.3903.122.camel@tony.toronto.redhat.com> Message-ID: <1143537554.22966.160.camel@localhost.localdomain> On Mon, 2006-03-27 at 16:45 -0500, Anthony Balkissoon wrote: > "gnu/testlet/javax/swing/JTable/isCellEditable", so tab-completion is > possible. YES! Thank you sooooo much for that :-) TWISTI