On Wed, Nov 5, 2008 at 1:43 PM, Simon Kitching <[EMAIL PROTECTED]> wrote: > Matthias Wessendorf schrieb: >> 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. >> > Yep, it would be great if Leonardo would be willing to try this out some > time... >> 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... >> > I think that if anyone has this in their class: > import org.apache.myfaces.core._StateHolderHelper; > then it should be reasonably obvious to them that they are using a > non-portable feature...
yeah, but... I saw puking horses in front of a drugstore (German saying) :-) >> >>> 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... >> > > You are worried about auto-complete offering non-standard classes as > possible completions? the general presence of IMPL-based "APIs". A good designed application shouldn't use IMPL exposed "APIs". Sometimes you need that (vanilla JPA is not enough) but than, in those rare cases... there is a good chance, that the devs know why they used it. > > I agree that it would be a bad idea to include a class named > org.apache.myfaces.core.FacesContext > in the myfaces-api.jar file. Some common-sense is needed. Maybe we could yes, true :-) > adopt the convention that all non-standard classes in the jar start with > underscore or similar; that should prevent them popping up when not wanted. > > But I don't think that simply having org.apache.myfaces classes in the > jar is going to confuse anyone that has more than two brain-cells. And > it would make the implementation a *lot* easier to work on, with less > "build magic" involved. I am not convinced that it is a good idea - in terms of thinking about (happy) users. I agree on the impl implementation, though. -M > > Regards, Simon > > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
