Matthias Wessendorf wrote:
I'm perfectly happy to make using MyFaces configurable easily in our build scripts.In principle, this makes perfect sense. It'll be easy if you've split the MyFaces jars into api and impl classes (like the RI does), because then it's just a matter of setting up your own build.properties file and defining "jsf-api.jar" and "jsf-impl.jar" appropriately.
no, not now. but i mean also the use of myfaces in the examples. so it would be much easier for users, since JSF (myfaces) is delivered directly
for running the WAR-files.
But I'm -1 on including MyFaces in any Struts distribution until it has passed the TCK tests to certify that it is a compatible implementation of JavaServer Faces. Assistance in making that happen is one of the benefits you'll get by becoming an Apache project (once MyFaces passes through the incubation process), because Apache already has access to all the relevant TCK tests without having to apply for the scholarship that is available for non-profit orgs.
But, until it does, it would be a disservice to Struts users to package something that represents itself as being JSF when it hasn't been proven to be so.
Regarding the split of JARs, I would recommend you do that (javax.faces.* versus everything else) if you have not done so yet. The primary benefit is that users of MyFaces will only need the API jar in their compile time classpath, and will therefore not be tempted to program directly to the implementation classes and therefore lock themselves in to MyFaces (instead of being portable to anyone's JSF implementation).
You'll need to include both the API and IMPL jars in a webapp, of course, but that's already taken care of by the build scripts for the struts-faces examples (assuming you configure the properties correctly).
matthias
Craig
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
