We know that the resulting build should either have jsf-api.jar and jsf-impl.jar (1.2 version) in the case of JSF testing, or myfaces-api.jar and myfaces-impl.jar in the case of MyFaces testing.

My question is if the JSF-1.2 libs are removed, should MyFaces still suppose to work on tomcat 6, or we expect MyFaces to only work on Tomcat 5?

A new target was created with the name "myfaces" in build-common.

For developers, the build script became a bit smarter to adapt switch -Dmyfaces="" so that "tomcat" server targets and switch -Dmyfaces="" could be combined together.

Markup switches with targets maybe a better option. As we discussed a year ago, building targets to markup switches was one of goals to improve build functionality and feasibility.

For myfaces, myfaces applications have no conjunction to JSF RI jars in compiling time and deploying time. A new target, "myface", may be good to use to build all myfaces war files.

I guess we have two options then:

1. Add new targets for MyFaces (1.1 and App. Server combinations
2. Make the build smart enough to adapt properly when the -Dmyfaces="" switch is used in conjunction with the existing build targets (basically substitute the sun JSF RI jars with the MyFaces ones).

Thoughts?

The target "myfaces" was dedicated for war files built for myfaces applications.

The target "build.myfaces.war" in build-common provides the function to build war file for myfaces version. It is available for use at any level in Samples. As I remember, there was a discussion about myfaces issue. We do not support jsf1.2 with myfaces yet. So the default server for the war file is Tomcat 5.x. The war file for myfaces version from the most current trunk works fine with Tomcat 5.5