|
[
Permlink
| « Hide
]
Craig McClanahan added a comment - 21/Aug/06 05:33 PM
I presume we mean that the testing framework should *not* impose the JSF implementation on what is being tested, right? :-)
Correct "type-o" in description. The second sentence should have read "The testing framework should not impose the JSF implementation on
what is being tested." The word "not" was left out. Thanks to Craig McClanahan for pointing out the error. This affects maven users. Based on that I would suggest status be raised to blocker or critical
To avoid enforcing the choice of JSF implementation on users, all of the JSF api and impl dependencies should be marked 'provided'. Since these definitions are in the shale-parent pom, this issue affects all of the Shale jars. This will be addressed as part of a larger effort that will also fix the dependencies for the webapps and work around some issues with Maven's dependency resolution. Users can work around this issue in Shale 1.0.3 by using <exclusions> in their own project poms. As of the 20060914 nightly build (and corresponding updated 1.0.4-SNAPSHOT), I have completed a first pass at refactoring our build process to address these dependency issues. Now, building the Shale Framework libraries depends on the MyFaces API jar, but when you build an application you still get the choice of which implementation to use. As a side effect, the framework library POMs (including shale-core and shale-test) should no longer force you to use the JSF implementation that they were built against.
Leaving the issue open for the moment, because it is very likely I've missed some details along the way. The shale-core and shale-test modules (and others) now declare a "provided" dependency on the MyFaces API jar (because they need JSF APIs in order to compile), but this will not translate into a runtime dependency on this particular version.
|
||||||||||||||||||||||||||||||||||||||||||