Going back to the faces module, instead of continuing with the org.jboss.seam.jsf and org.jboss.seam.faces package split in Seam 3, I think we should put all the faces classes under org.jboss.seam.faces and use appropriate sub-package names. So in this case, I propose org.jboss.seam.faces.application.SeamApplicationFactory and org.jboss.seam.faces.application.SeamApplication for overriding the default Application impl. We will also need the org.jboss.seam.el package (perhaps module).

+1 for this idea.  The module dependencies are turning out to be quite difficult to unravel, if we put our foot down and say that all faces-related/dependent functionality just goes in the faces module this will greatly help to simplify things.

I think it's just a matter of zooming out to look at the bigger picture when things seem like they are in a twist.

Instead of thinking of replacing the class 1-for-1, think if perhaps there is base functionality that would be relevant for any environment and specific functionality for a framework like JSF. Then, you can create a generic class and then specialize it using a deployment type and @Specializes. Two examples of this so far are StatusMessages/FacesStatusMessages and Expressions/FacesExpressions. I believe that Selector is another candidate for this. There is nothing specific to JSF about a selector, but it just happens to be in the JSF package in Seam 2.1.

-Dan

--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action

http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan

NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters.  Please don't hesitate to resend a message if
you feel that it did not reach my attention.