Hi All, A thought just occurred to me.
The JSF core spec license (and TCK) require that we do not add any class to the javax.faces namespace which is not in the spec. This is fair, as doing so would confuse users and lead to unportable code. However this limitation has caused some real pain, as we would *like* to have helper methods shared across javax.faces classes which are not in the same package. Our current solution for this is some very ugly "templating" in the build tools, where we generate classes in the javax.faces packages so that we can "paste" the same code into them. But does anything in the spec or TCK actually say that the "myfaces-api.jar" file cannot contain classes in the "org.apache.myfaces" namespace, or that our implementations of javax.faces classes (eg javax.faces.component.UIComponentBase) cannot then call static methods on those classes or have instances of them as private members? Sun doesn't do that; simply looking at the classes within the jsf-api.jar file shows that it contains nothing that is not in the javax.faces namespace. But are we required to do the same? Adding such classes doesn't seem to me to violate the spirit of JSF at all; the point is to avoid tricking users into writing non-portable code, but we wouldn't be doing that. And if you look at the standard java "rt.jar", it contains lots of "com.sun" classes, and no-one claims that this forces or deceives people into writing non-portable java. Being able to add helper classes into the myfaces-api.jar file would make life simpler in a lot of ways. In fact, is there any reason why JSF needs to be split into two "api" and "impl" jar files, rather than just one? Not that I'm suggesting that; but it does seem possible. Regards, Simon -- -- Emails in "mixed" posting style will be ignored -- (http://en.wikipedia.org/wiki/Posting_style)
