And it's only failing for one of the Tomahawk tests, so it's not really a MyFaces core test that's failing (as far as I can tell). But still........
I checked out Shale Test, located all the dependencies, and created a patch. As far as I can tell, it's the only problem in the codebase. Eclipse didn't identify any other problems. On 8/11/06, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
No, it's a Java 1.5 method that snuck into Shale Test 1.0.3-snapshot. I should have been more clear about that. https://issues.apache.org/struts/browse/SHALE-251 But yeah, that would be good for us as well. On 8/11/06, Dennis Byrne <[EMAIL PROTECTED]> wrote: > Perhaps we can also get mvn to enforce this in local development as well? > > Mike, Did you mean 1.1.3 snap ? > > Dennis Byrne > > >-----Original Message----- > >From: Mike Kienenberger [mailto:[EMAIL PROTECTED] > >Sent: Friday, August 11, 2006 07:46 PM > >To: 'MyFaces Development' > >Cc: 'Craig McClanahan' > >Subject: Re: Heads Up on Shale Test Framework API Change > > > >Speaking of breakage, there's a Java 1.5 method dependency in the > >1.0.3-snapshot, which is causing MyFaces to fail to build with testing > >enabled (the default) under Java 1.4. > > > >https://issues.apache.org/struts/browse/SHALE-251 > > > >It'd be great if we could get this fixed at the same time. > > > >It'd probably be a good idea if Shale had an automated way to catch > >Java 1.4 incompatibilities right away. > > > >This brings up another issue. Should MyFaces 1.1 be requiring Java > >1.4 to run tests? We're obligated to provide 1.3 support for the core > >as it stands. My personal thoughts are that requiring 1.4 to run the > >tests isn't the end of the world, but should at least be documented > >somewhere. > > > >Do we have continuum set up to build the core with Java 1.3 to insure > >there aren't any Java 1.4 methods sneaking into the code? > > > > > >On 8/11/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: > >> We're looking at implementing a suggestion[1] to change the API on the > >> setUp() and tearDown() methods of > >> org.apache.shale.test.base.AbstractJsfTestCase, to add > >> "throws Exception" to the method signatures. The primary goal is to be > >> consistent with the underlying TestCase class from JUnit 3.8.1, and to allow > >> test developers to go ahead and let JUnit handle exceptions here like you > >> often do when you add "throws Exception" to individual test methods. > >> > >> Implementing this change, of course, will cause all existing test cases that > >> extend this base class to not compile. Looking at the MyFaces and Trinidad > >> codebases, there are indeed a few such tests (although not a gigantic > >> number). What I propose to do is to make the change in the Shale code, and > >> then fix the test cases in MyFaces and Trinidad and check those in too > >> (since I'm a committer on both repositories). > >> > >> Does anyone see any problem with me doing this (probably over the weekend at > >> some point)? > >> > >> Craig McClanahan > >> > >> [1] https://issues.apache.org/struts/browse/SHALE-249 > >> > >> > > > > >
