hi leo, since the goal is that the myfaces specific api should be aligned with the jsf 2.2 api, the only difference should be the package and the lookup e.g. of ClientWindow -> there isn't a big difference at all. which means in return: there's also no issue with starting with the jsf 2.2 api -> just continue, if you prefer it that way.
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/8/1 Leonardo Uribe <[email protected]> > Hi > > 2012/7/31 Gerhard Petracek <[email protected]>: > > 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. > > > > I'm not proposing to do not do it for 2.0.x / 2.1.x . Instead, I'm > proposing to start implementing the javadoc proposed in the early > draft review : > > http://jcp.org/en/jsr/detail?id=344 > > Later, when we have a clear idea about how the implementation should > work, we can think about how to do a backport for 2.0.x / 2.1.x. > > > 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. > > > > I think a good plan is: > > 1. Create a 2.1.x branch (2.1.x-client-window), set versions to > 2.1.9-CLIENT-WINDOW-SNAPSHOT and work in a implementation, following > JSF 2.2 early draft javadoc, taking as base what we have in MyFaces > CODI and previous discussions in the wiki. > 2. Try it, create examples and see how it works and correct what's > necessary. > 3. Only when the implementation is clear, propose a backport to be > included in 2.1.x . > > In this way, we minimize the effort involved, because the code in the > branch could be easily included later in MyFaces 2.2, and we ensure > the implementation in 2.1.x is aligned with the spec (test this stuff > will take some time, and if another draft of the spec is out in that > time, we can check it and synchronize it with our code). > > If no objections I'll start with the necessary steps. > > regards, > > Leonardo Uribe > > > 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 > >> >> >> > >> >> > > >> > > >> > > > > > >
