I agree. Let's do homework first.
And for all "itchy" guys: Let's start a wiki page with the 1.2 roadmap
as Sean suggested.

Manfred


On 2/15/06, Sean Schofield <[EMAIL PROTECTED]> wrote:
> I'm also not very "itchy" for JSF 1.2.  I too will be looking at
> facelets on my next JSF project or using the RI.  I'd rather spend my
> energies on a really solid component foundation.
>
> My suggestion is that we hold off on the JSF 1.2 stuff for a month or
> so at least until we get a chance to release, fix the website, square
> away JIRA and assimilate Tobago.  Those tasks will require everybody's
> attention and will ultimately impact the 1.2 effort (at least from an
> infrastructure standpoint.)
>
> I also think we need a *very* well though out plan for how to proceed
> with 1.2 so we don't confuse the hell out of everybody (including
> ourselves.)  I don't think its just as simple as making a branch.
> Maybe we could start with a detailed roadmap of how the 1.2 effort
> would work and who is willing to work on it.  Something more then just
> creating a branch and seeing what happens ...
>
> Sean
>
> On 2/15/06, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
> > 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