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...
>
>> 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?
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
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.
Regards, Simon
