Hello, Are there gonna be tests for the jsr-201 (Enumerations, Autoboxing, Enhanced for loops and Static Import) in the next Jacks updates ? Is there a possiblity to add our tests made for the jsr-201 ? Regards -- -- Taoufik
--- Taoufik EL AOUMARI <taoufik@...> wrote: > Hello, > > Are there gonna be tests for the jsr-201 (Enumerations, Autoboxing, > Enhanced for loops and Static Import) in the next Jacks updates ? > > Is there a possiblity to add our tests made for the jsr-201 ? I think it would be great to have tests for the new jsrs added to jacks, too. You can ask Tom Tromey for cvs access to mauve/jacks. cheers, dalibor topic p.s. there is an updated draft of the JLS3 apparently without insane click-through licenses at http://java.sun.com/docs/books/jls/jls-proposed-changes.html __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/
>> Are there gonna be tests for the jsr-201 (Enumerations, Autoboxing, >> Enhanced for loops and Static Import) in the next Jacks updates ? >> >> Is there a possiblity to add our tests made for the jsr-201 ? Yeah, definitely. Dalibor> I think it would be great to have tests for the new jsrs Dalibor> added to jacks, too. You can ask Tom Tromey for cvs access Dalibor> to mauve/jacks. Fill out the handy form: http://sources.redhat.com/cgi-bin/pdw/ps_form.cgi There are a few jacks tests for new language features already. And I think I have some more lying around that I haven't checked in yet... nothing very comprehensive though. Tom
Hi, In the "Install Requirements" section of: http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/jacks/jacks.html?cvsroot=mauve the instructions for fetching Jacks from CVS are incorrect in the light of the move to Mauve's CVS. Can someone please correct it? That aside, the Jacks logo in the top-left is not displayed correctly: a. It needs "?cvsroot=mauve" appended to the reference. b. Even then the MIME-type returned is incorrect for a PNG image. Thanks, Ranjit. -- -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA. Web: http://ranjitmathew.hostingzero.com/
For a project as large as Classpath, it would be good to have a tests for all important classes. Apart the standard java.* and javax.* , this also includes the Classpath specific classes from gnu.* namespace. In some packages this namespace contains many classes, having hundreds lines of the working code. Even it they run ok today, staying without tests leaves a gap for the future regression bugs. It is not immediatly clear if such tests can be contributed to Mauve. With such tests the Mauve would not compile without the newest version of Classpath. Classpath has its own small test suite. While not very popular and requiring to write all tests in the form of the executable classes, it could be treated as an alternative. Before committing Classpath specific tests to Mauve, I would like to discuss this question in the list. Regards Audrius
On Thu, Mar 10, 2005 at 03:18:33PM +0100, Meskauskas Audrius wrote: > For a project as large as Classpath, it would be good to > have a tests for all important classes. Apart the standard > java.* and javax.* , this also includes the Classpath > specific classes from gnu.* namespace. In some > packages this namespace contains many classes, > having hundreds lines of the working code. Even it they run ok today, staying without tests leaves a gap for > the future regression bugs. It is not immediatly clear if such tests can be contributed to > Mauve. With such tests the Mauve would not compile > without the newest version of Classpath. Classpath has its own small test suite. While not very popular > and requiring to write all tests in the form of the executable > classes, it could be treated as an alternative. > > Before committing Classpath specific tests to Mauve, I would > like to discuss this question in the list. We should really put the tests in muave. Into a specific CVS module if needed/wanted. We have already classpath specific tests in Mauve. If we consider an extra module is need then we should move them into it. Michael -- -- Java Trap: http://www.gnu.org/philosophy/java-trap.html
Michael Koch wrote: > On Thu, Mar 10, 2005 at 03:18:33PM +0100, Meskauskas Audrius wrote: > >>For a project as large as Classpath, it would be good to >>have a tests for all important classes. Apart the standard >>java.* and javax.* , this also includes the Classpath >>specific classes from gnu.* namespace. In some >>packages this namespace contains many classes, >>having hundreds lines of the working code. Even it they run ok today, staying without tests leaves a gap for >>the future regression bugs. It is not immediatly clear if such tests can be contributed to >>Mauve. With such tests the Mauve would not compile >>without the newest version of Classpath. Classpath has its own small test suite. While not very popular >>and requiring to write all tests in the form of the executable >>classes, it could be treated as an alternative. >> >>Before committing Classpath specific tests to Mauve, I would >>like to discuss this question in the list. > > > We should really put the tests in muave. Into a specific CVS module if > needed/wanted. We have already classpath specific tests in Mauve. If we > consider an extra module is need then we should move them into it. I'd say mauve, too. If a test is Classpath specific, then it can be tagged as such. cheers, dalibor topic(Continue reading)
Dalibor> I'd say mauve, too. If a test is Classpath specific, then it Dalibor> can be tagged as such. I agree. We already put Classpath regression tests into Mauve. For things that are truly Classpath-specific, say tests for gnu.*, we can just invent a new "classpath" tag and mention it in README. Tom
Hi,
On Sat, 2005-03-12 at 12:21 -0700, Tom Tromey wrote:
> Dalibor> I'd say mauve, too. If a test is Classpath specific, then it
> Dalibor> can be tagged as such.
>
> I agree. We already put Classpath regression tests into Mauve. For
> things that are truly Classpath-specific, say tests for gnu.*, we can
> just invent a new "classpath" tag and mention it in README.
OK. How about the following patch to the README:
--- README 4 Jan 2005 20:53:30 -0000 1.20
+++ README 15 Mar 2005 17:34:46 -0000
<at> <at> -46,6 +46,15 <at> <at>
JDK1.1 Run JDK1.1 tests only
JDK1.2 Run JDK1.2 tests only
+ * The GNU_CLASSPATH tag selects and runs tests specific to the
+ (internal) core classes of the Free Software Foundation GNU Classpath
+ implementation (available from http://www.gnu.org/software/classpath)
+ on which a lot of free runtimes and compilers are build (but which are
+ not guaranteed to be available on all platforms).
+ These tests can be enable by adding GNU_CLASSPATH to your KEYS variable
+ and disabled by adding !GNU_CLASSPATH to the KEYS variable.
+ All such tests are in subdirectories under gnu/testlet/classpath.
+
If an otherwise unrecognized tag QUUX is seen, and the file
`mauve-QUUX' exists in the mauve source directory, then the contents
of this file are treated as a list of tags. For instance, here is the
(Continue reading)
Mark> OK. How about the following patch to the README: Looks good. Mark> By having a tag and a special subdirectory for these tests it should be Mark> simple to enable/disable these special tests for the various ways people Mark> run mauve (by hand, make, batch_run, ant script, etc). I think just putting them in a directory named after their class, like we do for everything, will suffice. Using 'gnu.javax.swing....' is just as selectable -- and obviously classpath-specific, IMO -- as 'classpath.gnu.javax.swing...' But I don't have a strong opinion on it. Tom
RSS Feed1 | |
|---|---|
1 | |
2 | |
3 | |
3 | |
1 | |
21 | |
10 | |
2 | |
2 | |
1 | |
1 | |
3 | |
1 | |
7 | |
1 | |
2 | |
35 | |
5 | |
1 | |
3 | |
6 | |
6 | |
11 | |
4 | |
21 | |
12 | |
7 | |
1 | |
28 | |
29 | |
18 | |
10 | |
25 | |
22 | |
57 | |
13 | |
1 | |
8 | |
8 | |
10 | |
12 | |
20 | |
19 | |
14 | |
38 | |
11 | |
1 | |
12 |
