For properly testing against both APIs and IMPLs, we'd need to have the RI be
1) maven2-nized 2) with a compatible license. Now, license issues have been resolved for most of the licenses we deal with. Was the CDDL amongst the libraries we may deliver binaries with? I do believe so... regards, Martin On 3/20/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: > (Coming back from London after a couple of days out of touch, so this might > be old news, but ...) > > > On 3/17/06, Dennis Byrne < [EMAIL PROTECTED]> wrote: > > >One -- you're actually limiting or biasing the test coverage for this > > >particular test because you're testing against a particular > > >implementation rather than a more abstract mock object. > > > > Yes, this is an argument that is as old as QA itself ;) > > > And it would be exactly the same if the tests were using a MyFaces-specific > mock object :-). > > The point is that you *cannot* test the behavior of many JSF related objects > without more than a "pure abstract" implementation of the mock objects. I'm > sure that is true in most scenarios that use mock objects for a testing > strategy, but it is clearly true here. > > Want proof? You wouldn't believe how many times the Shale test framework > had to flesh out implementations of abstract methods (that used to just > throw UnsupportedOperationException) before the framework was actually > usable in testing MyFaces components :-). > > > >Two -- by requiring impl to be a dependency for the test code, you > > >allow the possibility of unintentionally using impl classes in the > > >non-test code. > > > > As long as impl is scoped as "test" in the pom.xml for tomahawk, I don't > see how maven would allow one of us to compile the non-test code. > > > +1. In order to test components correctly, it is vital that the > compile-time and runtime classpaths for the tests include the API jar file > and the test framework, but *not* the impl classes. > > HOWEVER ... this condition is merely "necessary but not sufficient". That > is because JSF has quite a lot of "implementation" functionality built in to > the API classes as well, so you could still end up with unintended > dependencies on the MyFaces API classes. A robust testing strategy for > components would execute against both (a) MyFaces API + Test Framework, and > (b) JSF RI + Test Framework. Along with, of course, runtime tests against > both API+IMPL combinations. > > > >Another observation is that end-users cannot download, build, test > > >Tomahawk without MyFaces impl. Since Tomahawk is supposed to be > > >JSF-implementation independent, it's contrary to our stated goal to > > >require a specific implementation for testing or development. > > > > Obviously we want people to use tomahawk w/out myFaces impl. If you would > like to make it possible for them to test tomahawk w/out impl than more > power to you. I think this is taking it too far and we will never get a pat > on the back for this. > > > Isn't this the basic motivation behind migrating to a "shared" or "commons" > artifact that both the MyFaces impl and the components can depend on, > without creating a mutual dependency? (But that only deals with part of the > problem, as the previous response paragraph describes.) > > > Dennis Byrne > > > > > > > > Craig > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
