hi leo, no - we don't need a compromise just for testing this feature. it's really an important feature also for v2.0.x and v2.1.x! i explained all the advantages (for users of myfaces-core v2.0.x and v2.1.x and also tomee) in the first mail of this thread - please read it again.
if you have objections concerning the initial stability of the myfaces specific api, it's also fine to start with a prototype in a separated branch. regards, gerhard http://www.irian.at Your JSF/JavaEE powerhouse - JavaEE Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2012/7/31 Leonardo Uribe <[email protected]> > Hi Gerhard > > In my opinion, start with 2.1.x is the wrong way to do it. Sounds > better to create a branch, do the necessary changes (including modify > javax.faces.* classes to match the spec draft, but only the necessary > for windowId feature), and then if that is not enough do the backport. > > The whole point of this is provide "something" to try windowId feature > and check if everything is correct before JSF 2.2 is out, right?. In > that sense, I think do a milestone release is a good compromise. When > JSF 2.2 is out, we can do an official release and applications using > these artifacts will just jump to 2.2. > > In my opinion, there are still many things to make clear before try a > backport. How the implementation should behave? there are many ways to > do it and each one with different trade-offs. > > I'm still worried about create some classes in MyFaces, tell people to > use them and later change them without warning just because something > needs to be fixed. With a milestone release, the message is clear: > "... this is just JSF 2.1 + windowId proposal for JSF 2.2, so the > implementation here is not final and can change at any moment ...". > > ... Easy to do, hard to correct ... > > regards, > > Leonardo Uribe > > 2012/7/31 Gerhard Petracek <[email protected]>: > > hi leo, > > > > i'm not sure if we really need such releases. > > if it is easier for you to start with the official api of v2.2 and to > > backport it afterwards, it's imo also ok to create a branch for it. > > in this case we might have to drop (or refactor) this branch later on, > > because the final ClientWindow implementation for v2.2 should just > delegate > > to the myfaces specific api (if possible) to allow an easier sync. > > > > regards, > > gerhard > > > > http://www.irian.at > > > > Your JSF/JavaEE powerhouse - > > JavaEE Consulting, Development and > > Courses in English and German > > > > Professional Support for Apache MyFaces > > > > > > > > 2012/7/31 Leonardo Uribe <[email protected]> > >> > >> Hi > >> > >> There is an alternative to do it for 2.0.x / 2.1.x . We can create a > >> temporal 2.2.x branch that will only contain JSF 2.1 + JSF 2.2 > >> windowId API and then we do milestones releases, which does not > >> require to be official (no TCK), with some additional identifier. For > >> example myfaces-bundle-2.2.0-mr-1w.jar or something like that. > >> > >> In this way, we can just implement the proposal we have for JSF 2.2, > >> and people could try it, but we avoid the overhead involved in > >> implement myfaces specific hacks for 2.1. Later, we can backport it to > >> JSF 2.1(optional), but only after we have a clear idea about how the > >> implementation should work, and how we can backport it. Does that > >> sounds reasonable? > >> > >> regards, > >> > >> Leonardo Uribe > >> > >> 2012/7/23 Gerhard Petracek <[email protected]>: > >> > hi @ all, > >> > > >> > if there are no objections, i'll create a jira ticket for it tomorrow. > >> > > >> > regards, > >> > gerhard > >> > > >> > http://www.irian.at > >> > > >> > Your JSF/JavaEE powerhouse - > >> > JavaEE Consulting, Development and > >> > Courses in English and German > >> > > >> > Professional Support for Apache MyFaces > >> > > >> > > >> > > >> > > >> > 2012/7/20 David Blevins <[email protected]> > >> >> > >> >> > >> >> On Jul 19, 2012, at 2:49 AM, Mark Struberg wrote: > >> >> > The internal API will be 1:1 sync with the proposed javax.faces > API - > >> >> > we > >> >> > are just not allowed to do it directly in javax.faces before it's > >> >> > official. > >> >> > >> >> Sounds great. Only reason I ask was the TCK gets cranky when you > >> >> change > >> >> the API signatures. But this proposed approach sounds like a nice > >> >> compromise. > >> >> > >> >> Very workable. > >> >> > >> >> > >> >> -David > >> >> > >> > > > > > >
