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
