You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Michael Concini <mc...@gmail.com> on 2009/02/24 21:38:34 UTC
MyFaces 2.0 development going forward
Now that the JSF 2.0 spec is getting closer to completion, I think it
would be a good idea for some more planning to go into the development
process for the MyFaces 2.0 release going forward. There are several
aspects of this that need to be addressed.
First, regarding the changes/additions to the JSF spec. Is anyone
keeping track somewhere of which changes have JIRA issues attached
versus those that still need to have new issues created? It is getting
to be hard to determine what changes might still not have issues
attached at this point as the number of JIRA issues associated with the
2.0 spec approaches 200.
Second, I think it would be very helpful to put together a more detailed
road map of when we want to target specific changes and features. I
think a good example of how we might want to do this is what
OpenWebBeans is doing in their road map
<https://issues.apache.org/jira/secure/BrowseProject.jspa?id=12310844&subset=-1>.
They've outlined exactly what is being planned for the upcoming
milestone work. I know something like this would be very useful to my
team at IBM in determining which work is best for us to take on in any
milestone period.
I also think it would be a good idea to come up with a more formal way
of keeping track of who is working on which items. As more folks become
involved, its going to become more and more likely that we'll step on
each other's toes.
Does anyone have thoughts on any of the above? I'd be glad to work with
someone from the PMC to assist in any of the required planning.
Thanks,
Mike Concini
Re: MyFaces 2.0 development going forward
Posted by Werner Punz <we...@gmail.com>.
jankeesvanandel@gmail.com schrieb:
> I'm currently working on the annotation processing stuff (@ManagedBean,
> @ManagedProperty...). Already made a first attempt for the managed
> beans, but there is still some work to do (converters, components, event
> listeners, etc). I hope I can apply the same logic for those other
> components as well.
>
> With Werner working on Ajax and Simon on Facelets, we already cover a
> large portion of JSF2. Facelets is big, though, since it also contains
> tags for all components, EZComp, JSF2-Facelets/Original-Facelets
> switching, etc... Resource handling/relocation is also a mandatory
> requirement for Ajax to work.
>
My main problem the last few weeks was that I was assigned to another
task which bound me for 100% I hope to have again at least one day per
week beginning from this week to finish the client side ajax part.
We are on the client side currently at 70% :-), most of the
roundtripping is implemented on the client side, the response handling
still is missing! Btw. I ditched the Trinidad xhr code (I made it
switchable so you for now still can use it).
The reason was, the Trinidad code had so many things in, which is not
needed by the specs which made the code hard to maintain,
that a small clean room transport made more sense to keep the codebase
leaner.
Some parts of the Trinidad xhr code still live in the new codebase, the
form value encoding for instance. But for now there is not too much
needed from the Trinidad codebase. I have not seen the latest spec, but
the entire iframe aspects were not there, because no direct form submit
was done, xhr transport only and that one queued and asynchronously
only. By removing the trinidad codebase, I could trim the entire XHR
codebase down by 70%, so it made sense to do it!
For now I have both transports with a small adapter layer on top of it
to hook it into jsf2 but I am not sure if we keep the Trinidad codebase.
As for the server side, the main issue there is we have to do a
specialized responsewriter, which pretty much Trinidad does already!
But I do not consider that too much work!
Werner
Re: Re: MyFaces 2.0 development going forward
Posted by Matthias Wessendorf <ma...@apache.org>.
>
> About Shale-test, is it right to use Shale classes in MyFaces Core? Of
> course it's just the unit tests, but in some way it's still a cyclic
> dependency which is usually a bad thing...
but you don't relay on the testing framework for runtime.
So, yes using shale to fire the unit tests is valid. Well
it is part of the build (already today)
-M
>
> /Jan-Kees
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
Re: MyFaces 2.0 development going forward
Posted by Matthias Wessendorf <ma...@apache.org>.
Yes, that's for sharing details, e.g. stack trace on failure (from the TCK).
That doesn't mean you can't submit a "descriptive" jira ticket ;-)
-Matthias
On Sun, Mar 1, 2009 at 8:09 PM, Michael Concini <mc...@gmail.com> wrote:
> I got a response back from our legal, and any usage of the TCK must be
> appropriately related to IBM products. So you're right that we can't share
> results. Sorry for any misunderstanding on that.
>
> Matthias Wessendorf wrote:
>
> On Thu, Feb 26, 2009 at 6:10 PM, Michael Concini <mc...@gmail.com> wrote:
>
>
> I'll have to check on what the deal is with the tck results. I'm not sure
> what our current license conditions are with Sun (not my area of
> expertise). I'll let you know what I find out from our legal team.
>
>
> cool. There is an "jcp-open" (jcp-open@apache.org) list on Apache,
> which you may want
> to ping as well, to inform them about your conditions on that TCK thing.
>
> -Matthias
>
>
>
> Matthias Wessendorf wrote:
>
> Not sure what you mean by "combing a committer". As far as the TCK is
>
>
> whoops. Typo... becoming :-)
>
>
>
> concerned though, we will have immediate access to the TCK at IBM once Sun
> releases it. We'd be happy to run any alpha, beta and eventually final
> releases of MyFaces 2.0 through the tck and work on fixing those bugs.
>
>
> IMO that's fine, but you can't share the results if I remember correctly
>
>
>
> I also think it would be a good idea to come up with a more formal way
> of
> keeping track of who is working on which items. As more folks become
> involved, its going to become more and more likely that we'll step on
> each
> other's toes.
>
>
> I agree, but JIRA only allows to assign ticket to commiters and I don't
> have
> anything better than adding a comment to the ticket for now. If you have
> a
> better idea it would be welcome.
>
>
> Perhaps we could use the wiki ? Like creating an umbrella MyFaces 2.0
> items wiki
> page, which "links" the all the subtasks / issues .
>
>
>
> Using the wiki may not be a bad idea. If we were to do that though, one
> thing that would be of great help to my team at least would be to have the
> work items mapped back to the changes in the spec where possible. Even
> something as simple as an which section/subsection the change comes from.
> I'd be happy to help out with that work, but I would guess Simon or someone
> from his team could do it more efficiently since they did the initial
> breakdown of the work into the JIRA issues.
>
>
> I think so too. We can add that info to the wiki. something like:
>
> ISSUE NAME MYFACES JIRA SPEC ISSUE
> implement blah MYFACES-1234 SPEC-789 (all are linked to
> the real resources)
>
> -M
>
>
>
>
> Does anyone have thoughts on any of the above? I'd be glad to work
> with
> someone from the PMC to assist in any of the required planning.
>
>
> Michael, the right channel to communicate on the development of Apache
> MyFaces
> is this mailing list. If you/your team has questions, the best is to
> use something
> like [myfaces 2.0] in the beginning of the subject, so a mail can be
> filtered easily.
> We usually use other resources, like JIRA or the MyFaces wiki ([2]) to
> "organize"
> the work. You can create an account on those services and contribute some
> work
> there as well.
>
> If you have more questions, please ask them here, as the community is more
> than
> willing to answer them.
>
> -Matthias
>
> [1] http://www.apache.org/jcp/sunopenletter.html
> [2] http://wiki.apache.org/myfaces/
>
>
>
> Thanks,
> Mike Concini
>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
>
>
>
>
>
>
>
>
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
Re: MyFaces 2.0 development going forward
Posted by Michael Concini <mc...@gmail.com>.
I got a response back from our legal, and any usage of the TCK must be
appropriately related to IBM products. So you're right that we can't
share results. Sorry for any misunderstanding on that.
Matthias Wessendorf wrote:
> On Thu, Feb 26, 2009 at 6:10 PM, Michael Concini <mc...@gmail.com> wrote:
>
>> I'll have to check on what the deal is with the tck results. I'm not sure
>> what our current license conditions are with Sun (not my area of
>> expertise). I'll let you know what I find out from our legal team.
>>
>
> cool. There is an "jcp-open" (jcp-open@apache.org) list on Apache,
> which you may want
> to ping as well, to inform them about your conditions on that TCK thing.
>
> -Matthias
>
>
>> Matthias Wessendorf wrote:
>>
>> Not sure what you mean by "combing a committer". As far as the TCK is
>>
>>
>> whoops. Typo... becoming :-)
>>
>>
>>
>> concerned though, we will have immediate access to the TCK at IBM once Sun
>> releases it. We'd be happy to run any alpha, beta and eventually final
>> releases of MyFaces 2.0 through the tck and work on fixing those bugs.
>>
>>
>> IMO that's fine, but you can't share the results if I remember correctly
>>
>>
>>
>> I also think it would be a good idea to come up with a more formal way
>> of
>> keeping track of who is working on which items. As more folks become
>> involved, its going to become more and more likely that we'll step on
>> each
>> other's toes.
>>
>>
>> I agree, but JIRA only allows to assign ticket to commiters and I don't
>> have
>> anything better than adding a comment to the ticket for now. If you have
>> a
>> better idea it would be welcome.
>>
>>
>> Perhaps we could use the wiki ? Like creating an umbrella MyFaces 2.0
>> items wiki
>> page, which "links" the all the subtasks / issues .
>>
>>
>>
>> Using the wiki may not be a bad idea. If we were to do that though, one
>> thing that would be of great help to my team at least would be to have the
>> work items mapped back to the changes in the spec where possible. Even
>> something as simple as an which section/subsection the change comes from.
>> I'd be happy to help out with that work, but I would guess Simon or someone
>> from his team could do it more efficiently since they did the initial
>> breakdown of the work into the JIRA issues.
>>
>>
>> I think so too. We can add that info to the wiki. something like:
>>
>> ISSUE NAME MYFACES JIRA SPEC ISSUE
>> implement blah MYFACES-1234 SPEC-789 (all are linked to
>> the real resources)
>>
>> -M
>>
>>
>>
>>
>> Does anyone have thoughts on any of the above? I'd be glad to work
>> with
>> someone from the PMC to assist in any of the required planning.
>>
>>
>> Michael, the right channel to communicate on the development of Apache
>> MyFaces
>> is this mailing list. If you/your team has questions, the best is to
>> use something
>> like [myfaces 2.0] in the beginning of the subject, so a mail can be
>> filtered easily.
>> We usually use other resources, like JIRA or the MyFaces wiki ([2]) to
>> "organize"
>> the work. You can create an account on those services and contribute some
>> work
>> there as well.
>>
>> If you have more questions, please ask them here, as the community is more
>> than
>> willing to answer them.
>>
>> -Matthias
>>
>> [1] http://www.apache.org/jcp/sunopenletter.html
>> [2] http://wiki.apache.org/myfaces/
>>
>>
>>
>> Thanks,
>> Mike Concini
>>
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>>
>>
>>
>>
>>
>>
>>
>
>
>
>
Re: MyFaces 2.0 development going forward
Posted by Matthias Wessendorf <ma...@apache.org>.
On Thu, Feb 26, 2009 at 6:10 PM, Michael Concini <mc...@gmail.com> wrote:
> I'll have to check on what the deal is with the tck results. I'm not sure
> what our current license conditions are with Sun (not my area of
> expertise). I'll let you know what I find out from our legal team.
cool. There is an "jcp-open" (jcp-open@apache.org) list on Apache,
which you may want
to ping as well, to inform them about your conditions on that TCK thing.
-Matthias
>
> Matthias Wessendorf wrote:
>
> Not sure what you mean by "combing a committer". As far as the TCK is
>
>
> whoops. Typo... becoming :-)
>
>
>
> concerned though, we will have immediate access to the TCK at IBM once Sun
> releases it. We'd be happy to run any alpha, beta and eventually final
> releases of MyFaces 2.0 through the tck and work on fixing those bugs.
>
>
> IMO that's fine, but you can't share the results if I remember correctly
>
>
>
> I also think it would be a good idea to come up with a more formal way
> of
> keeping track of who is working on which items. As more folks become
> involved, its going to become more and more likely that we'll step on
> each
> other's toes.
>
>
> I agree, but JIRA only allows to assign ticket to commiters and I don't
> have
> anything better than adding a comment to the ticket for now. If you have
> a
> better idea it would be welcome.
>
>
> Perhaps we could use the wiki ? Like creating an umbrella MyFaces 2.0
> items wiki
> page, which "links" the all the subtasks / issues .
>
>
>
> Using the wiki may not be a bad idea. If we were to do that though, one
> thing that would be of great help to my team at least would be to have the
> work items mapped back to the changes in the spec where possible. Even
> something as simple as an which section/subsection the change comes from.
> I'd be happy to help out with that work, but I would guess Simon or someone
> from his team could do it more efficiently since they did the initial
> breakdown of the work into the JIRA issues.
>
>
> I think so too. We can add that info to the wiki. something like:
>
> ISSUE NAME MYFACES JIRA SPEC ISSUE
> implement blah MYFACES-1234 SPEC-789 (all are linked to
> the real resources)
>
> -M
>
>
>
>
> Does anyone have thoughts on any of the above? I'd be glad to work
> with
> someone from the PMC to assist in any of the required planning.
>
>
> Michael, the right channel to communicate on the development of Apache
> MyFaces
> is this mailing list. If you/your team has questions, the best is to
> use something
> like [myfaces 2.0] in the beginning of the subject, so a mail can be
> filtered easily.
> We usually use other resources, like JIRA or the MyFaces wiki ([2]) to
> "organize"
> the work. You can create an account on those services and contribute some
> work
> there as well.
>
> If you have more questions, please ask them here, as the community is more
> than
> willing to answer them.
>
> -Matthias
>
> [1] http://www.apache.org/jcp/sunopenletter.html
> [2] http://wiki.apache.org/myfaces/
>
>
>
> Thanks,
> Mike Concini
>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
>
>
>
>
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
Re: MyFaces 2.0 development going forward
Posted by Matthias Wessendorf <ma...@apache.org>.
On Thu, Feb 26, 2009 at 6:10 PM, Michael Concini <mc...@gmail.com> wrote:
> I'll have to check on what the deal is with the tck results. I'm not sure
> what our current license conditions are with Sun (not my area of
> expertise). I'll let you know what I find out from our legal team.
cool. There is an "jcp-open" (jcp-open@apache.org) list on Apache,
which you may want
to ping as well, to inform them about your conditions on that TCK thing.
-Matthias
>
> Matthias Wessendorf wrote:
>
> Not sure what you mean by "combing a committer". As far as the TCK is
>
>
> whoops. Typo... becoming :-)
>
>
>
> concerned though, we will have immediate access to the TCK at IBM once Sun
> releases it. We'd be happy to run any alpha, beta and eventually final
> releases of MyFaces 2.0 through the tck and work on fixing those bugs.
>
>
> IMO that's fine, but you can't share the results if I remember correctly
>
>
>
> I also think it would be a good idea to come up with a more formal way
> of
> keeping track of who is working on which items. As more folks become
> involved, its going to become more and more likely that we'll step on
> each
> other's toes.
>
>
> I agree, but JIRA only allows to assign ticket to commiters and I don't
> have
> anything better than adding a comment to the ticket for now. If you have
> a
> better idea it would be welcome.
>
>
> Perhaps we could use the wiki ? Like creating an umbrella MyFaces 2.0
> items wiki
> page, which "links" the all the subtasks / issues .
>
>
>
> Using the wiki may not be a bad idea. If we were to do that though, one
> thing that would be of great help to my team at least would be to have the
> work items mapped back to the changes in the spec where possible. Even
> something as simple as an which section/subsection the change comes from.
> I'd be happy to help out with that work, but I would guess Simon or someone
> from his team could do it more efficiently since they did the initial
> breakdown of the work into the JIRA issues.
>
>
> I think so too. We can add that info to the wiki. something like:
>
> ISSUE NAME MYFACES JIRA SPEC ISSUE
> implement blah MYFACES-1234 SPEC-789 (all are linked to
> the real resources)
>
> -M
>
>
>
>
> Does anyone have thoughts on any of the above? I'd be glad to work
> with
> someone from the PMC to assist in any of the required planning.
>
>
> Michael, the right channel to communicate on the development of Apache
> MyFaces
> is this mailing list. If you/your team has questions, the best is to
> use something
> like [myfaces 2.0] in the beginning of the subject, so a mail can be
> filtered easily.
> We usually use other resources, like JIRA or the MyFaces wiki ([2]) to
> "organize"
> the work. You can create an account on those services and contribute some
> work
> there as well.
>
> If you have more questions, please ask them here, as the community is more
> than
> willing to answer them.
>
> -Matthias
>
> [1] http://www.apache.org/jcp/sunopenletter.html
> [2] http://wiki.apache.org/myfaces/
>
>
>
> Thanks,
> Mike Concini
>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
>
>
>
>
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
Re: MyFaces 2.0 development going forward
Posted by Michael Concini <mc...@gmail.com>.
I'll have to check on what the deal is with the tck results. I'm not
sure what our current license conditions are with Sun (not my area of
expertise). I'll let you know what I find out from our legal team.
Matthias Wessendorf wrote:
>> Not sure what you mean by "combing a committer". As far as the TCK is
>>
>
> whoops. Typo... becoming :-)
>
>
>> concerned though, we will have immediate access to the TCK at IBM once Sun
>> releases it. We'd be happy to run any alpha, beta and eventually final
>> releases of MyFaces 2.0 through the tck and work on fixing those bugs.
>>
>
> IMO that's fine, but you can't share the results if I remember correctly
>
>
>>>>> I also think it would be a good idea to come up with a more formal way
>>>>> of
>>>>> keeping track of who is working on which items. As more folks become
>>>>> involved, its going to become more and more likely that we'll step on
>>>>> each
>>>>> other's toes.
>>>>>
>>>> I agree, but JIRA only allows to assign ticket to commiters and I don't
>>>> have
>>>> anything better than adding a comment to the ticket for now. If you have
>>>> a
>>>> better idea it would be welcome.
>>>>
>>> Perhaps we could use the wiki ? Like creating an umbrella MyFaces 2.0
>>> items wiki
>>> page, which "links" the all the subtasks / issues .
>>>
>>>
>> Using the wiki may not be a bad idea. If we were to do that though, one
>> thing that would be of great help to my team at least would be to have the
>> work items mapped back to the changes in the spec where possible. Even
>> something as simple as an which section/subsection the change comes from.
>> I'd be happy to help out with that work, but I would guess Simon or someone
>> from his team could do it more efficiently since they did the initial
>> breakdown of the work into the JIRA issues.
>>
>
> I think so too. We can add that info to the wiki. something like:
>
> ISSUE NAME MYFACES JIRA SPEC ISSUE
> implement blah MYFACES-1234 SPEC-789 (all are linked to
> the real resources)
>
> -M
>
>
>
>>>>> Does anyone have thoughts on any of the above? I'd be glad to work
>>>>> with
>>>>> someone from the PMC to assist in any of the required planning.
>>>>>
>>> Michael, the right channel to communicate on the development of Apache
>>> MyFaces
>>> is this mailing list. If you/your team has questions, the best is to
>>> use something
>>> like [myfaces 2.0] in the beginning of the subject, so a mail can be
>>> filtered easily.
>>> We usually use other resources, like JIRA or the MyFaces wiki ([2]) to
>>> "organize"
>>> the work. You can create an account on those services and contribute some
>>> work
>>> there as well.
>>>
>>> If you have more questions, please ask them here, as the community is more
>>> than
>>> willing to answer them.
>>>
>>> -Matthias
>>>
>>> [1] http://www.apache.org/jcp/sunopenletter.html
>>> [2] http://wiki.apache.org/myfaces/
>>>
>>>
>>>>> Thanks,
>>>>> Mike Concini
>>>>>
>>>>
>>>
>>> --
>>> Matthias Wessendorf
>>>
>>> blog: http://matthiaswessendorf.wordpress.com/
>>> sessions: http://www.slideshare.net/mwessendorf
>>> twitter: http://twitter.com/mwessendorf
>>>
>>
>>
>
>
>
>
Re: MyFaces 2.0 development going forward
Posted by Matthias Wessendorf <ma...@apache.org>.
>
> Not sure what you mean by "combing a committer". As far as the TCK is
whoops. Typo... becoming :-)
> concerned though, we will have immediate access to the TCK at IBM once Sun
> releases it. We'd be happy to run any alpha, beta and eventually final
> releases of MyFaces 2.0 through the tck and work on fixing those bugs.
IMO that's fine, but you can't share the results if I remember correctly
>
>> >
>> >>
>> >> I also think it would be a good idea to come up with a more formal way
>> >> of
>> >> keeping track of who is working on which items. As more folks become
>> >> involved, its going to become more and more likely that we'll step on
>> >> each
>> >> other's toes.
>> >
>> > I agree, but JIRA only allows to assign ticket to commiters and I don't
>> > have
>> > anything better than adding a comment to the ticket for now. If you have
>> > a
>> > better idea it would be welcome.
>>
>> Perhaps we could use the wiki ? Like creating an umbrella MyFaces 2.0
>> items wiki
>> page, which "links" the all the subtasks / issues .
>>
> Using the wiki may not be a bad idea. If we were to do that though, one
> thing that would be of great help to my team at least would be to have the
> work items mapped back to the changes in the spec where possible. Even
> something as simple as an which section/subsection the change comes from.
> I'd be happy to help out with that work, but I would guess Simon or someone
> from his team could do it more efficiently since they did the initial
> breakdown of the work into the JIRA issues.
I think so too. We can add that info to the wiki. something like:
ISSUE NAME MYFACES JIRA SPEC ISSUE
implement blah MYFACES-1234 SPEC-789 (all are linked to
the real resources)
-M
>>
>> >
>> >>
>> >> Does anyone have thoughts on any of the above? I'd be glad to work
>> >> with
>> >> someone from the PMC to assist in any of the required planning.
>>
>> Michael, the right channel to communicate on the development of Apache
>> MyFaces
>> is this mailing list. If you/your team has questions, the best is to
>> use something
>> like [myfaces 2.0] in the beginning of the subject, so a mail can be
>> filtered easily.
>> We usually use other resources, like JIRA or the MyFaces wiki ([2]) to
>> "organize"
>> the work. You can create an account on those services and contribute some
>> work
>> there as well.
>>
>> If you have more questions, please ask them here, as the community is more
>> than
>> willing to answer them.
>>
>> -Matthias
>>
>> [1] http://www.apache.org/jcp/sunopenletter.html
>> [2] http://wiki.apache.org/myfaces/
>>
>> >>
>> >> Thanks,
>> >> Mike Concini
>> >
>> >
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>
>
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
Re: MyFaces 2.0 development going forward
Posted by Michael Concini <mc...@gmail.com>.
Thanks for the responses so far. Comments in-line (in blue text).
Simon Lessard wrote:
> Hi Matthias,
>
> I guess that's a fair point about alpha release, I'll try to think of
> some good milestone.
>
>
> ~ Simon
>
> On Thu, Feb 26, 2009 at 2:25 AM, Matthias Wessendorf
> <matzew@apache.org <ma...@apache.org>> wrote:
>
> Hi
>
> On Tue, Feb 24, 2009 at 9:50 PM, Simon Lessard
> <simon.lessard.3@gmail.com <ma...@gmail.com>> wrote:
> > Hi Michael,
> >
> > See inline.
> >
> >
> > Regards,
> >
> > ~ Simon
> >
> > On Tue, Feb 24, 2009 at 3:38 PM, Michael Concini
> <mconcini@gmail.com <ma...@gmail.com>> wrote:
> >>
> >> Now that the JSF 2.0 spec is getting closer to completion, I
> think it
> >> would be a good idea for some more planning to go into the
> development
> >> process for the MyFaces 2.0 release going forward. There are
> several
> >> aspects of this that need to be addressed.
> >>
> >> First, regarding the changes/additions to the JSF spec. Is
> anyone keeping
> >> track somewhere of which changes have JIRA issues attached
> versus those that
> >> still need to have new issues created? It is getting to be
> hard to
> >> determine what changes might still not have issues attached at
> this point as
> >> the number of JIRA issues associated with the 2.0 spec
> approaches 200.
> >
> > The tickets matching the public review are all created. I'll do
> another
> > roundtrip with my team when the final spec is released to create
> the missing
> > ones. Basically Werner is working on the JavaScript API,
> Leonardo and
> > Jan-Kees help in various areas, I'm currently working on integrating
> > Facelets and my teammate are helping me with that. One MAJOR
> issue that we
> > have right now are unit tests. Leonardo proposed to attack that
> one, but
> > since Shale might change his mind about the future of
> Shale-test, I asked
> > him to postpone dealing with it just in case so that we don't
> have to work
> > on that issue for nothing.
>
> this maybe a bit off-topic, but we should start to put the shale-test
> into myfaces.
> Simon, I will write the (required) mail to the shale dev list and will
> let the folks
> here know about the outcome.
>
> >
> >>
> >> Second, I think it would be very helpful to put together a more
> detailed
> >> road map of when we want to target specific changes and
> features. I think a
> >> good example of how we might want to do this is what
> OpenWebBeans is doing
> >> in their road map. They've outlined exactly what is being
> planned for the
> >> upcoming milestone work. I know something like this would be
> very useful to
> >> my team at IBM in determining which work is best for us to take
> on in any
> >> milestone period.
> >
> > I don't know if milestones are relevant when implementing a spec
> considering
> > what has to be done is fixed and static. I don't see any release
> coming not
> > passing the TCK, thus not implementing everything needed.
>
> I think that some users/contributors would appreciate a milestone or
> an alpha release.
> Once we release something that hasn't passed the TCK we have to call
> that aplha/milestone.
> Geronimo did this in the past and so does the openwebbeans podling. I
> wonder if we already
> asked for a TCK, and I am not sure if that has TCK has some fields of
> use restrictions (see [1] for
> a larger discussion on the field of use restrictions). But we should
> definitely ping SUN. Let me
> take on that part.
>
> Michael, if you are combing a committer (by providing patches) you can
> also get access to run
> the TCK (after signing a NDA) on your side. ;-)
>
Not sure what you mean by "combing a committer". As far as the TCK is
concerned though, we will have immediate access to the TCK at IBM once
Sun releases it. We'd be happy to run any alpha, beta and eventually
final releases of MyFaces 2.0 through the tck and work on fixing those
bugs.
> >
> >>
> >> I also think it would be a good idea to come up with a more
> formal way of
> >> keeping track of who is working on which items. As more folks
> become
> >> involved, its going to become more and more likely that we'll
> step on each
> >> other's toes.
> >
> > I agree, but JIRA only allows to assign ticket to commiters and
> I don't have
> > anything better than adding a comment to the ticket for now. If
> you have a
> > better idea it would be welcome.
>
> Perhaps we could use the wiki ? Like creating an umbrella MyFaces
> 2.0 items wiki
> page, which "links" the all the subtasks / issues .
>
Using the wiki may not be a bad idea. If we were to do that though, one
thing that would be of great help to my team at least would be to have
the work items mapped back to the changes in the spec where possible.
Even something as simple as an which section/subsection the change comes
from. I'd be happy to help out with that work, but I would guess Simon
or someone from his team could do it more efficiently since they did the
initial breakdown of the work into the JIRA issues.
>
> >
> >>
> >> Does anyone have thoughts on any of the above? I'd be glad to
> work with
> >> someone from the PMC to assist in any of the required planning.
>
> Michael, the right channel to communicate on the development of
> Apache MyFaces
> is this mailing list. If you/your team has questions, the best is to
> use something
> like [myfaces 2.0] in the beginning of the subject, so a mail can be
> filtered easily.
> We usually use other resources, like JIRA or the MyFaces wiki ([2]) to
> "organize"
> the work. You can create an account on those services and
> contribute some work
> there as well.
>
> If you have more questions, please ask them here, as the community
> is more than
> willing to answer them.
>
> -Matthias
>
> [1] http://www.apache.org/jcp/sunopenletter.html
> [2] http://wiki.apache.org/myfaces/
>
> >>
> >> Thanks,
> >> Mike Concini
> >
> >
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
>
Re: MyFaces 2.0 development going forward
Posted by Leonardo Uribe <lu...@gmail.com>.
Hi
The list is fine. I'll be happy to help with 2.0 as soon as the code is
committed.
regards
Leonardo Uribe
On Tue, Mar 17, 2009 at 7:51 AM, Simon Lessard <si...@gmail.com>wrote:
> Hi Matthias and all,
>
> Yes I could add it to a wiki, but I think I'll have to revisit what will be
> required per alpha release as I'm currently implementing latest spec
> snapshot on the MyFaces base (cannot commit it yet since it's not public
> though) and there are more change on that version than between 1.2 and the
> first early draft. So far I added in the codes 2 kinds of TODO:
>
> // TODO: IMPLEMENT API
> and
> // TODO: IMPLEMENT IMPL
>
> where the first mean that there's missing code in myfaces-api (new non
> abstract method or modified contract) and the second means that the method
> should be added on the myfaces-impl side (mainly new methods that throws the
> really crappy UnsupportedOperationException). I didn't create JIRA tickets
> for now, but from previous experience I think it should rather be a per
> classe basis instead of a per todo basis that I first used for 2.0.
>
> As for the big lines of 2.0, I see the following high level modules:
>
> - Facelets PDL
> - Resource API
> - JavaScript API
> - SystemEvent API
> - Error handling API (and run through existing classes to make sure the
> new exception specification is enforced)
> - Tree visiting API
> - Partial view API
> - Annotation support
> - New tags (mostly linked to Facelets)
> - New validators (Bean and regex mainly)
> - Unit tests
> - Utility methods (ExternalContext mainly)
> - Config ordering
>
> Am I missing anything? Also, assuming this list is correct, would it be
> acceptable to base the alpha releases on full implementation of some of
> those modules? I thknk there's more or less 3 teams working at the same time
> on 2.0, so maybe we could implement 2 modules per release (in case one team
> is less active during a given release cycle)?
>
>
> Regards,
>
> ~ Simon
>
>
>
> On Thu, Feb 26, 2009 at 1:06 PM, Matthias Wessendorf <ma...@apache.org>wrote:
>
>> Simon,
>>
>> can you add that content to a wiki ?
>>
>> -Matthias
>>
>> On Thu, Feb 26, 2009 at 6:03 PM, Simon Lessard
>> <si...@gmail.com> wrote:
>> > Hi Micheal,
>> >
>> > Help on Facelets would be most welcome, it's quite big and not a code
>> base I
>> > know that much. I can see 6 main tasks to that integration, 4 required
>> and 2
>> > nice to have:
>> >
>> > Relink the classes to JSF 2.0 FaceletContext and other Facelets API from
>> > myfaces-api. 100% done.
>> > Package renaming. Someone suggested to keep the same names before, but
>> that
>> > won't work as JSF 2.0 must work if you drop in the latest Facelets JAR
>> and
>> > keeping the same names would imply some name clashes. So we have to
>> figure
>> > out either where to place each sub module or keep it with the original
>> > structure but with different root packages. 0% done.
>> > Set Facelets as the default ViewHandler (as of JSF 2.0 Facelets
>> superceede
>> > JSP). 0% done.
>> > Since I used the latest Facelets code for integration, there's already
>> some
>> > difference between the spec and Facelets, namely with FaceletHandler
>> where
>> > the API only has the apply method while latest Facelets uses
>> > applyDefinition. Therefore, we have to revert the Facelets code back to
>> > apply only and get rid of the applyDefinition code. 30% done.
>> > Convert Facelets to Java 5+ (generics). 50% done. This is a nice to
>> have,
>> > but I use this task to get comfortable with the code base at the same
>> time.
>> > Get rid of the JSF version code switches. Facelets sometimes switch
>> between
>> > "Facelets" EL and "native" EL based on the current JSF version to
>> support EL
>> > in JSF 1.1 mainly. However, in MyFaces 2.0, this is irrelevant and a
>> > performance overhaul so we need to get rid of that and always use
>> "native"
>> > EL. 99% done. (I think I've got them all already, but I need to do
>> another
>> > run on it to be sure)
>> >
>> > Points 2, 3, 4 are the ones I need the most help with. For 4. we started
>> > fixing it using the JIRA tickets about the various Facelets tags for
>> patch
>> > attachment purposes.
>> >
>> >
>> > Regards,
>> >
>> > ~ Simon
>> >
>> > On Thu, Feb 26, 2009 at 11:46 AM, Michael Concini <mc...@gmail.com>
>> > wrote:
>> >>
>> >> Good point about the size of the facelets work. Simon, is there part
>> of
>> >> the facelets work that we could pick up for you guys? We're looking to
>> help
>> >> out where our efforts would be most useful instead of just grabbing
>> random
>> >> issues to work on.
>> >> I agree for the most part about your proposed contents for an alpha
>> >> release. I would also like to stress the importance of regression
>> testing
>> >> with JSF 1.1/1.2 apps as part of any alpha release.
>> >> -Mike
>> >>
>> >> jankeesvanandel@gmail.com wrote:
>> >>>
>> >>> I'm currently working on the annotation processing stuff
>> (@ManagedBean,
>> >>> @ManagedProperty...). Already made a first attempt for the managed
>> beans,
>> >>> but there is still some work to do (converters, components, event
>> listeners,
>> >>> etc). I hope I can apply the same logic for those other components as
>> well.
>> >>>
>> >>> With Werner working on Ajax and Simon on Facelets, we already cover a
>> >>> large portion of JSF2. Facelets is big, though, since it also contains
>> tags
>> >>> for all components, EZComp, JSF2-Facelets/Original-Facelets switching,
>> >>> etc... Resource handling/relocation is also a mandatory requirement
>> for Ajax
>> >>> to work.
>> >>>
>> >>> But I think an alpha release should at least contain these essential
>> JSF2
>> >>> components: AJAX, Facelets, annotation based configuration. I think
>> those
>> >>> components are the base of the JSF2 work. Adding in other features
>> should
>> >>> not be too hard when those three are in place properly.
>> >>>
>> >>> About Shale-test, is it right to use Shale classes in MyFaces Core? Of
>> >>> course it's just the unit tests, but in some way it's still a cyclic
>> >>> dependency which is usually a bad thing...
>> >>>
>> >>> /Jan-Kees
>> >>
>> >
>> >
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>>
>
>
Re: MyFaces 2.0 development going forward
Posted by Simon Lessard <si...@gmail.com>.
Hi Matthias and all,
Yes I could add it to a wiki, but I think I'll have to revisit what will be
required per alpha release as I'm currently implementing latest spec
snapshot on the MyFaces base (cannot commit it yet since it's not public
though) and there are more change on that version than between 1.2 and the
first early draft. So far I added in the codes 2 kinds of TODO:
// TODO: IMPLEMENT API
and
// TODO: IMPLEMENT IMPL
where the first mean that there's missing code in myfaces-api (new non
abstract method or modified contract) and the second means that the method
should be added on the myfaces-impl side (mainly new methods that throws the
really crappy UnsupportedOperationException). I didn't create JIRA tickets
for now, but from previous experience I think it should rather be a per
classe basis instead of a per todo basis that I first used for 2.0.
As for the big lines of 2.0, I see the following high level modules:
- Facelets PDL
- Resource API
- JavaScript API
- SystemEvent API
- Error handling API (and run through existing classes to make sure the
new exception specification is enforced)
- Tree visiting API
- Partial view API
- Annotation support
- New tags (mostly linked to Facelets)
- New validators (Bean and regex mainly)
- Unit tests
- Utility methods (ExternalContext mainly)
- Config ordering
Am I missing anything? Also, assuming this list is correct, would it be
acceptable to base the alpha releases on full implementation of some of
those modules? I thknk there's more or less 3 teams working at the same time
on 2.0, so maybe we could implement 2 modules per release (in case one team
is less active during a given release cycle)?
Regards,
~ Simon
On Thu, Feb 26, 2009 at 1:06 PM, Matthias Wessendorf <ma...@apache.org>wrote:
> Simon,
>
> can you add that content to a wiki ?
>
> -Matthias
>
> On Thu, Feb 26, 2009 at 6:03 PM, Simon Lessard
> <si...@gmail.com> wrote:
> > Hi Micheal,
> >
> > Help on Facelets would be most welcome, it's quite big and not a code
> base I
> > know that much. I can see 6 main tasks to that integration, 4 required
> and 2
> > nice to have:
> >
> > Relink the classes to JSF 2.0 FaceletContext and other Facelets API from
> > myfaces-api. 100% done.
> > Package renaming. Someone suggested to keep the same names before, but
> that
> > won't work as JSF 2.0 must work if you drop in the latest Facelets JAR
> and
> > keeping the same names would imply some name clashes. So we have to
> figure
> > out either where to place each sub module or keep it with the original
> > structure but with different root packages. 0% done.
> > Set Facelets as the default ViewHandler (as of JSF 2.0 Facelets
> superceede
> > JSP). 0% done.
> > Since I used the latest Facelets code for integration, there's already
> some
> > difference between the spec and Facelets, namely with FaceletHandler
> where
> > the API only has the apply method while latest Facelets uses
> > applyDefinition. Therefore, we have to revert the Facelets code back to
> > apply only and get rid of the applyDefinition code. 30% done.
> > Convert Facelets to Java 5+ (generics). 50% done. This is a nice to have,
> > but I use this task to get comfortable with the code base at the same
> time.
> > Get rid of the JSF version code switches. Facelets sometimes switch
> between
> > "Facelets" EL and "native" EL based on the current JSF version to support
> EL
> > in JSF 1.1 mainly. However, in MyFaces 2.0, this is irrelevant and a
> > performance overhaul so we need to get rid of that and always use
> "native"
> > EL. 99% done. (I think I've got them all already, but I need to do
> another
> > run on it to be sure)
> >
> > Points 2, 3, 4 are the ones I need the most help with. For 4. we started
> > fixing it using the JIRA tickets about the various Facelets tags for
> patch
> > attachment purposes.
> >
> >
> > Regards,
> >
> > ~ Simon
> >
> > On Thu, Feb 26, 2009 at 11:46 AM, Michael Concini <mc...@gmail.com>
> > wrote:
> >>
> >> Good point about the size of the facelets work. Simon, is there part of
> >> the facelets work that we could pick up for you guys? We're looking to
> help
> >> out where our efforts would be most useful instead of just grabbing
> random
> >> issues to work on.
> >> I agree for the most part about your proposed contents for an alpha
> >> release. I would also like to stress the importance of regression
> testing
> >> with JSF 1.1/1.2 apps as part of any alpha release.
> >> -Mike
> >>
> >> jankeesvanandel@gmail.com wrote:
> >>>
> >>> I'm currently working on the annotation processing stuff (@ManagedBean,
> >>> @ManagedProperty...). Already made a first attempt for the managed
> beans,
> >>> but there is still some work to do (converters, components, event
> listeners,
> >>> etc). I hope I can apply the same logic for those other components as
> well.
> >>>
> >>> With Werner working on Ajax and Simon on Facelets, we already cover a
> >>> large portion of JSF2. Facelets is big, though, since it also contains
> tags
> >>> for all components, EZComp, JSF2-Facelets/Original-Facelets switching,
> >>> etc... Resource handling/relocation is also a mandatory requirement for
> Ajax
> >>> to work.
> >>>
> >>> But I think an alpha release should at least contain these essential
> JSF2
> >>> components: AJAX, Facelets, annotation based configuration. I think
> those
> >>> components are the base of the JSF2 work. Adding in other features
> should
> >>> not be too hard when those three are in place properly.
> >>>
> >>> About Shale-test, is it right to use Shale classes in MyFaces Core? Of
> >>> course it's just the unit tests, but in some way it's still a cyclic
> >>> dependency which is usually a bad thing...
> >>>
> >>> /Jan-Kees
> >>
> >
> >
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
Re: MyFaces 2.0 development going forward
Posted by Matthias Wessendorf <ma...@apache.org>.
Simon,
can you add that content to a wiki ?
-Matthias
On Thu, Feb 26, 2009 at 6:03 PM, Simon Lessard
<si...@gmail.com> wrote:
> Hi Micheal,
>
> Help on Facelets would be most welcome, it's quite big and not a code base I
> know that much. I can see 6 main tasks to that integration, 4 required and 2
> nice to have:
>
> Relink the classes to JSF 2.0 FaceletContext and other Facelets API from
> myfaces-api. 100% done.
> Package renaming. Someone suggested to keep the same names before, but that
> won't work as JSF 2.0 must work if you drop in the latest Facelets JAR and
> keeping the same names would imply some name clashes. So we have to figure
> out either where to place each sub module or keep it with the original
> structure but with different root packages. 0% done.
> Set Facelets as the default ViewHandler (as of JSF 2.0 Facelets superceede
> JSP). 0% done.
> Since I used the latest Facelets code for integration, there's already some
> difference between the spec and Facelets, namely with FaceletHandler where
> the API only has the apply method while latest Facelets uses
> applyDefinition. Therefore, we have to revert the Facelets code back to
> apply only and get rid of the applyDefinition code. 30% done.
> Convert Facelets to Java 5+ (generics). 50% done. This is a nice to have,
> but I use this task to get comfortable with the code base at the same time.
> Get rid of the JSF version code switches. Facelets sometimes switch between
> "Facelets" EL and "native" EL based on the current JSF version to support EL
> in JSF 1.1 mainly. However, in MyFaces 2.0, this is irrelevant and a
> performance overhaul so we need to get rid of that and always use "native"
> EL. 99% done. (I think I've got them all already, but I need to do another
> run on it to be sure)
>
> Points 2, 3, 4 are the ones I need the most help with. For 4. we started
> fixing it using the JIRA tickets about the various Facelets tags for patch
> attachment purposes.
>
>
> Regards,
>
> ~ Simon
>
> On Thu, Feb 26, 2009 at 11:46 AM, Michael Concini <mc...@gmail.com>
> wrote:
>>
>> Good point about the size of the facelets work. Simon, is there part of
>> the facelets work that we could pick up for you guys? We're looking to help
>> out where our efforts would be most useful instead of just grabbing random
>> issues to work on.
>> I agree for the most part about your proposed contents for an alpha
>> release. I would also like to stress the importance of regression testing
>> with JSF 1.1/1.2 apps as part of any alpha release.
>> -Mike
>>
>> jankeesvanandel@gmail.com wrote:
>>>
>>> I'm currently working on the annotation processing stuff (@ManagedBean,
>>> @ManagedProperty...). Already made a first attempt for the managed beans,
>>> but there is still some work to do (converters, components, event listeners,
>>> etc). I hope I can apply the same logic for those other components as well.
>>>
>>> With Werner working on Ajax and Simon on Facelets, we already cover a
>>> large portion of JSF2. Facelets is big, though, since it also contains tags
>>> for all components, EZComp, JSF2-Facelets/Original-Facelets switching,
>>> etc... Resource handling/relocation is also a mandatory requirement for Ajax
>>> to work.
>>>
>>> But I think an alpha release should at least contain these essential JSF2
>>> components: AJAX, Facelets, annotation based configuration. I think those
>>> components are the base of the JSF2 work. Adding in other features should
>>> not be too hard when those three are in place properly.
>>>
>>> About Shale-test, is it right to use Shale classes in MyFaces Core? Of
>>> course it's just the unit tests, but in some way it's still a cyclic
>>> dependency which is usually a bad thing...
>>>
>>> /Jan-Kees
>>
>
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
Re: MyFaces 2.0 development going forward
Posted by Simon Lessard <si...@gmail.com>.
Hi Micheal,
Help on Facelets would be most welcome, it's quite big and not a code base I
know that much. I can see 6 main tasks to that integration, 4 required and 2
nice to have:
1. Relink the classes to JSF 2.0 FaceletContext and other Facelets API
from myfaces-api. *100%* done.
2. Package renaming. Someone suggested to keep the same names before, but
that won't work as JSF 2.0 must work if you drop in the latest Facelets JAR
and keeping the same names would imply some name clashes. So we have to
figure out either where to place each sub module or keep it with the
original structure but with different root packages. *0%* done.
3. Set Facelets as the default ViewHandler (as of JSF 2.0 Facelets
superceede JSP). *0%* done.
4. Since I used the latest Facelets code for integration, there's already
some difference between the spec and Facelets, namely with FaceletHandler
where the API only has the apply method while latest Facelets uses
applyDefinition. Therefore, we have to revert the Facelets code back to
apply only and get rid of the applyDefinition code. *30%* done.
5. Convert Facelets to Java 5+ (generics). *50%* done. This is a nice to
have, but I use this task to get comfortable with the code base at the same
time.
6. Get rid of the JSF version code switches. Facelets sometimes switch
between "Facelets" EL and "native" EL based on the current JSF version to
support EL in JSF 1.1 mainly. However, in MyFaces 2.0, this is irrelevant
and a performance overhaul so we need to get rid of that and always use
"native" EL. *99% *done. (I think I've got them all already, but I need
to do another run on it to be sure)
Points 2, 3, 4 are the ones I need the most help with. For 4. we started
fixing it using the JIRA tickets about the various Facelets tags for patch
attachment purposes.
Regards,
~ Simon
On Thu, Feb 26, 2009 at 11:46 AM, Michael Concini <mc...@gmail.com>wrote:
> Good point about the size of the facelets work. Simon, is there part of
> the facelets work that we could pick up for you guys? We're looking to help
> out where our efforts would be most useful instead of just grabbing random
> issues to work on.
> I agree for the most part about your proposed contents for an alpha
> release. I would also like to stress the importance of regression testing
> with JSF 1.1/1.2 apps as part of any alpha release.
> -Mike
>
>
> jankeesvanandel@gmail.com wrote:
>
>> I'm currently working on the annotation processing stuff (@ManagedBean,
>> @ManagedProperty...). Already made a first attempt for the managed beans,
>> but there is still some work to do (converters, components, event listeners,
>> etc). I hope I can apply the same logic for those other components as well.
>>
>> With Werner working on Ajax and Simon on Facelets, we already cover a
>> large portion of JSF2. Facelets is big, though, since it also contains tags
>> for all components, EZComp, JSF2-Facelets/Original-Facelets switching,
>> etc... Resource handling/relocation is also a mandatory requirement for Ajax
>> to work.
>>
>> But I think an alpha release should at least contain these essential JSF2
>> components: AJAX, Facelets, annotation based configuration. I think those
>> components are the base of the JSF2 work. Adding in other features should
>> not be too hard when those three are in place properly.
>>
>> About Shale-test, is it right to use Shale classes in MyFaces Core? Of
>> course it's just the unit tests, but in some way it's still a cyclic
>> dependency which is usually a bad thing...
>>
>> /Jan-Kees
>>
>
>
Re: MyFaces 2.0 development going forward
Posted by Michael Concini <mc...@gmail.com>.
We already have taken care of the legal stuff. We had actually hoped to
get involved in the 2.0 work much earlier but got stalled out waiting on
legal in the fall. We're good to go on that now.
Matthias Wessendorf wrote:
>> facelets work that we could pick up for you guys? We're looking to help out
>>
>
> As for you team... I'd recommend to sign and fax the Individual
> Contributor License Agreement (if you haven't done
> so already), see [1]. If you have an intellectual property agreement
> with your employer, they may also need to file a
> corporate agreement ([2]). IBM has one, so the guy in charge of that
> could just update the one, by adding your
> team. I think that person does know about the CCLA.
>
> HTH,
> Matthias
>
> [1] http://apache.org/licenses/icla.txt
> [2] http://apache.org/licenses/cla-corporate.txt
> [general info] http://apache.org/foundation/how-it-works.html
>
>
Re: MyFaces 2.0 development going forward
Posted by Matthias Wessendorf <ma...@apache.org>.
> facelets work that we could pick up for you guys? We're looking to help out
As for you team... I'd recommend to sign and fax the Individual
Contributor License Agreement (if you haven't done
so already), see [1]. If you have an intellectual property agreement
with your employer, they may also need to file a
corporate agreement ([2]). IBM has one, so the guy in charge of that
could just update the one, by adding your
team. I think that person does know about the CCLA.
HTH,
Matthias
[1] http://apache.org/licenses/icla.txt
[2] http://apache.org/licenses/cla-corporate.txt
[general info] http://apache.org/foundation/how-it-works.html
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
Re: MyFaces 2.0 development going forward
Posted by Michael Concini <mc...@gmail.com>.
Good point about the size of the facelets work. Simon, is there part of
the facelets work that we could pick up for you guys? We're looking to
help out where our efforts would be most useful instead of just grabbing
random issues to work on.
I agree for the most part about your proposed contents for an alpha
release. I would also like to stress the importance of regression
testing with JSF 1.1/1.2 apps as part of any alpha release.
-Mike
jankeesvanandel@gmail.com wrote:
> I'm currently working on the annotation processing stuff
> (@ManagedBean, @ManagedProperty...). Already made a first attempt for
> the managed beans, but there is still some work to do (converters,
> components, event listeners, etc). I hope I can apply the same logic
> for those other components as well.
>
> With Werner working on Ajax and Simon on Facelets, we already cover a
> large portion of JSF2. Facelets is big, though, since it also contains
> tags for all components, EZComp, JSF2-Facelets/Original-Facelets
> switching, etc... Resource handling/relocation is also a mandatory
> requirement for Ajax to work.
>
> But I think an alpha release should at least contain these essential
> JSF2 components: AJAX, Facelets, annotation based configuration. I
> think those components are the base of the JSF2 work. Adding in other
> features should not be too hard when those three are in place properly.
>
> About Shale-test, is it right to use Shale classes in MyFaces Core? Of
> course it's just the unit tests, but in some way it's still a cyclic
> dependency which is usually a bad thing...
>
> /Jan-Kees
Re: Re: MyFaces 2.0 development going forward
Posted by ja...@gmail.com.
I'm currently working on the annotation processing stuff (@ManagedBean,
@ManagedProperty...). Already made a first attempt for the managed beans,
but there is still some work to do (converters, components, event
listeners, etc). I hope I can apply the same logic for those other
components as well.
With Werner working on Ajax and Simon on Facelets, we already cover a large
portion of JSF2. Facelets is big, though, since it also contains tags for
all components, EZComp, JSF2-Facelets/Original-Facelets switching, etc...
Resource handling/relocation is also a mandatory requirement for Ajax to
work.
But I think an alpha release should at least contain these essential JSF2
components: AJAX, Facelets, annotation based configuration. I think those
components are the base of the JSF2 work. Adding in other features should
not be too hard when those three are in place properly.
About Shale-test, is it right to use Shale classes in MyFaces Core? Of
course it's just the unit tests, but in some way it's still a cyclic
dependency which is usually a bad thing...
/Jan-Kees
Re: MyFaces 2.0 development going forward
Posted by Simon Lessard <si...@gmail.com>.
Hi Matthias,
I guess that's a fair point about alpha release, I'll try to think of some
good milestone.
~ Simon
On Thu, Feb 26, 2009 at 2:25 AM, Matthias Wessendorf <ma...@apache.org>wrote:
> Hi
>
> On Tue, Feb 24, 2009 at 9:50 PM, Simon Lessard
> <si...@gmail.com> wrote:
> > Hi Michael,
> >
> > See inline.
> >
> >
> > Regards,
> >
> > ~ Simon
> >
> > On Tue, Feb 24, 2009 at 3:38 PM, Michael Concini <mc...@gmail.com>
> wrote:
> >>
> >> Now that the JSF 2.0 spec is getting closer to completion, I think it
> >> would be a good idea for some more planning to go into the development
> >> process for the MyFaces 2.0 release going forward. There are several
> >> aspects of this that need to be addressed.
> >>
> >> First, regarding the changes/additions to the JSF spec. Is anyone
> keeping
> >> track somewhere of which changes have JIRA issues attached versus those
> that
> >> still need to have new issues created? It is getting to be hard to
> >> determine what changes might still not have issues attached at this
> point as
> >> the number of JIRA issues associated with the 2.0 spec approaches 200.
> >
> > The tickets matching the public review are all created. I'll do another
> > roundtrip with my team when the final spec is released to create the
> missing
> > ones. Basically Werner is working on the JavaScript API, Leonardo and
> > Jan-Kees help in various areas, I'm currently working on integrating
> > Facelets and my teammate are helping me with that. One MAJOR issue that
> we
> > have right now are unit tests. Leonardo proposed to attack that one, but
> > since Shale might change his mind about the future of Shale-test, I asked
> > him to postpone dealing with it just in case so that we don't have to
> work
> > on that issue for nothing.
>
> this maybe a bit off-topic, but we should start to put the shale-test
> into myfaces.
> Simon, I will write the (required) mail to the shale dev list and will
> let the folks
> here know about the outcome.
>
> >
> >>
> >> Second, I think it would be very helpful to put together a more detailed
> >> road map of when we want to target specific changes and features. I
> think a
> >> good example of how we might want to do this is what OpenWebBeans is
> doing
> >> in their road map. They've outlined exactly what is being planned for
> the
> >> upcoming milestone work. I know something like this would be very useful
> to
> >> my team at IBM in determining which work is best for us to take on in
> any
> >> milestone period.
> >
> > I don't know if milestones are relevant when implementing a spec
> considering
> > what has to be done is fixed and static. I don't see any release coming
> not
> > passing the TCK, thus not implementing everything needed.
>
> I think that some users/contributors would appreciate a milestone or
> an alpha release.
> Once we release something that hasn't passed the TCK we have to call
> that aplha/milestone.
> Geronimo did this in the past and so does the openwebbeans podling. I
> wonder if we already
> asked for a TCK, and I am not sure if that has TCK has some fields of
> use restrictions (see [1] for
> a larger discussion on the field of use restrictions). But we should
> definitely ping SUN. Let me
> take on that part.
>
> Michael, if you are combing a committer (by providing patches) you can
> also get access to run
> the TCK (after signing a NDA) on your side. ;-)
>
> >
> >>
> >> I also think it would be a good idea to come up with a more formal way
> of
> >> keeping track of who is working on which items. As more folks become
> >> involved, its going to become more and more likely that we'll step on
> each
> >> other's toes.
> >
> > I agree, but JIRA only allows to assign ticket to commiters and I don't
> have
> > anything better than adding a comment to the ticket for now. If you have
> a
> > better idea it would be welcome.
>
> Perhaps we could use the wiki ? Like creating an umbrella MyFaces 2.0 items
> wiki
> page, which "links" the all the subtasks / issues .
>
> >
> >>
> >> Does anyone have thoughts on any of the above? I'd be glad to work with
> >> someone from the PMC to assist in any of the required planning.
>
> Michael, the right channel to communicate on the development of Apache
> MyFaces
> is this mailing list. If you/your team has questions, the best is to
> use something
> like [myfaces 2.0] in the beginning of the subject, so a mail can be
> filtered easily.
> We usually use other resources, like JIRA or the MyFaces wiki ([2]) to
> "organize"
> the work. You can create an account on those services and contribute some
> work
> there as well.
>
> If you have more questions, please ask them here, as the community is more
> than
> willing to answer them.
>
> -Matthias
>
> [1] http://www.apache.org/jcp/sunopenletter.html
> [2] http://wiki.apache.org/myfaces/
>
> >>
> >> Thanks,
> >> Mike Concini
> >
> >
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
Re: MyFaces 2.0 development going forward
Posted by Matthias Wessendorf <ma...@apache.org>.
Hi
On Tue, Feb 24, 2009 at 9:50 PM, Simon Lessard
<si...@gmail.com> wrote:
> Hi Michael,
>
> See inline.
>
>
> Regards,
>
> ~ Simon
>
> On Tue, Feb 24, 2009 at 3:38 PM, Michael Concini <mc...@gmail.com> wrote:
>>
>> Now that the JSF 2.0 spec is getting closer to completion, I think it
>> would be a good idea for some more planning to go into the development
>> process for the MyFaces 2.0 release going forward. There are several
>> aspects of this that need to be addressed.
>>
>> First, regarding the changes/additions to the JSF spec. Is anyone keeping
>> track somewhere of which changes have JIRA issues attached versus those that
>> still need to have new issues created? It is getting to be hard to
>> determine what changes might still not have issues attached at this point as
>> the number of JIRA issues associated with the 2.0 spec approaches 200.
>
> The tickets matching the public review are all created. I'll do another
> roundtrip with my team when the final spec is released to create the missing
> ones. Basically Werner is working on the JavaScript API, Leonardo and
> Jan-Kees help in various areas, I'm currently working on integrating
> Facelets and my teammate are helping me with that. One MAJOR issue that we
> have right now are unit tests. Leonardo proposed to attack that one, but
> since Shale might change his mind about the future of Shale-test, I asked
> him to postpone dealing with it just in case so that we don't have to work
> on that issue for nothing.
this maybe a bit off-topic, but we should start to put the shale-test
into myfaces.
Simon, I will write the (required) mail to the shale dev list and will
let the folks
here know about the outcome.
>
>>
>> Second, I think it would be very helpful to put together a more detailed
>> road map of when we want to target specific changes and features. I think a
>> good example of how we might want to do this is what OpenWebBeans is doing
>> in their road map. They've outlined exactly what is being planned for the
>> upcoming milestone work. I know something like this would be very useful to
>> my team at IBM in determining which work is best for us to take on in any
>> milestone period.
>
> I don't know if milestones are relevant when implementing a spec considering
> what has to be done is fixed and static. I don't see any release coming not
> passing the TCK, thus not implementing everything needed.
I think that some users/contributors would appreciate a milestone or
an alpha release.
Once we release something that hasn't passed the TCK we have to call
that aplha/milestone.
Geronimo did this in the past and so does the openwebbeans podling. I
wonder if we already
asked for a TCK, and I am not sure if that has TCK has some fields of
use restrictions (see [1] for
a larger discussion on the field of use restrictions). But we should
definitely ping SUN. Let me
take on that part.
Michael, if you are combing a committer (by providing patches) you can
also get access to run
the TCK (after signing a NDA) on your side. ;-)
>
>>
>> I also think it would be a good idea to come up with a more formal way of
>> keeping track of who is working on which items. As more folks become
>> involved, its going to become more and more likely that we'll step on each
>> other's toes.
>
> I agree, but JIRA only allows to assign ticket to commiters and I don't have
> anything better than adding a comment to the ticket for now. If you have a
> better idea it would be welcome.
Perhaps we could use the wiki ? Like creating an umbrella MyFaces 2.0 items wiki
page, which "links" the all the subtasks / issues .
>
>>
>> Does anyone have thoughts on any of the above? I'd be glad to work with
>> someone from the PMC to assist in any of the required planning.
Michael, the right channel to communicate on the development of Apache MyFaces
is this mailing list. If you/your team has questions, the best is to
use something
like [myfaces 2.0] in the beginning of the subject, so a mail can be
filtered easily.
We usually use other resources, like JIRA or the MyFaces wiki ([2]) to
"organize"
the work. You can create an account on those services and contribute some work
there as well.
If you have more questions, please ask them here, as the community is more than
willing to answer them.
-Matthias
[1] http://www.apache.org/jcp/sunopenletter.html
[2] http://wiki.apache.org/myfaces/
>>
>> Thanks,
>> Mike Concini
>
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
Re: MyFaces 2.0 development going forward
Posted by Simon Lessard <si...@gmail.com>.
Hi Michael,
See inline.
Regards,
~ Simon
On Tue, Feb 24, 2009 at 3:38 PM, Michael Concini <mc...@gmail.com> wrote:
> Now that the JSF 2.0 spec is getting closer to completion, I think it
> would be a good idea for some more planning to go into the development
> process for the MyFaces 2.0 release going forward. There are several
> aspects of this that need to be addressed.
>
> First, regarding the changes/additions to the JSF spec. Is anyone keeping
> track somewhere of which changes have JIRA issues attached versus those that
> still need to have new issues created? It is getting to be hard to
> determine what changes might still not have issues attached at this point as
> the number of JIRA issues associated with the 2.0 spec approaches 200.
>
The tickets matching the public review are all created. I'll do another
roundtrip with my team when the final spec is released to create the missing
ones. Basically Werner is working on the JavaScript API, Leonardo and
Jan-Kees help in various areas, I'm currently working on integrating
Facelets and my teammate are helping me with that. One MAJOR issue that we
have right now are unit tests. Leonardo proposed to attack that one, but
since Shale might change his mind about the future of Shale-test, I asked
him to postpone dealing with it just in case so that we don't have to work
on that issue for nothing.
>
>
> Second, I think it would be very helpful to put together a more detailed
> road map of when we want to target specific changes and features. I think a
> good example of how we might want to do this is what OpenWebBeans is doing in
> their road map<https://issues.apache.org/jira/secure/BrowseProject.jspa?id=12310844&subset=-1>.
> They've outlined exactly what is being planned for the upcoming milestone
> work. I know something like this would be very useful to my team at IBM in
> determining which work is best for us to take on in any milestone period.
>
I don't know if milestones are relevant when implementing a spec considering
what has to be done is fixed and static. I don't see any release coming not
passing the TCK, thus not implementing everything needed.
>
>
> I also think it would be a good idea to come up with a more formal way of
> keeping track of who is working on which items. As more folks become
> involved, its going to become more and more likely that we'll step on each
> other's toes.
>
I agree, but JIRA only allows to assign ticket to commiters and I don't have
anything better than adding a comment to the ticket for now. If you have a
better idea it would be welcome.
>
>
> Does anyone have thoughts on any of the above? I'd be glad to work with
> someone from the PMC to assist in any of the required planning.
>
> Thanks,
> Mike Concini
>