Because this is an apache project, there's nothing stopping a set of
the developers from working on JSF 1.2 if that's their "itch to
scratch" (other than a PMC mandate).  At least, that's my impression
from watching the struts dev mailing list over the years.

Personally, I'm -0 on working on a JSF 1.2 branch.   I'm +1 on adding
1.2 features to the existing 1.1 branch so long as they're compatible,
but I don't have the option/interest of doing Java 1.5 work at this
time, and Java 1.5 is a requirement for JSF 1.2.

<shameless plug>
Besides, Facelets gives me almost all of the missing JSF 1.2 features
at no extra cost while continuing to use MyFaces 1.1.
</shameless plug>

On 2/15/06, Simon Kitching <[EMAIL PROTECTED]> wrote:
> -0 on making trunk a JSF1.2 project.
>
> There is a whole lot of work still to be done to stabilise the 1.1.x
> series; the JIRA issues list alone shows that. I would prefer to see the
> main emphasis be on getting a "finished" release of the 1.1 spec rather
> than on having an incomplete 1.1 and an incomplete 1.2 concurrently.
> That doesn't mean that work on 1.2 features can't happen; just I think
> that trunk (which is the easiest and most obvious place to work) should
> stay with 1.1.x until all the major JIRA issues are fixed. Patches for
> the 1.1.x series can be applied to "trunk", then merged to the 1.2
> branch at leisure; this seems more sensible than having things the other
> way around.
>
> Regards,
>
> Simon
>
>
> On Wed, 2006-02-15 at 05:38 -0700, Bill Dudney wrote:
> > +1 on branching 1.1.x and moving trunk to JSF 1.2
> >
> > Bill Dudney
> > MyFaces - myfaces.apache.org
> > Wadi - incubator.apache.org/wadi
> >
> >
> >
> >
> >
> > On Feb 15, 2006, at 12:08 AM, John Fallows wrote:
> >
> > > On 2/14/06, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> > >         Wo-ow!
> > >
> > >         cool, that went fast!
> > >
> > >         Now, I'm definitely for a JSF 1.2 branch, if we can go with
> > >         that.
> > >
> > > We'd probably want to branch the more stable 1.1.x codeline and let
> > > trunk evolve to leverage the new 1.2 APIs.
> > >
> > > Kind Regards,
> > > John Fallows.
> > >
> > >
> > >         regards
> > >
> > >         Martin
> > >
> > >         On 2/14/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > >         > The commons-el code is poor IMHO.  The one I donated to
> > >         Jasper was originally founded within the RI 1.1 donation and
> > >         benchmarked quite a bit faster at the time.
> > >         >
> > >         > The one re-written for the EL-API and donated to both Sun
> > >         and Apache is based on Java CC, and finely tuned for JSF's
> > >         serialization and stateful lifecycles around VariableMappers
> > >         and FunctionMappers.
> > >         >
> > >         > I may be biased, but I think it would be a waste of time
> > >         to try to modify the commmons-el solution for the EL-API.
> > >         >
> > >         > BTW, on the topic of JSF 1.2 and findComponent, we've
> > >         added invokeOnComponent to the spec, implemented much like
> > >         was discussed here on the dev list and has been implemented
> > >         and tested within the RI.  I, personally, would like to see
> > >         MyFaces adopt this method early instead of providing a
> > >         partial solution with perspectives to users.
> > >         >
> > >         > -- Jacob
> > >         >
> > >         > >
> > >         > >> Wow!.  I must have missed that email!  Was it donated
> > >         to MyFaces?  I
> > >         > >
> > >         > >I think it was sent, when you are on vacation ;-)
> > >         > >
> > >         > >-Matthias
> > >         >
> > >
> > >
> > >         --
> > >
> > >         http://www.irian.at
> > >
> > >         Your JSF powerhouse -
> > >         JSF Consulting, Development and
> > >         Courses in English and German
> > >
> > >         Professional Support for Apache MyFaces
> > >
> > >
> > >
> > > --
> > > http://apress.com/book/bookDisplay.html?bID=10044
> > > Author: Pro JSF and Ajax: Building Rich Internet Components, Apress
> >
> >
>
>

Reply via email to