myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leonardo Uribe <lu4...@gmail.com>
Subject Re: [DISCUSS] [Core] window-id for myfaces-core 2.0.x and 2.1.x
Date Wed, 01 Aug 2012 12:53:45 GMT
Hi

2012/7/31 Gerhard Petracek <gerhard.petracek@gmail.com>:
> 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 <lu4242@gmail.com>
>>
>> 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 <gerhard.petracek@gmail.com>:
>> > 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 <lu4242@gmail.com>
>> >>
>> >> 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 <gerhard.petracek@gmail.com>:
>> >> > 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 <david.blevins@gmail.com>
>> >> >>
>> >> >>
>> >> >> 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
>> >> >>
>> >> >
>> >
>> >
>
>

Mime
View raw message