+1
On Wed, Aug 1, 2012 at 4:05 PM, Gerhard Petracek <[email protected]> wrote: > 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 >> >> >> >> >> >> >> > >> >> > >> >> > >> > >> > > >
