On Wed, Nov 5, 2008 at 10:55 AM, Simon Kitching <[EMAIL PROTECTED]> wrote: > 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?
hrm, I am not sure on this, but doubt it would be OK. Leo acutally has the TCK, perhaps he just could try to add things like that to see what the binary compatibility hammer tells you. That said, I think it would confuse users of the API JAR, if they see stuff in there... that is not part of the spec... they start to use it and have issues when they say "good bye myfaces"... I am not really thrilled to add those vendor locks... > > 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. In a tool (JDeveloper, Eclipse, name it) you only want the API, since that is specified. The impl is private and not intended for usage in someones application. If we would mix api and impl into one jar... we would expose the stuff from impl, which is mostly not desired when one cares about writing jsf-based apps... > > Regards, > Simon -M > > -- > -- Emails in "mixed" posting style will be ignored > -- (http://en.wikipedia.org/wiki/Posting_style) > > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
