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 >> >> >> > > >
