JSF2.0 implementation

[Simon Kitching <sk...@apache.org>]

I see from the commit list that a new JSF2.0 branch has been created.

I don't remember seeing *any* kind of discussion or even announcement 
about this. While I am happy to see JSF2.0 work going on, this kind of 
approach does not seem to be at all in the "community" spirit. IMO, 
major events like this should be discussed beforehand.

One issue, for example, is that the core-1.2 stuff is currently 
half-way-converted from the trinidad plugins to the 
myfaces-builder-plugin. So now it is branched, any changes need to be 
applied in two places.

In addition, a large amount of code has just been committed by someone 
(slessard) who is not a particularly regular contributor to myfaces. 
Where did this code come from? Do we need a code grant for it? Note that 
when code is developed iteratively on the dev list then there is no need 
for a grant. But a sudden code dump is different, even when contributed 
by someone who has signed a CLA.

And with 3 branches to now maintain, we need to discuss whether and when 
we phase out maintenance of the jsf-1.1 branch. Currently when users 
provide patches in jira, they almost always provide a patch against only 
one version and the committer ports it, which does increase the load on 
existing committers. When do we stop asking committers to do this when 
patching bugs?

To repeat, I'm *happy* that jsf2.0 implementation is in progress, and 
appreciate people contributing time to write an ASF-2.0-licensed 
implementation. But it is a  standard saying at Apache that "community 
is more important than code", and the "community" aspect here seems to 
have been rather neglected...

Regards,
Simon

Re: JSF2.0 implementation

[Matthias Wessendorf <ma...@apache.org>]

On Fri, Aug 29, 2008 at 10:22 AM, Simon Kitching <sk...@apache.org> wrote:
> Thanks for all the info, Simon. This all looks great. All I really wanted
> was for this info to be posted (to the dev list) before the branch was
> created rather than after. I (and probably a lot of other people here) don't
> watch JIRA messages closely as there are so many.
>
> A suggestion: maybe a wiki page would be useful to gather info about the
> development plans for this new branch?

+1 sounds good.
Could be a "raw" guide as well (in terms of getting started9

>
> Summary:
> * Part funded by Fujitsu - which already has a CCLA
> * Part done on private time of slessard who is a committer with appropriate
> icla.
> * Other Fujitsu developers (not currently apache committers) are probably
> going to contribute in the near future;
>   patches to be attached first to JIRA then committed by slessard or others.

I think after one or two patches, we want an iCLA.

>
> I presume that the other non-committers working on this will also subscribe
> to the dev list, and will discuss any design issues they have here on the
> list rather than in private at Fujitsu? I know it sometimes feels weird to

+1 I'd expect that.

> discuss stuff over email when the person you are mostly discussing this with
> sits at the next desk, but that's important for open-source community.
>
> BTW, if people are going to contribute significant time to this, then of
> course they deserve listing in the pom.xml as contributors - and it might
> perhaps be nice if they introduce themselves via an email on this dev list,
> so we know who we owe a few beers to when this is all done!

:-)

-Matthias

>
> Regards,
> Simon K.
>
>



-- 
Matthias Wessendorf

Need JSF and Web 2.0?
http://code.google.com/p/facesgoodies

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

Re: JSF2.0 implementation

[Simon Kitching <sk...@apache.org>]

Thanks for all the info, Simon. This all looks great. All I really 
wanted was for this info to be posted (to the dev list) before the 
branch was created rather than after. I (and probably a lot of other 
people here) don't watch JIRA messages closely as there are so many.

A suggestion: maybe a wiki page would be useful to gather info about the 
development plans for this new branch?

Summary:
 * Part funded by Fujitsu - which already has a CCLA
 * Part done on private time of slessard who is a committer with 
appropriate icla.
 * Other Fujitsu developers (not currently apache committers) are 
probably going to contribute in the near future;
    patches to be attached first to JIRA then committed by slessard or 
others.

I presume that the other non-committers working on this will also 
subscribe to the dev list, and will discuss any design issues they have 
here on the list rather than in private at Fujitsu? I know it sometimes 
feels weird to discuss stuff over email when the person you are mostly 
discussing this with sits at the next desk, but that's important for 
open-source community.

BTW, if people are going to contribute significant time to this, then of 
course they deserve listing in the pom.xml as contributors - and it 
might perhaps be nice if they introduce themselves via an email on this 
dev list, so we know who we owe a few beers to when this is all done!

Regards,
Simon K.

Re: JSF2.0 implementation

[Simon Lessard <si...@gmail.com>]

Yep, that's what I was thinking of.


Regards,

~ Simon

On Fri, Aug 29, 2008 at 11:33 AM, Matthias Wessendorf <ma...@apache.org>wrote:

> On Fri, Aug 29, 2008 at 5:23 PM, Simon Lessard
> <si...@gmail.com> wrote:
> > I think you can only assign tickets to known contributors, that is JIRA
> > users with some special permissions, which is not the case for some
> people
> > on my team.
>
> correct.
>
> > Of course, in the best world, assigning the ticket to yourself and mark
> it
> > as "In progress" would be the best way to prevent clashes.
>
> perhaps adding a comment, like "I started to look at it" would help?
> -M
>
> >
> >
> > ~ Simon
> >
> > On Fri, Aug 29, 2008 at 1:18 AM, Matthias Wessendorf <
> mwessendorf@gmail.com>
> > wrote:
> >>
> >>
> >> Sent from my iPod.
> >> Am 29.08.2008 um 01:53 schrieb "Simon Lessard"
> >> <si...@gmail.com>:
> >>
> >> Ok,
> >>
> >> The branch is now compiling and TODOs of the following format were
> placed
> >> in the newly created methods : // TODO: JSF 2.0 #xx
> >>
> >> We also created a JIRA ticket of every of those TODOs, so if you feel
> like
> >> trying one, you can add a comment in JIRA saying that you're taking the
> >> ticker. Before taking a ticket, make sure that no one else is currently
> >> working on it to prevent clashes.
> >>
> >> That's why you can assign tickets.
> >>
> >> The next step on my side is to add more TODOs for the updated methods
> and
> >> create a JIRA ticket for them, then I'll get to coding myself.
> >>
> >>
> >> Thanks,
> >>
> >> ~ Simon
> >>
> >>
> >> On Thu, Aug 28, 2008 at 7:19 PM, Simon Lessard <
> simon.lessard.3@gmail.com>
> >> wrote:
> >>>
> >>> Thank :) Although give me 10 minutes or so to fix something stupid I
> did
> >>> before doing a checkout.
> >>>
> >>>
> >>> Regards,
> >>>
> >>> ~ Simon
> >>>
> >>> On Thu, Aug 28, 2008 at 7:16 PM, Hazem Saleh <ha...@apache.org>
> wrote:
> >>>>
> >>>> Thank you Simon. I will join this soon.
> >>>>
> >>>> On Thu, Aug 28, 2008 at 7:13 PM, Simon Lessard
> >>>> <si...@gmail.com> wrote:
> >>>>>
> >>>>> Hi Bruno,
> >>>>>
> >>>>> So far my planing was:
> >>>>>
> >>>>> sequential
> >>>>> 1. Create all new API classes: done
> >>>>> 2. Add all new methods to the API, with empty TODO: JSF 2.0 comment
> in
> >>>>> their body when they aren't abstract: in progress and I already found
> some
> >>>>> strange stuff that I might raise on the EG group discussions as for
> why
> >>>>> Application.getResourceHandler isn't abstract while all other get
> handler
> >>>>> methods are: in progress
> >>>>>
> >>>>> *** At that point, IMPL will no longer compile ***
> >>>>>
> >>>>> 3. Add the missing signature in IMPL with empty TODO: JSF 2.0 comment
> >>>>> in their body
> >>>>>
> >>>>> *** Everything should compile but don't work at all ***
> >>>>>
> >>>>> parallel
> >>>>> 4. Modify the build plugin to include jsf 2.0 changes
> >>>>> 5. Implement the API changes
> >>>>> 6. Implement the IMPL changes
> >>>>> 7. Implement the JS library
> >>>>>
> >>>>> I would really like to use Facelets code when required, but we'll
> have
> >>>>> to make sure it's alright with legal discuss first I think, I'm not
> well
> >>>>> versed enough in this kind of very specific issues.
> >>>>>
> >>>>> It's a very high level roadmap, We should probably use much finer
> >>>>> granularity for point 5 to 7, but I'm not there yet.
> >>>>>
> >>>>>
> >>>>> Regards,
> >>>>>
> >>>>> ~ Simon
> >>>>>
> >>>>> On Thu, Aug 28, 2008 at 11:30 AM, Bruno Aranda <
> brunoaranda@gmail.com>
> >>>>> wrote:
> >>>>>>
> >>>>>> I am willing (as always) to contribute as much as my time permits to
> >>>>>> the JSF 2.0 implementation. I tried to find in the list what is
> going to be
> >>>>>> the big picture, the roadmap to have a JSF 2.0 implementation. Do we
> have
> >>>>>> something like that? How are we going to integrate Facelets, for
> instance?
> >>>>>> (good that is now under ASL!). What part are you developing at the
> moment?
> >>>>>>
> >>>>>> Thanks!
> >>>>>>
> >>>>>> Bruno
> >>>>>>
> >>>>>> 2008/8/28 Matthias Wessendorf <ma...@apache.org>
> >>>>>>>
> >>>>>>> On Thu, Aug 28, 2008 at 4:50 PM, Simon Lessard
> >>>>>>> <si...@gmail.com> wrote:
> >>>>>>> >
> >>>>>>> >
> >>>>>>> > On Thu, Aug 28, 2008 at 10:35 AM, Matthias Wessendorf
> >>>>>>> > <ma...@apache.org>
> >>>>>>> > wrote:
> >>>>>>> >>
> >>>>>>> >> On Thu, Aug 28, 2008 at 4:24 PM, Simon Lessard
> >>>>>>> >> <si...@gmail.com> wrote:
> >>>>>>> >> > Hi Simon,
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> > On Thu, Aug 28, 2008 at 2:56 AM, Simon Kitching
> >>>>>>> >> > <sk...@apache.org>
> >>>>>>> >> > wrote:
> >>>>>>> >> >>
> >>>>>>> >> >> I see from the commit list that a new JSF2.0 branch has been
> >>>>>>> >> >> created.
> >>>>>>> >> >>
> >>>>>>> >> >> I don't remember seeing *any* kind of discussion or even
> >>>>>>> >> >> announcement
> >>>>>>> >> >> about this. While I am happy to see JSF2.0 work going on,
> this
> >>>>>>> >> >> kind of
> >>>>>>> >> >> approach does not seem to be at all in the "community"
> spirit.
> >>>>>>> >> >> IMO,
> >>>>>>> >> >> major
> >>>>>>> >> >> events like this should be discussed beforehand.
> >>>>>>> >> >
> >>>>>>> >> > As mentioned by other people, there was a vote about this a
> >>>>>>> >> > while back .
> >>>>>>> >> > Why
> >>>>>>> >> > did I create it just now? Simply because my company agreed to
> >>>>>>> >> > provide
> >>>>>>> >> > some
> >>>>>>> >> > resource to help with the implementation and we were ready to
> >>>>>>> >> > get
> >>>>>>> >> > started.
> >>>>>>> >>
> >>>>>>> >> One might ask here for a CCLA ;-)
> >>>>>>> >> We did that for Oracle way back, and update once in a while all
> >>>>>>> >> the
> >>>>>>> >> contributors,
> >>>>>>> >> that have signed the iCLA.
> >>>>>>> >
> >>>>>>> > Yeah, but Fujistu signed a CCLA already when I became commiter,
> so
> >>>>>>> > that's a
> >>>>>>> > non issue as well.
> >>>>>>>
> >>>>>>> good.
> >>>>>>>
> >>>>>>> >
> >>>>>>> >>
> >>>>>>> >> >
> >>>>>>> >> >>
> >>>>>>> >> >> One issue, for example, is that the core-1.2 stuff is
> currently
> >>>>>>> >> >> half-way-converted from the trinidad plugins to the
> >>>>>>> >> >> myfaces-builder-plugin.
> >>>>>>> >> >> So now it is branched, any changes need to be applied in two
> >>>>>>> >> >> places.
> >>>>>>> >> >
> >>>>>>> >> > To be honest, I find this irrelevant, it's a branch, not a
> trunk
> >>>>>>> >> > and
> >>>>>>> >> > I'll
> >>>>>>> >> > most likely do some branch merging when core 1.2.x get release
> >>>>>>> >> > and the
> >>>>>>> >> > plugin might have to change a little to support jsfVersion
> 2.0.
> >>>>>>> >> >
> >>>>>>> >> >>
> >>>>>>> >> >> In addition, a large amount of code has just been committed
> by
> >>>>>>> >> >> someone
> >>>>>>> >> >> (slessard) who is not a particularly regular contributor to
> >>>>>>> >> >> myfaces.
> >>>>>>> >> >
> >>>>>>> >> > I see even less relevance in that statement.
> >>>>>>> >> >
> >>>>>>> >> >>
> >>>>>>> >> >> Where did this code come from? Do we need a code grant for
> it?
> >>>>>>> >> >> Note
> >>>>>>> >> >> that
> >>>>>>> >> >> when code is developed iteratively on the dev list then there
> >>>>>>> >> >> is no
> >>>>>>> >> >> need for
> >>>>>>> >> >> a grant. But a sudden code dump is different, even when
> >>>>>>> >> >> contributed by
> >>>>>>> >> >> someone who has signed a CLA.
> >>>>>>> >> >
> >>>>>>> >> > The code was coded just yesterday by me and is not much at
> all,
> >>>>>>> >> > creating
> >>>>>>> >> > missing classes for the JavaDoc change log is in no matter a
> >>>>>>> >> > large
> >>>>>>> >> > amount in
> >>>>>>> >> > term of complexity. Also since I was the only author of it (my
> >>>>>>> >> > teammates
> >>>>>>> >> > will wait until I have added the signatures). There's
> absolutely
> >>>>>>> >> > no need
> >>>>>>> >> > of
> >>>>>>> >> > code grant either.
> >>>>>>> >>
> >>>>>>> >> I agree on the code grant, b/c of it is really pretty trivial to
> >>>>>>> >> create those API classes/interfaces
> >>>>>>> >> (based on the javadoc log, as I said before).
> >>>>>>> >> @signatures: you mean the iCLA / CCLA, aren't you ?
> >>>>>>> >
> >>>>>>> > nah, I meant method signatures, it will be easier for my
> teammates
> >>>>>>> > to know
> >>>>>>> > what they have to do once there's a nice // TODO: Convert to JSF
> >>>>>>> > 2.0 added
> >>>>>>> > in every new method's body.
> >>>>>>> >
> >>>>>>> > As far as I understand the legal issues (might have to fallback
> to
> >>>>>>> > legal@apache.org though), they won't need a CLA until they
> become
> >>>>>>> > commiters.
> >>>>>>> > I don't know if I should have the company add their names to the
> >>>>>>> > CCLA
> >>>>>>>
> >>>>>>> no. wrong
> >>>>>>> cla == contributor license agreement.
> >>>>>>> I usually ask for that after one or two patches. Never been an
> issue
> >>>>>>> at all.
> >>>>>>> We (from ORA) add those contributors to our CCLA, and fax the
> update
> >>>>>>> to
> >>>>>>> Sam Ruby (our ASF secretary).
> >>>>>>>
> >>>>>>> > however. Technically, we aren't bound contractualy by any
> >>>>>>> > intellectual
> >>>>>>> > property transfer with my employer and we're developping outside
> >>>>>>> > normal
> >>>>>>> > business hours so we aren't directly paid either for it so I
> don't
> >>>>>>> > know if
> >>>>>>> > adding their name to the CCLA is even needed or not.
> >>>>>>>
> >>>>>>> that means, what you develop on your sparetime is yours... NO CCLA
> >>>>>>> update
> >>>>>>> required. Cool
> >>>>>>>
> >>>>>>> -Matthias
> >>>>>>>
> >>>>>>> >
> >>>>>>> >
> >>>>>>> > ~ Simon
> >>>>>>> >
> >>>>>>> >>
> >>>>>>> >> >
> >>>>>>> >> >>
> >>>>>>> >> >> And with 3 branches to now maintain, we need to discuss
> whether
> >>>>>>> >> >> and
> >>>>>>> >> >> when
> >>>>>>> >> >> we phase out maintenance of the jsf-1.1 branch. Currently
> when
> >>>>>>> >> >> users
> >>>>>>> >> >> provide
> >>>>>>> >> >> patches in jira, they almost always provide a patch against
> >>>>>>> >> >> only one
> >>>>>>> >> >> version
> >>>>>>> >> >> and the committer ports it, which does increase the load on
> >>>>>>> >> >> existing
> >>>>>>> >> >> committers. When do we stop asking committers to do this when
> >>>>>>> >> >> patching
> >>>>>>> >> >> bugs?
> >>>>>>> >> >
> >>>>>>> >> > I can take care of the branch merging, this is how we handled
> >>>>>>> >> > the
> >>>>>>> >> > trinidad
> >>>>>>> >> > 1.2 branch at first, Adam would do the merging every now and
> >>>>>>> >> > then, so
> >>>>>>> >> > I'm
> >>>>>>> >> > not asking the committers to do some extra work.
> >>>>>>> >>
> >>>>>>> >> yup. not a big deal. Also I doubt that that many folks will work
> >>>>>>> >> there, on the branch.
> >>>>>>> >> If the branch needs some merging... fine as well, IMO.
> >>>>>>> >>
> >>>>>>> >> >
> >>>>>>> >> >>
> >>>>>>> >> >> To repeat, I'm *happy* that jsf2.0 implementation is in
> >>>>>>> >> >> progress, and
> >>>>>>> >> >> appreciate people contributing time to write an
> >>>>>>> >> >> ASF-2.0-licensed
> >>>>>>> >> >> implementation. But it is a  standard saying at Apache that
> >>>>>>> >> >> "community
> >>>>>>> >> >> is
> >>>>>>> >> >> more important than code", and the "community" aspect here
> >>>>>>> >> >> seems to
> >>>>>>> >> >> have
> >>>>>>> >> >> been rather neglected...
> >>>>>>> >> >
> >>>>>>> >> > I don't agree at all here. Although it wasn't announced on the
> >>>>>>> >> > dev list,
> >>>>>>> >> > the
> >>>>>>> >> > JIRA ticket created to attach patches was speciafically for
> the
> >>>>>>> >> > community.
> >>>>>>> >>
> >>>>>>> >> and the branch creation was also discussed.
> >>>>>>> >>
> >>>>>>> >> > Code provided by Fujitsu employees will never go through me
> with
> >>>>>>> >> > direct
> >>>>>>> >> > commit, it will all be added as patches, even extra tests and
> >>>>>>> >> > documentation
> >>>>>>> >> > as we want them and everyone else willing to help get the
> credit
> >>>>>>> >> > for it.
> >>>>>>> >>
> >>>>>>> >> we do the same. Folks provide patches and jira tickets to
> describe
> >>>>>>> >> the
> >>>>>>> >> problem.
> >>>>>>> >>
> >>>>>>> >> > Furthermore, I personally didn't announce it because the
> branch
> >>>>>>> >> > will be
> >>>>>>> >> > very
> >>>>>>> >> > instable for a week or two until we finish adding the missing
> >>>>>>> >> > signatures
> >>>>>>> >> > (impl might not even always compile).
> >>>>>>> >>
> >>>>>>> >> dev@ is a developers community; so that would be fine :-)
> >>>>>>> >>
> >>>>>>> >> -Matthias
> >>>>>>> >>
> >>>>>>> >> > If community wasn't important in the process we would just
> have
> >>>>>>> >> > used a
> >>>>>>> >> > private repository at Fujitsu, worked on it for some time with
> >>>>>>> >> > my team,
> >>>>>>> >> > then
> >>>>>>> >> > commit some very large amount of code (real large) that would
> >>>>>>> >> > have
> >>>>>>> >> > needed a
> >>>>>>> >> > code grant, prevented the people to see at what rythm things
> >>>>>>> >> > were
> >>>>>>> >> > progressing and contributing. The only point I *could* give
> you
> >>>>>>> >> > here is
> >>>>>>> >> > that
> >>>>>>> >> > maybe I should have annouced the creation directly on the dev
> >>>>>>> >> > list and
> >>>>>>> >> > point
> >>>>>>> >> > on the JIRA ticket and SVN url rather than relying only on
> JIRA
> >>>>>>> >> > ticket
> >>>>>>> >> > report that get forwarded on the dev list.
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >> > Regards,
> >>>>>>> >> >
> >>>>>>> >> > ~ Simon
> >>>>>>> >> >
> >>>>>>> >> >>
> >>>>>>> >> >> Regards,
> >>>>>>> >> >> Simon
> >>>>>>> >> >>
> >>>>>>> >> >
> >>>>>>> >> >
> >>>>>>> >>
> >>>>>>> >>
> >>>>>>> >>
> >>>>>>> >> --
> >>>>>>> >> Matthias Wessendorf
> >>>>>>> >>
> >>>>>>> >> Need JSF and Web 2.0?
> >>>>>>> >> http://code.google.com/p/facesgoodies
> >>>>>>> >>
> >>>>>>> >> further stuff:
> >>>>>>> >> blog: http://matthiaswessendorf.wordpress.com/
> >>>>>>> >> sessions: http://www.slideshare.net/mwessendorf
> >>>>>>> >> mail: matzew-at-apache-dot-org
> >>>>>>> >
> >>>>>>> >
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Matthias Wessendorf
> >>>>>>>
> >>>>>>> Need JSF and Web 2.0?
> >>>>>>> http://code.google.com/p/facesgoodies
> >>>>>>>
> >>>>>>> further stuff:
> >>>>>>> blog: http://matthiaswessendorf.wordpress.com/
> >>>>>>> sessions: http://www.slideshare.net/mwessendorf
> >>>>>>> mail: matzew-at-apache-dot-org
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Hazem Ahmed Saleh Ahmed
> >>>> http://www.jroller.com/page/HazemBlog
> >>>>
> >>>> [Web 2.0] GMaps Integration with JSF + Apache Tomahawk + JBoss a4j :
> >>>> http://code.google.com/p/gmaps4jsf/
> >>>
> >>
> >
> >
>
>
>
> --
> Matthias Wessendorf
>
> Need JSF and Web 2.0?
> http://code.google.com/p/facesgoodies
>
> further stuff:
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> mail: matzew-at-apache-dot-org
>

Re: JSF2.0 implementation

[Matthias Wessendorf <ma...@apache.org>]

On Fri, Aug 29, 2008 at 5:23 PM, Simon Lessard
<si...@gmail.com> wrote:
> I think you can only assign tickets to known contributors, that is JIRA
> users with some special permissions, which is not the case for some people
> on my team.

correct.

> Of course, in the best world, assigning the ticket to yourself and mark it
> as "In progress" would be the best way to prevent clashes.

perhaps adding a comment, like "I started to look at it" would help?
-M

>
>
> ~ Simon
>
> On Fri, Aug 29, 2008 at 1:18 AM, Matthias Wessendorf <mw...@gmail.com>
> wrote:
>>
>>
>> Sent from my iPod.
>> Am 29.08.2008 um 01:53 schrieb "Simon Lessard"
>> <si...@gmail.com>:
>>
>> Ok,
>>
>> The branch is now compiling and TODOs of the following format were placed
>> in the newly created methods : // TODO: JSF 2.0 #xx
>>
>> We also created a JIRA ticket of every of those TODOs, so if you feel like
>> trying one, you can add a comment in JIRA saying that you're taking the
>> ticker. Before taking a ticket, make sure that no one else is currently
>> working on it to prevent clashes.
>>
>> That's why you can assign tickets.
>>
>> The next step on my side is to add more TODOs for the updated methods and
>> create a JIRA ticket for them, then I'll get to coding myself.
>>
>>
>> Thanks,
>>
>> ~ Simon
>>
>>
>> On Thu, Aug 28, 2008 at 7:19 PM, Simon Lessard <si...@gmail.com>
>> wrote:
>>>
>>> Thank :) Although give me 10 minutes or so to fix something stupid I did
>>> before doing a checkout.
>>>
>>>
>>> Regards,
>>>
>>> ~ Simon
>>>
>>> On Thu, Aug 28, 2008 at 7:16 PM, Hazem Saleh <ha...@apache.org> wrote:
>>>>
>>>> Thank you Simon. I will join this soon.
>>>>
>>>> On Thu, Aug 28, 2008 at 7:13 PM, Simon Lessard
>>>> <si...@gmail.com> wrote:
>>>>>
>>>>> Hi Bruno,
>>>>>
>>>>> So far my planing was:
>>>>>
>>>>> sequential
>>>>> 1. Create all new API classes: done
>>>>> 2. Add all new methods to the API, with empty TODO: JSF 2.0 comment in
>>>>> their body when they aren't abstract: in progress and I already found some
>>>>> strange stuff that I might raise on the EG group discussions as for why
>>>>> Application.getResourceHandler isn't abstract while all other get handler
>>>>> methods are: in progress
>>>>>
>>>>> *** At that point, IMPL will no longer compile ***
>>>>>
>>>>> 3. Add the missing signature in IMPL with empty TODO: JSF 2.0 comment
>>>>> in their body
>>>>>
>>>>> *** Everything should compile but don't work at all ***
>>>>>
>>>>> parallel
>>>>> 4. Modify the build plugin to include jsf 2.0 changes
>>>>> 5. Implement the API changes
>>>>> 6. Implement the IMPL changes
>>>>> 7. Implement the JS library
>>>>>
>>>>> I would really like to use Facelets code when required, but we'll have
>>>>> to make sure it's alright with legal discuss first I think, I'm not well
>>>>> versed enough in this kind of very specific issues.
>>>>>
>>>>> It's a very high level roadmap, We should probably use much finer
>>>>> granularity for point 5 to 7, but I'm not there yet.
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> ~ Simon
>>>>>
>>>>> On Thu, Aug 28, 2008 at 11:30 AM, Bruno Aranda <br...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> I am willing (as always) to contribute as much as my time permits to
>>>>>> the JSF 2.0 implementation. I tried to find in the list what is going to be
>>>>>> the big picture, the roadmap to have a JSF 2.0 implementation. Do we have
>>>>>> something like that? How are we going to integrate Facelets, for instance?
>>>>>> (good that is now under ASL!). What part are you developing at the moment?
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> Bruno
>>>>>>
>>>>>> 2008/8/28 Matthias Wessendorf <ma...@apache.org>
>>>>>>>
>>>>>>> On Thu, Aug 28, 2008 at 4:50 PM, Simon Lessard
>>>>>>> <si...@gmail.com> wrote:
>>>>>>> >
>>>>>>> >
>>>>>>> > On Thu, Aug 28, 2008 at 10:35 AM, Matthias Wessendorf
>>>>>>> > <ma...@apache.org>
>>>>>>> > wrote:
>>>>>>> >>
>>>>>>> >> On Thu, Aug 28, 2008 at 4:24 PM, Simon Lessard
>>>>>>> >> <si...@gmail.com> wrote:
>>>>>>> >> > Hi Simon,
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> > On Thu, Aug 28, 2008 at 2:56 AM, Simon Kitching
>>>>>>> >> > <sk...@apache.org>
>>>>>>> >> > wrote:
>>>>>>> >> >>
>>>>>>> >> >> I see from the commit list that a new JSF2.0 branch has been
>>>>>>> >> >> created.
>>>>>>> >> >>
>>>>>>> >> >> I don't remember seeing *any* kind of discussion or even
>>>>>>> >> >> announcement
>>>>>>> >> >> about this. While I am happy to see JSF2.0 work going on, this
>>>>>>> >> >> kind of
>>>>>>> >> >> approach does not seem to be at all in the "community" spirit.
>>>>>>> >> >> IMO,
>>>>>>> >> >> major
>>>>>>> >> >> events like this should be discussed beforehand.
>>>>>>> >> >
>>>>>>> >> > As mentioned by other people, there was a vote about this a
>>>>>>> >> > while back .
>>>>>>> >> > Why
>>>>>>> >> > did I create it just now? Simply because my company agreed to
>>>>>>> >> > provide
>>>>>>> >> > some
>>>>>>> >> > resource to help with the implementation and we were ready to
>>>>>>> >> > get
>>>>>>> >> > started.
>>>>>>> >>
>>>>>>> >> One might ask here for a CCLA ;-)
>>>>>>> >> We did that for Oracle way back, and update once in a while all
>>>>>>> >> the
>>>>>>> >> contributors,
>>>>>>> >> that have signed the iCLA.
>>>>>>> >
>>>>>>> > Yeah, but Fujistu signed a CCLA already when I became commiter, so
>>>>>>> > that's a
>>>>>>> > non issue as well.
>>>>>>>
>>>>>>> good.
>>>>>>>
>>>>>>> >
>>>>>>> >>
>>>>>>> >> >
>>>>>>> >> >>
>>>>>>> >> >> One issue, for example, is that the core-1.2 stuff is currently
>>>>>>> >> >> half-way-converted from the trinidad plugins to the
>>>>>>> >> >> myfaces-builder-plugin.
>>>>>>> >> >> So now it is branched, any changes need to be applied in two
>>>>>>> >> >> places.
>>>>>>> >> >
>>>>>>> >> > To be honest, I find this irrelevant, it's a branch, not a trunk
>>>>>>> >> > and
>>>>>>> >> > I'll
>>>>>>> >> > most likely do some branch merging when core 1.2.x get release
>>>>>>> >> > and the
>>>>>>> >> > plugin might have to change a little to support jsfVersion 2.0.
>>>>>>> >> >
>>>>>>> >> >>
>>>>>>> >> >> In addition, a large amount of code has just been committed by
>>>>>>> >> >> someone
>>>>>>> >> >> (slessard) who is not a particularly regular contributor to
>>>>>>> >> >> myfaces.
>>>>>>> >> >
>>>>>>> >> > I see even less relevance in that statement.
>>>>>>> >> >
>>>>>>> >> >>
>>>>>>> >> >> Where did this code come from? Do we need a code grant for it?
>>>>>>> >> >> Note
>>>>>>> >> >> that
>>>>>>> >> >> when code is developed iteratively on the dev list then there
>>>>>>> >> >> is no
>>>>>>> >> >> need for
>>>>>>> >> >> a grant. But a sudden code dump is different, even when
>>>>>>> >> >> contributed by
>>>>>>> >> >> someone who has signed a CLA.
>>>>>>> >> >
>>>>>>> >> > The code was coded just yesterday by me and is not much at all,
>>>>>>> >> > creating
>>>>>>> >> > missing classes for the JavaDoc change log is in no matter a
>>>>>>> >> > large
>>>>>>> >> > amount in
>>>>>>> >> > term of complexity. Also since I was the only author of it (my
>>>>>>> >> > teammates
>>>>>>> >> > will wait until I have added the signatures). There's absolutely
>>>>>>> >> > no need
>>>>>>> >> > of
>>>>>>> >> > code grant either.
>>>>>>> >>
>>>>>>> >> I agree on the code grant, b/c of it is really pretty trivial to
>>>>>>> >> create those API classes/interfaces
>>>>>>> >> (based on the javadoc log, as I said before).
>>>>>>> >> @signatures: you mean the iCLA / CCLA, aren't you ?
>>>>>>> >
>>>>>>> > nah, I meant method signatures, it will be easier for my teammates
>>>>>>> > to know
>>>>>>> > what they have to do once there's a nice // TODO: Convert to JSF
>>>>>>> > 2.0 added
>>>>>>> > in every new method's body.
>>>>>>> >
>>>>>>> > As far as I understand the legal issues (might have to fallback to
>>>>>>> > legal@apache.org though), they won't need a CLA until they become
>>>>>>> > commiters.
>>>>>>> > I don't know if I should have the company add their names to the
>>>>>>> > CCLA
>>>>>>>
>>>>>>> no. wrong
>>>>>>> cla == contributor license agreement.
>>>>>>> I usually ask for that after one or two patches. Never been an issue
>>>>>>> at all.
>>>>>>> We (from ORA) add those contributors to our CCLA, and fax the update
>>>>>>> to
>>>>>>> Sam Ruby (our ASF secretary).
>>>>>>>
>>>>>>> > however. Technically, we aren't bound contractualy by any
>>>>>>> > intellectual
>>>>>>> > property transfer with my employer and we're developping outside
>>>>>>> > normal
>>>>>>> > business hours so we aren't directly paid either for it so I don't
>>>>>>> > know if
>>>>>>> > adding their name to the CCLA is even needed or not.
>>>>>>>
>>>>>>> that means, what you develop on your sparetime is yours... NO CCLA
>>>>>>> update
>>>>>>> required. Cool
>>>>>>>
>>>>>>> -Matthias
>>>>>>>
>>>>>>> >
>>>>>>> >
>>>>>>> > ~ Simon
>>>>>>> >
>>>>>>> >>
>>>>>>> >> >
>>>>>>> >> >>
>>>>>>> >> >> And with 3 branches to now maintain, we need to discuss whether
>>>>>>> >> >> and
>>>>>>> >> >> when
>>>>>>> >> >> we phase out maintenance of the jsf-1.1 branch. Currently when
>>>>>>> >> >> users
>>>>>>> >> >> provide
>>>>>>> >> >> patches in jira, they almost always provide a patch against
>>>>>>> >> >> only one
>>>>>>> >> >> version
>>>>>>> >> >> and the committer ports it, which does increase the load on
>>>>>>> >> >> existing
>>>>>>> >> >> committers. When do we stop asking committers to do this when
>>>>>>> >> >> patching
>>>>>>> >> >> bugs?
>>>>>>> >> >
>>>>>>> >> > I can take care of the branch merging, this is how we handled
>>>>>>> >> > the
>>>>>>> >> > trinidad
>>>>>>> >> > 1.2 branch at first, Adam would do the merging every now and
>>>>>>> >> > then, so
>>>>>>> >> > I'm
>>>>>>> >> > not asking the committers to do some extra work.
>>>>>>> >>
>>>>>>> >> yup. not a big deal. Also I doubt that that many folks will work
>>>>>>> >> there, on the branch.
>>>>>>> >> If the branch needs some merging... fine as well, IMO.
>>>>>>> >>
>>>>>>> >> >
>>>>>>> >> >>
>>>>>>> >> >> To repeat, I'm *happy* that jsf2.0 implementation is in
>>>>>>> >> >> progress, and
>>>>>>> >> >> appreciate people contributing time to write an
>>>>>>> >> >> ASF-2.0-licensed
>>>>>>> >> >> implementation. But it is a  standard saying at Apache that
>>>>>>> >> >> "community
>>>>>>> >> >> is
>>>>>>> >> >> more important than code", and the "community" aspect here
>>>>>>> >> >> seems to
>>>>>>> >> >> have
>>>>>>> >> >> been rather neglected...
>>>>>>> >> >
>>>>>>> >> > I don't agree at all here. Although it wasn't announced on the
>>>>>>> >> > dev list,
>>>>>>> >> > the
>>>>>>> >> > JIRA ticket created to attach patches was speciafically for the
>>>>>>> >> > community.
>>>>>>> >>
>>>>>>> >> and the branch creation was also discussed.
>>>>>>> >>
>>>>>>> >> > Code provided by Fujitsu employees will never go through me with
>>>>>>> >> > direct
>>>>>>> >> > commit, it will all be added as patches, even extra tests and
>>>>>>> >> > documentation
>>>>>>> >> > as we want them and everyone else willing to help get the credit
>>>>>>> >> > for it.
>>>>>>> >>
>>>>>>> >> we do the same. Folks provide patches and jira tickets to describe
>>>>>>> >> the
>>>>>>> >> problem.
>>>>>>> >>
>>>>>>> >> > Furthermore, I personally didn't announce it because the branch
>>>>>>> >> > will be
>>>>>>> >> > very
>>>>>>> >> > instable for a week or two until we finish adding the missing
>>>>>>> >> > signatures
>>>>>>> >> > (impl might not even always compile).
>>>>>>> >>
>>>>>>> >> dev@ is a developers community; so that would be fine :-)
>>>>>>> >>
>>>>>>> >> -Matthias
>>>>>>> >>
>>>>>>> >> > If community wasn't important in the process we would just have
>>>>>>> >> > used a
>>>>>>> >> > private repository at Fujitsu, worked on it for some time with
>>>>>>> >> > my team,
>>>>>>> >> > then
>>>>>>> >> > commit some very large amount of code (real large) that would
>>>>>>> >> > have
>>>>>>> >> > needed a
>>>>>>> >> > code grant, prevented the people to see at what rythm things
>>>>>>> >> > were
>>>>>>> >> > progressing and contributing. The only point I *could* give you
>>>>>>> >> > here is
>>>>>>> >> > that
>>>>>>> >> > maybe I should have annouced the creation directly on the dev
>>>>>>> >> > list and
>>>>>>> >> > point
>>>>>>> >> > on the JIRA ticket and SVN url rather than relying only on JIRA
>>>>>>> >> > ticket
>>>>>>> >> > report that get forwarded on the dev list.
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> > Regards,
>>>>>>> >> >
>>>>>>> >> > ~ Simon
>>>>>>> >> >
>>>>>>> >> >>
>>>>>>> >> >> Regards,
>>>>>>> >> >> Simon
>>>>>>> >> >>
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >>
>>>>>>> >>
>>>>>>> >>
>>>>>>> >> --
>>>>>>> >> Matthias Wessendorf
>>>>>>> >>
>>>>>>> >> Need JSF and Web 2.0?
>>>>>>> >> http://code.google.com/p/facesgoodies
>>>>>>> >>
>>>>>>> >> further stuff:
>>>>>>> >> blog: http://matthiaswessendorf.wordpress.com/
>>>>>>> >> sessions: http://www.slideshare.net/mwessendorf
>>>>>>> >> mail: matzew-at-apache-dot-org
>>>>>>> >
>>>>>>> >
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Matthias Wessendorf
>>>>>>>
>>>>>>> Need JSF and Web 2.0?
>>>>>>> http://code.google.com/p/facesgoodies
>>>>>>>
>>>>>>> further stuff:
>>>>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>>>>> sessions: http://www.slideshare.net/mwessendorf
>>>>>>> mail: matzew-at-apache-dot-org
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Hazem Ahmed Saleh Ahmed
>>>> http://www.jroller.com/page/HazemBlog
>>>>
>>>> [Web 2.0] GMaps Integration with JSF + Apache Tomahawk + JBoss a4j :
>>>> http://code.google.com/p/gmaps4jsf/
>>>
>>
>
>



-- 
Matthias Wessendorf

Need JSF and Web 2.0?
http://code.google.com/p/facesgoodies

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

Re: JSF2.0 implementation

[Simon Lessard <si...@gmail.com>]

 I think you can only assign tickets to known contributors, that is JIRA
users with some special permissions, which is not the case for some people
on my team.

Of course, in the best world, assigning the ticket to yourself and mark it
as "In progress" would be the best way to prevent clashes.


~ Simon

On Fri, Aug 29, 2008 at 1:18 AM, Matthias Wessendorf
<mw...@gmail.com>wrote:

>
>
> Sent from my iPod.
>
> Am 29.08.2008 um 01:53 schrieb "Simon Lessard" <simon.lessard.3@gmail.com
> >:
>
> Ok,
>
> The branch is now compiling and TODOs of the following format were placed
> in the newly created methods : // TODO: JSF 2.0 #xx
>
> We also created a JIRA ticket of every of those TODOs, so if you feel like
> trying one, you can add a comment in JIRA saying that you're taking the
> ticker. Before taking a ticket, make sure that no one else is currently
> working on it to prevent clashes.
>
> That's why you can assign tickets.
>
> The next step on my side is to add more TODOs for the updated methods and
> create a JIRA ticket for them, then I'll get to coding myself.
>
>
> Thanks,
>
> ~ Simon
>
>
> On Thu, Aug 28, 2008 at 7:19 PM, Simon Lessard <<s...@gmail.com>
> simon.lessard.3@gmail.com> wrote:
>
>> Thank :) Although give me 10 minutes or so to fix something stupid I did
>> before doing a checkout.
>>
>>
>> Regards,
>>
>> ~ Simon
>>
>>
>> On Thu, Aug 28, 2008 at 7:16 PM, Hazem Saleh < <ha...@apache.org>
>> hazems@apache.org> wrote:
>>
>>> Thank you Simon. I will join this soon.
>>>
>>>
>>> On Thu, Aug 28, 2008 at 7:13 PM, Simon Lessard <<s...@gmail.com>
>>> simon.lessard.3@gmail.com> wrote:
>>>
>>>> Hi Bruno,
>>>>
>>>> So far my planing was:
>>>>
>>>> sequential
>>>> 1. Create all new API classes: done
>>>> 2. Add all new methods to the API, with empty TODO: JSF 2.0 comment in
>>>> their body when they aren't abstract: in progress and I already found some
>>>> strange stuff that I might raise on the EG group discussions as for why
>>>> Application.getResourceHandler isn't abstract while all other get handler
>>>> methods are: in progress
>>>>
>>>> *** At that point, IMPL will no longer compile ***
>>>>
>>>> 3. Add the missing signature in IMPL with empty TODO: JSF 2.0 comment in
>>>> their body
>>>>
>>>> *** Everything should compile but don't work at all ***
>>>>
>>>> parallel
>>>> 4. Modify the build plugin to include jsf 2.0 changes
>>>> 5. Implement the API changes
>>>> 6. Implement the IMPL changes
>>>> 7. Implement the JS library
>>>>
>>>> I would really like to use Facelets code when required, but we'll have
>>>> to make sure it's alright with legal discuss first I think, I'm not well
>>>> versed enough in this kind of very specific issues.
>>>>
>>>> It's a very high level roadmap, We should probably use much finer
>>>> granularity for point 5 to 7, but I'm not there yet.
>>>>
>>>>
>>>> Regards,
>>>>
>>>> ~ Simon
>>>>
>>>>
>>>> On Thu, Aug 28, 2008 at 11:30 AM, Bruno Aranda <<b...@gmail.com>
>>>> brunoaranda@gmail.com> wrote:
>>>>
>>>>> I am willing (as always) to contribute as much as my time permits to
>>>>> the JSF 2.0 implementation. I tried to find in the list what is going to be
>>>>> the big picture, the roadmap to have a JSF 2.0 implementation. Do we have
>>>>> something like that? How are we going to integrate Facelets, for instance?
>>>>> (good that is now under ASL!). What part are you developing at the moment?
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Bruno
>>>>>
>>>>> 2008/8/28 Matthias Wessendorf < <ma...@apache.org>
>>>>>
>>>>> On Thu, Aug 28, 2008 at 4:50 PM, Simon Lessard
>>>>>> < <si...@gmail.com> wrote:
>>>>>> >
>>>>>> >
>>>>>> > On Thu, Aug 28, 2008 at 10:35 AM, Matthias Wessendorf <<m...@apache.org>
>>>>>> matzew@apache.org>
>>>>>> > wrote:
>>>>>> >>
>>>>>> >> On Thu, Aug 28, 2008 at 4:24 PM, Simon Lessard
>>>>>> >> < <si...@gmail.com> wrote:
>>>>>> >> > Hi Simon,
>>>>>> >> >
>>>>>> >> >
>>>>>> >> > On Thu, Aug 28, 2008 at 2:56 AM, Simon Kitching <<s...@apache.org>
>>>>>> skitching@apache.org>
>>>>>> >> > wrote:
>>>>>> >> >>
>>>>>> >> >> I see from the commit list that a new JSF2.0 branch has been
>>>>>> created.
>>>>>> >> >>
>>>>>> >> >> I don't remember seeing *any* kind of discussion or even
>>>>>> announcement
>>>>>> >> >> about this. While I am happy to see JSF2.0 work going on, this
>>>>>> kind of
>>>>>> >> >> approach does not seem to be at all in the "community" spirit.
>>>>>> IMO,
>>>>>> >> >> major
>>>>>> >> >> events like this should be discussed beforehand.
>>>>>> >> >
>>>>>> >> > As mentioned by other people, there was a vote about this a while
>>>>>> back .
>>>>>> >> > Why
>>>>>> >> > did I create it just now? Simply because my company agreed to
>>>>>> provide
>>>>>> >> > some
>>>>>> >> > resource to help with the implementation and we were ready to get
>>>>>> >> > started.
>>>>>> >>
>>>>>> >> One might ask here for a CCLA ;-)
>>>>>> >> We did that for Oracle way back, and update once in a while all the
>>>>>> >> contributors,
>>>>>> >> that have signed the iCLA.
>>>>>> >
>>>>>> > Yeah, but Fujistu signed a CCLA already when I became commiter, so
>>>>>> that's a
>>>>>> > non issue as well.
>>>>>>
>>>>>> good.
>>>>>>
>>>>>> >
>>>>>> >>
>>>>>> >> >
>>>>>> >> >>
>>>>>> >> >> One issue, for example, is that the core-1.2 stuff is currently
>>>>>> >> >> half-way-converted from the trinidad plugins to the
>>>>>> >> >> myfaces-builder-plugin.
>>>>>> >> >> So now it is branched, any changes need to be applied in two
>>>>>> places.
>>>>>> >> >
>>>>>> >> > To be honest, I find this irrelevant, it's a branch, not a trunk
>>>>>> and
>>>>>> >> > I'll
>>>>>> >> > most likely do some branch merging when core 1.2.x get release
>>>>>> and the
>>>>>> >> > plugin might have to change a little to support jsfVersion 2.0.
>>>>>> >> >
>>>>>> >> >>
>>>>>> >> >> In addition, a large amount of code has just been committed by
>>>>>> someone
>>>>>> >> >> (slessard) who is not a particularly regular contributor to
>>>>>> myfaces.
>>>>>> >> >
>>>>>> >> > I see even less relevance in that statement.
>>>>>> >> >
>>>>>> >> >>
>>>>>> >> >> Where did this code come from? Do we need a code grant for it?
>>>>>> Note
>>>>>> >> >> that
>>>>>> >> >> when code is developed iteratively on the dev list then there is
>>>>>> no
>>>>>> >> >> need for
>>>>>> >> >> a grant. But a sudden code dump is different, even when
>>>>>> contributed by
>>>>>> >> >> someone who has signed a CLA.
>>>>>> >> >
>>>>>> >> > The code was coded just yesterday by me and is not much at all,
>>>>>> creating
>>>>>> >> > missing classes for the JavaDoc change log is in no matter a
>>>>>> large
>>>>>> >> > amount in
>>>>>> >> > term of complexity. Also since I was the only author of it (my
>>>>>> teammates
>>>>>> >> > will wait until I have added the signatures). There's absolutely
>>>>>> no need
>>>>>> >> > of
>>>>>> >> > code grant either.
>>>>>> >>
>>>>>> >> I agree on the code grant, b/c of it is really pretty trivial to
>>>>>> >> create those API classes/interfaces
>>>>>> >> (based on the javadoc log, as I said before).
>>>>>> >> @signatures: you mean the iCLA / CCLA, aren't you ?
>>>>>> >
>>>>>> > nah, I meant method signatures, it will be easier for my teammates
>>>>>> to know
>>>>>> > what they have to do once there's a nice // TODO: Convert to JSF 2.0
>>>>>> added
>>>>>> > in every new method's body.
>>>>>> >
>>>>>> > As far as I understand the legal issues (might have to fallback to
>>>>>> > <le...@apache.org>legal@apache.org though), they won't need a CLA
>>>>>> until they become commiters.
>>>>>> > I don't know if I should have the company add their names to the
>>>>>> CCLA
>>>>>>
>>>>>> no. wrong
>>>>>> cla == contributor license agreement.
>>>>>> I usually ask for that after one or two patches. Never been an issue
>>>>>> at all.
>>>>>> We (from ORA) add those contributors to our CCLA, and fax the update
>>>>>> to
>>>>>> Sam Ruby (our ASF secretary).
>>>>>>
>>>>>> > however. Technically, we aren't bound contractualy by any
>>>>>> intellectual
>>>>>> > property transfer with my employer and we're developping outside
>>>>>> normal
>>>>>> > business hours so we aren't directly paid either for it so I don't
>>>>>> know if
>>>>>> > adding their name to the CCLA is even needed or not.
>>>>>>
>>>>>> that means, what you develop on your sparetime is yours... NO CCLA
>>>>>> update
>>>>>> required. Cool
>>>>>>
>>>>>> -Matthias
>>>>>>
>>>>>> >
>>>>>> >
>>>>>> > ~ Simon
>>>>>> >
>>>>>> >>
>>>>>> >> >
>>>>>> >> >>
>>>>>> >> >> And with 3 branches to now maintain, we need to discuss whether
>>>>>> and
>>>>>> >> >> when
>>>>>> >> >> we phase out maintenance of the jsf-1.1 branch. Currently when
>>>>>> users
>>>>>> >> >> provide
>>>>>> >> >> patches in jira, they almost always provide a patch against only
>>>>>> one
>>>>>> >> >> version
>>>>>> >> >> and the committer ports it, which does increase the load on
>>>>>> existing
>>>>>> >> >> committers. When do we stop asking committers to do this when
>>>>>> patching
>>>>>> >> >> bugs?
>>>>>> >> >
>>>>>> >> > I can take care of the branch merging, this is how we handled the
>>>>>> >> > trinidad
>>>>>> >> > 1.2 branch at first, Adam would do the merging every now and
>>>>>> then, so
>>>>>> >> > I'm
>>>>>> >> > not asking the committers to do some extra work.
>>>>>> >>
>>>>>> >> yup. not a big deal. Also I doubt that that many folks will work
>>>>>> >> there, on the branch.
>>>>>> >> If the branch needs some merging... fine as well, IMO.
>>>>>> >>
>>>>>> >> >
>>>>>> >> >>
>>>>>> >> >> To repeat, I'm *happy* that jsf2.0 implementation is in
>>>>>> progress, and
>>>>>> >> >> appreciate people contributing time to write an ASF-2.0-licensed
>>>>>> >> >> implementation. But it is a  standard saying at Apache that
>>>>>> "community
>>>>>> >> >> is
>>>>>> >> >> more important than code", and the "community" aspect here seems
>>>>>> to
>>>>>> >> >> have
>>>>>> >> >> been rather neglected...
>>>>>> >> >
>>>>>> >> > I don't agree at all here. Although it wasn't announced on the
>>>>>> dev list,
>>>>>> >> > the
>>>>>> >> > JIRA ticket created to attach patches was speciafically for the
>>>>>> >> > community.
>>>>>> >>
>>>>>> >> and the branch creation was also discussed.
>>>>>> >>
>>>>>> >> > Code provided by Fujitsu employees will never go through me with
>>>>>> direct
>>>>>> >> > commit, it will all be added as patches, even extra tests and
>>>>>> >> > documentation
>>>>>> >> > as we want them and everyone else willing to help get the credit
>>>>>> for it.
>>>>>> >>
>>>>>> >> we do the same. Folks provide patches and jira tickets to describe
>>>>>> the
>>>>>> >> problem.
>>>>>> >>
>>>>>> >> > Furthermore, I personally didn't announce it because the branch
>>>>>> will be
>>>>>> >> > very
>>>>>> >> > instable for a week or two until we finish adding the missing
>>>>>> signatures
>>>>>> >> > (impl might not even always compile).
>>>>>> >>
>>>>>> >> dev@ is a developers community; so that would be fine :-)
>>>>>> >>
>>>>>> >> -Matthias
>>>>>> >>
>>>>>> >> > If community wasn't important in the process we would just have
>>>>>> used a
>>>>>> >> > private repository at Fujitsu, worked on it for some time with my
>>>>>> team,
>>>>>> >> > then
>>>>>> >> > commit some very large amount of code (real large) that would
>>>>>> have
>>>>>> >> > needed a
>>>>>> >> > code grant, prevented the people to see at what rythm things were
>>>>>> >> > progressing and contributing. The only point I *could* give you
>>>>>> here is
>>>>>> >> > that
>>>>>> >> > maybe I should have annouced the creation directly on the dev
>>>>>> list and
>>>>>> >> > point
>>>>>> >> > on the JIRA ticket and SVN url rather than relying only on JIRA
>>>>>> ticket
>>>>>> >> > report that get forwarded on the dev list.
>>>>>> >> >
>>>>>> >> >
>>>>>> >> > Regards,
>>>>>> >> >
>>>>>> >> > ~ Simon
>>>>>> >> >
>>>>>> >> >>
>>>>>> >> >> Regards,
>>>>>> >> >> Simon
>>>>>> >> >>
>>>>>> >> >
>>>>>> >> >
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >> --
>>>>>> >> Matthias Wessendorf
>>>>>> >>
>>>>>> >> Need JSF and Web 2.0?
>>>>>> >> <http://code.google.com/p/facesgoodies>
>>>>>> http://code.google.com/p/facesgoodies
>>>>>> >>
>>>>>> >> further stuff:
>>>>>> >> blog: <http://matthiaswessendorf.wordpress.com/>
>>>>>> http://matthiaswessendorf.wordpress.com/
>>>>>> >> sessions: <http://www.slideshare.net/mwessendorf>
>>>>>> http://www.slideshare.net/mwessendorf
>>>>>> >> mail: matzew-at-apache-dot-org
>>>>>> >
>>>>>> >
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Matthias Wessendorf
>>>>>>
>>>>>> Need JSF and Web 2.0?
>>>>>>  <http://code.google.com/p/facesgoodies>
>>>>>> http://code.google.com/p/facesgoodies
>>>>>>
>>>>>> further stuff:
>>>>>> blog: <http://matthiaswessendorf.wordpress.com/>
>>>>>> http://matthiaswessendorf.wordpress.com/
>>>>>> sessions: <http://www.slideshare.net/mwessendorf>
>>>>>> http://www.slideshare.net/mwessendorf
>>>>>> mail: matzew-at-apache-dot-org
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Hazem Ahmed Saleh Ahmed
>>> <http://www.jroller.com/page/HazemBlog>
>>> http://www.jroller.com/page/HazemBlog
>>>
>>> [Web 2.0] GMaps Integration with JSF + Apache Tomahawk + JBoss a4j :
>>>  <http://code.google.com/p/gmaps4jsf/>
>>> http://code.google.com/p/gmaps4jsf/
>>>
>>
>>
>

Re: JSF2.0 implementation

[Matthias Wessendorf <mw...@gmail.com>]

Sent from my iPod.

Am 29.08.2008 um 01:53 schrieb "Simon Lessard" <simon.lessard.3@gmail.com 
 >:

> Ok,
>
> The branch is now compiling and TODOs of the following format were  
> placed in the newly created methods : // TODO: JSF 2.0 #xx
>
> We also created a JIRA ticket of every of those TODOs, so if you  
> feel like trying one, you can add a comment in JIRA saying that  
> you're taking the ticker. Before taking a ticket, make sure that no  
> one else is currently working on it to prevent clashes.
>
That's why you can assign tickets.
> The next step on my side is to add more TODOs for the updated  
> methods and create a JIRA ticket for them, then I'll get to coding  
> myself.
>
>
> Thanks,
>
> ~ Simon
>
>
> On Thu, Aug 28, 2008 at 7:19 PM, Simon Lessard <simon.lessard.3@gmail.com 
> > wrote:
> Thank :) Although give me 10 minutes or so to fix something stupid I  
> did before doing a checkout.
>
>
> Regards,
>
> ~ Simon
>
>
> On Thu, Aug 28, 2008 at 7:16 PM, Hazem Saleh <ha...@apache.org>  
> wrote:
> Thank you Simon. I will join this soon.
>
>
> On Thu, Aug 28, 2008 at 7:13 PM, Simon Lessard <simon.lessard.3@gmail.com 
> > wrote:
> Hi Bruno,
>
> So far my planing was:
>
> sequential
> 1. Create all new API classes: done
> 2. Add all new methods to the API, with empty TODO: JSF 2.0 comment  
> in their body when they aren't abstract: in progress and I already  
> found some strange stuff that I might raise on the EG group  
> discussions as for why Application.getResourceHandler isn't abstract  
> while all other get handler methods are: in progress
>
> *** At that point, IMPL will no longer compile ***
>
> 3. Add the missing signature in IMPL with empty TODO: JSF 2.0  
> comment in their body
>
> *** Everything should compile but don't work at all ***
>
> parallel
> 4. Modify the build plugin to include jsf 2.0 changes
> 5. Implement the API changes
> 6. Implement the IMPL changes
> 7. Implement the JS library
>
> I would really like to use Facelets code when required, but we'll  
> have to make sure it's alright with legal discuss first I think, I'm  
> not well versed enough in this kind of very specific issues.
>
> It's a very high level roadmap, We should probably use much finer  
> granularity for point 5 to 7, but I'm not there yet.
>
>
> Regards,
>
> ~ Simon
>
>
> On Thu, Aug 28, 2008 at 11:30 AM, Bruno Aranda  
> <br...@gmail.com> wrote:
> I am willing (as always) to contribute as much as my time permits to  
> the JSF 2.0 implementation. I tried to find in the list what is  
> going to be the big picture, the roadmap to have a JSF 2.0  
> implementation. Do we have something like that? How are we going to  
> integrate Facelets, for instance? (good that is now under ASL!).  
> What part are you developing at the moment?
>
> Thanks!
>
> Bruno
>
> 2008/8/28 Matthias Wessendorf <ma...@apache.org>
>
> On Thu, Aug 28, 2008 at 4:50 PM, Simon Lessard
> <si...@gmail.com> wrote:
> >
> >
> > On Thu, Aug 28, 2008 at 10:35 AM, Matthias Wessendorf <matzew@apache.org 
> >
> > wrote:
> >>
> >> On Thu, Aug 28, 2008 at 4:24 PM, Simon Lessard
> >> <si...@gmail.com> wrote:
> >> > Hi Simon,
> >> >
> >> >
> >> > On Thu, Aug 28, 2008 at 2:56 AM, Simon Kitching <skitching@apache.org 
> >
> >> > wrote:
> >> >>
> >> >> I see from the commit list that a new JSF2.0 branch has been  
> created.
> >> >>
> >> >> I don't remember seeing *any* kind of discussion or even  
> announcement
> >> >> about this. While I am happy to see JSF2.0 work going on, this  
> kind of
> >> >> approach does not seem to be at all in the "community" spirit.  
> IMO,
> >> >> major
> >> >> events like this should be discussed beforehand.
> >> >
> >> > As mentioned by other people, there was a vote about this a  
> while back .
> >> > Why
> >> > did I create it just now? Simply because my company agreed to  
> provide
> >> > some
> >> > resource to help with the implementation and we were ready to get
> >> > started.
> >>
> >> One might ask here for a CCLA ;-)
> >> We did that for Oracle way back, and update once in a while all the
> >> contributors,
> >> that have signed the iCLA.
> >
> > Yeah, but Fujistu signed a CCLA already when I became commiter, so  
> that's a
> > non issue as well.
>
> good.
>
> >
> >>
> >> >
> >> >>
> >> >> One issue, for example, is that the core-1.2 stuff is currently
> >> >> half-way-converted from the trinidad plugins to the
> >> >> myfaces-builder-plugin.
> >> >> So now it is branched, any changes need to be applied in two  
> places.
> >> >
> >> > To be honest, I find this irrelevant, it's a branch, not a  
> trunk and
> >> > I'll
> >> > most likely do some branch merging when core 1.2.x get release  
> and the
> >> > plugin might have to change a little to support jsfVersion 2.0.
> >> >
> >> >>
> >> >> In addition, a large amount of code has just been committed by  
> someone
> >> >> (slessard) who is not a particularly regular contributor to  
> myfaces.
> >> >
> >> > I see even less relevance in that statement.
> >> >
> >> >>
> >> >> Where did this code come from? Do we need a code grant for it?  
> Note
> >> >> that
> >> >> when code is developed iteratively on the dev list then there  
> is no
> >> >> need for
> >> >> a grant. But a sudden code dump is different, even when  
> contributed by
> >> >> someone who has signed a CLA.
> >> >
> >> > The code was coded just yesterday by me and is not much at all,  
> creating
> >> > missing classes for the JavaDoc change log is in no matter a  
> large
> >> > amount in
> >> > term of complexity. Also since I was the only author of it (my  
> teammates
> >> > will wait until I have added the signatures). There's  
> absolutely no need
> >> > of
> >> > code grant either.
> >>
> >> I agree on the code grant, b/c of it is really pretty trivial to
> >> create those API classes/interfaces
> >> (based on the javadoc log, as I said before).
> >> @signatures: you mean the iCLA / CCLA, aren't you ?
> >
> > nah, I meant method signatures, it will be easier for my teammates  
> to know
> > what they have to do once there's a nice // TODO: Convert to JSF  
> 2.0 added
> > in every new method's body.
> >
> > As far as I understand the legal issues (might have to fallback to
> > legal@apache.org though), they won't need a CLA until they become  
> commiters.
> > I don't know if I should have the company add their names to the  
> CCLA
>
> no. wrong
> cla == contributor license agreement.
> I usually ask for that after one or two patches. Never been an issue  
> at all.
> We (from ORA) add those contributors to our CCLA, and fax the update  
> to
> Sam Ruby (our ASF secretary).
>
> > however. Technically, we aren't bound contractualy by any  
> intellectual
> > property transfer with my employer and we're developping outside  
> normal
> > business hours so we aren't directly paid either for it so I don't  
> know if
> > adding their name to the CCLA is even needed or not.
>
> that means, what you develop on your sparetime is yours... NO CCLA  
> update
> required. Cool
>
> -Matthias
>
> >
> >
> > ~ Simon
> >
> >>
> >> >
> >> >>
> >> >> And with 3 branches to now maintain, we need to discuss  
> whether and
> >> >> when
> >> >> we phase out maintenance of the jsf-1.1 branch. Currently when  
> users
> >> >> provide
> >> >> patches in jira, they almost always provide a patch against  
> only one
> >> >> version
> >> >> and the committer ports it, which does increase the load on  
> existing
> >> >> committers. When do we stop asking committers to do this when  
> patching
> >> >> bugs?
> >> >
> >> > I can take care of the branch merging, this is how we handled the
> >> > trinidad
> >> > 1.2 branch at first, Adam would do the merging every now and  
> then, so
> >> > I'm
> >> > not asking the committers to do some extra work.
> >>
> >> yup. not a big deal. Also I doubt that that many folks will work
> >> there, on the branch.
> >> If the branch needs some merging... fine as well, IMO.
> >>
> >> >
> >> >>
> >> >> To repeat, I'm *happy* that jsf2.0 implementation is in  
> progress, and
> >> >> appreciate people contributing time to write an ASF-2.0-licensed
> >> >> implementation. But it is a  standard saying at Apache that  
> "community
> >> >> is
> >> >> more important than code", and the "community" aspect here  
> seems to
> >> >> have
> >> >> been rather neglected...
> >> >
> >> > I don't agree at all here. Although it wasn't announced on the  
> dev list,
> >> > the
> >> > JIRA ticket created to attach patches was speciafically for the
> >> > community.
> >>
> >> and the branch creation was also discussed.
> >>
> >> > Code provided by Fujitsu employees will never go through me  
> with direct
> >> > commit, it will all be added as patches, even extra tests and
> >> > documentation
> >> > as we want them and everyone else willing to help get the  
> credit for it.
> >>
> >> we do the same. Folks provide patches and jira tickets to  
> describe the
> >> problem.
> >>
> >> > Furthermore, I personally didn't announce it because the branch  
> will be
> >> > very
> >> > instable for a week or two until we finish adding the missing  
> signatures
> >> > (impl might not even always compile).
> >>
> >> dev@ is a developers community; so that would be fine :-)
> >>
> >> -Matthias
> >>
> >> > If community wasn't important in the process we would just have  
> used a
> >> > private repository at Fujitsu, worked on it for some time with  
> my team,
> >> > then
> >> > commit some very large amount of code (real large) that would  
> have
> >> > needed a
> >> > code grant, prevented the people to see at what rythm things were
> >> > progressing and contributing. The only point I *could* give you  
> here is
> >> > that
> >> > maybe I should have annouced the creation directly on the dev  
> list and
> >> > point
> >> > on the JIRA ticket and SVN url rather than relying only on JIRA  
> ticket
> >> > report that get forwarded on the dev list.
> >> >
> >> >
> >> > Regards,
> >> >
> >> > ~ Simon
> >> >
> >> >>
> >> >> Regards,
> >> >> Simon
> >> >>
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> Matthias Wessendorf
> >>
> >> Need JSF and Web 2.0?
> >> http://code.google.com/p/facesgoodies
> >>
> >> further stuff:
> >> blog: http://matthiaswessendorf.wordpress.com/
> >> sessions: http://www.slideshare.net/mwessendorf
> >> mail: matzew-at-apache-dot-org
> >
> >
>
>
>
> --
> Matthias Wessendorf
>
> Need JSF and Web 2.0?
> http://code.google.com/p/facesgoodies
>
> further stuff:
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> mail: matzew-at-apache-dot-org
>
>
>
>
>
> -- 
> Hazem Ahmed Saleh Ahmed
> http://www.jroller.com/page/HazemBlog
>
> [Web 2.0] GMaps Integration with JSF + Apache Tomahawk + JBoss a4j :
> http://code.google.com/p/gmaps4jsf/
>
>

Re: JSF2.0 implementation

[Matthias Wessendorf <mw...@gmail.com>]

good point leo.
When needed we can create it, k?

Sent from my iPod.

Am 29.08.2008 um 02:11 schrieb "Leonardo Uribe" <lu...@gmail.com>:

>
>
> On Thu, Aug 28, 2008 at 6:55 PM, Hazem Saleh <ha...@apache.org>  
> wrote:
> Thank you Simon
>
>
> On Fri, Aug 29, 2008 at 2:53 AM, Simon Lessard <simon.lessard.3@gmail.com 
> > wrote:
> Ok,
>
> The branch is now compiling and TODOs of the following format were  
> placed in the newly created methods : // TODO: JSF 2.0 #xx
>
> We also created a JIRA ticket of every of those TODOs, so if you  
> feel like trying one, you can add a comment in JIRA saying that  
> you're taking the ticker. Before taking a ticket, make sure that no  
> one else is currently working on it to prevent clashes.
>
> The next step on my side is to add more TODOs for the updated  
> methods and create a JIRA ticket for them, then I'll get to coding  
> myself.
>
>
> Thanks,
>
> ~ Simon
>
>
>
> On Thu, Aug 28, 2008 at 7:19 PM, Simon Lessard <simon.lessard.3@gmail.com 
> > wrote:
> Thank :) Although give me 10 minutes or so to fix something stupid I  
> did before doing a checkout.
>
>
> Regards,
>
> ~ Simon
>
>
> On Thu, Aug 28, 2008 at 7:16 PM, Hazem Saleh <ha...@apache.org>  
> wrote:
> Thank you Simon. I will join this soon.
>
>
> On Thu, Aug 28, 2008 at 7:13 PM, Simon Lessard <simon.lessard.3@gmail.com 
> > wrote:
> Hi Bruno,
>
> So far my planing was:
>
> sequential
> 1. Create all new API classes: done
> 2. Add all new methods to the API, with empty TODO: JSF 2.0 comment  
> in their body when they aren't abstract: in progress and I already  
> found some strange stuff that I might raise on the EG group  
> discussions as for why Application.getResourceHandler isn't abstract  
> while all other get handler methods are: in progress
>
> *** At that point, IMPL will no longer compile ***
>
> 3. Add the missing signature in IMPL with empty TODO: JSF 2.0  
> comment in their body
>
> *** Everything should compile but don't work at all ***
>
> parallel
> 4. Modify the build plugin to include jsf 2.0 changes
> 5. Implement the API changes
> 6. Implement the IMPL changes
> 7. Implement the JS library
>
> I would really like to use Facelets code when required, but we'll  
> have to make sure it's alright with legal discuss first I think, I'm  
> not well versed enough in this kind of very specific issues.
>
> It's a very high level roadmap, We should probably use much finer  
> granularity for point 5 to 7, but I'm not there yet.
>
>
> Regards,
>
> ~ Simon
>
>
> On Thu, Aug 28, 2008 at 11:30 AM, Bruno Aranda  
> <br...@gmail.com> wrote:
> I am willing (as always) to contribute as much as my time permits to  
> the JSF 2.0 implementation. I tried to find in the list what is  
> going to be the big picture, the roadmap to have a JSF 2.0  
> implementation. Do we have something like that? How are we going to  
> integrate Facelets, for instance? (good that is now under ASL!).  
> What part are you developing at the moment?
>
> Thanks!
>
> Bruno
>
> 2008/8/28 Matthias Wessendorf <ma...@apache.org>
>
> On Thu, Aug 28, 2008 at 4:50 PM, Simon Lessard
> <si...@gmail.com> wrote:
> >
> >
> > On Thu, Aug 28, 2008 at 10:35 AM, Matthias Wessendorf <matzew@apache.org 
> >
> > wrote:
> >>
> >> On Thu, Aug 28, 2008 at 4:24 PM, Simon Lessard
> >> <si...@gmail.com> wrote:
> >> > Hi Simon,
> >> >
> >> >
> >> > On Thu, Aug 28, 2008 at 2:56 AM, Simon Kitching <skitching@apache.org 
> >
> >> > wrote:
> >> >>
> >> >> I see from the commit list that a new JSF2.0 branch has been  
> created.
> >> >>
> >> >> I don't remember seeing *any* kind of discussion or even  
> announcement
> >> >> about this. While I am happy to see JSF2.0 work going on, this  
> kind of
> >> >> approach does not seem to be at all in the "community" spirit.  
> IMO,
> >> >> major
> >> >> events like this should be discussed beforehand.
> >> >
> >> > As mentioned by other people, there was a vote about this a  
> while back .
> >> > Why
> >> > did I create it just now? Simply because my company agreed to  
> provide
> >> > some
> >> > resource to help with the implementation and we were ready to get
> >> > started.
> >>
> >> One might ask here for a CCLA ;-)
> >> We did that for Oracle way back, and update once in a while all the
> >> contributors,
> >> that have signed the iCLA.
> >
> > Yeah, but Fujistu signed a CCLA already when I became commiter, so  
> that's a
> > non issue as well.
>
> good.
>
> >
> >>
> >> >
> >> >>
> >> >> One issue, for example, is that the core-1.2 stuff is currently
> >> >> half-way-converted from the trinidad plugins to the
> >> >> myfaces-builder-plugin.
> >> >> So now it is branched, any changes need to be applied in two  
> places.
> >> >
> >> > To be honest, I find this irrelevant, it's a branch, not a  
> trunk and
> >> > I'll
> >> > most likely do some branch merging when core 1.2.x get release  
> and the
> >> > plugin might have to change a little to support jsfVersion 2.0.
> >> >
> >> >>
> >> >> In addition, a large amount of code has just been committed by  
> someone
> >> >> (slessard) who is not a particularly regular contributor to  
> myfaces.
> >> >
> >> > I see even less relevance in that statement.
> >> >
> >> >>
> >> >> Where did this code come from? Do we need a code grant for it?  
> Note
> >> >> that
> >> >> when code is developed iteratively on the dev list then there  
> is no
> >> >> need for
> >> >> a grant. But a sudden code dump is different, even when  
> contributed by
> >> >> someone who has signed a CLA.
> >> >
> >> > The code was coded just yesterday by me and is not much at all,  
> creating
> >> > missing classes for the JavaDoc change log is in no matter a  
> large
> >> > amount in
> >> > term of complexity. Also since I was the only author of it (my  
> teammates
> >> > will wait until I have added the signatures). There's  
> absolutely no need
> >> > of
> >> > code grant either.
> >>
> >> I agree on the code grant, b/c of it is really pretty trivial to
> >> create those API classes/interfaces
> >> (based on the javadoc log, as I said before).
> >> @signatures: you mean the iCLA / CCLA, aren't you ?
> >
> > nah, I meant method signatures, it will be easier for my teammates  
> to know
> > what they have to do once there's a nice // TODO: Convert to JSF  
> 2.0 added
> > in every new method's body.
> >
> > As far as I understand the legal issues (might have to fallback to
> > legal@apache.org though), they won't need a CLA until they become  
> commiters.
> > I don't know if I should have the company add their names to the  
> CCLA
>
> no. wrong
> cla == contributor license agreement.
> I usually ask for that after one or two patches. Never been an issue  
> at all.
> We (from ORA) add those contributors to our CCLA, and fax the update  
> to
> Sam Ruby (our ASF secretary).
>
> > however. Technically, we aren't bound contractualy by any  
> intellectual
> > property transfer with my employer and we're developping outside  
> normal
> > business hours so we aren't directly paid either for it so I don't  
> know if
> > adding their name to the CCLA is even needed or not.
>
> that means, what you develop on your sparetime is yours... NO CCLA  
> update
> required. Cool
>
> -Matthias
>
> >
> >
> > ~ Simon
> >
> >>
> >> >
> >> >>
> >> >> And with 3 branches to now maintain, we need to discuss  
> whether and
> >> >> when
> >> >> we phase out maintenance of the jsf-1.1 branch. Currently when  
> users
> >> >> provide
> >> >> patches in jira, they almost always provide a patch against  
> only one
> >> >> version
> >> >> and the committer ports it, which does increase the load on  
> existing
> >> >> committers. When do we stop asking committers to do this when  
> patching
> >> >> bugs?
> >> >
> >> > I can take care of the branch merging, this is how we handled the
> >> > trinidad
> >> > 1.2 branch at first, Adam would do the merging every now and  
> then, so
> >> > I'm
> >> > not asking the committers to do some extra work.
> >>
> >> yup. not a big deal. Also I doubt that that many folks will work
> >> there, on the branch.
> >> If the branch needs some merging... fine as well, IMO.
> >>
> >> >
> >> >>
> >> >> To repeat, I'm *happy* that jsf2.0 implementation is in  
> progress, and
> >> >> appreciate people contributing time to write an ASF-2.0-licensed
> >> >> implementation. But it is a  standard saying at Apache that  
> "community
> >> >> is
> >> >> more important than code", and the "community" aspect here  
> seems to
> >> >> have
> >> >> been rather neglected...
> >> >
> >> > I don't agree at all here. Although it wasn't announced on the  
> dev list,
> >> > the
> >> > JIRA ticket created to attach patches was speciafically for the
> >> > community.
> >>
> >> and the branch creation was also discussed.
> >>
> >> > Code provided by Fujitsu employees will never go through me  
> with direct
> >> > commit, it will all be added as patches, even extra tests and
> >> > documentation
> >> > as we want them and everyone else willing to help get the  
> credit for it.
> >>
> >> we do the same. Folks provide patches and jira tickets to  
> describe the
> >> problem.
> >>
> >> > Furthermore, I personally didn't announce it because the branch  
> will be
> >> > very
> >> > instable for a week or two until we finish adding the missing  
> signatures
> >> > (impl might not even always compile).
> >>
> >> dev@ is a developers community; so that would be fine :-)
> >>
> >> -Matthias
> >>
> >> > If community wasn't important in the process we would just have  
> used a
> >> > private repository at Fujitsu, worked on it for some time with  
> my team,
> >> > then
> >> > commit some very large amount of code (real large) that would  
> have
> >> > needed a
> >> > code grant, prevented the people to see at what rythm things were
> >> > progressing and contributing. The only point I *could* give you  
> here is
> >> > that
> >> > maybe I should have annouced the creation directly on the dev  
> list and
> >> > point
> >> > on the JIRA ticket and SVN url rather than relying only on JIRA  
> ticket
> >> > report that get forwarded on the dev list.
> >> >
> >> >
> >> > Regards,
> >> >
> >> > ~ Simon
> >> >
> >> >>
> >> >> Regards,
> >> >> Simon
> >> >>
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> Matthias Wessendorf
> >>
> >> Need JSF and Web 2.0?
> >> http://code.google.com/p/facesgoodies
> >>
> >> further stuff:
> >> blog: http://matthiaswessendorf.wordpress.com/
> >> sessions: http://www.slideshare.net/mwessendorf
> >> mail: matzew-at-apache-dot-org
> >
> >
>
>
>
> --
> Matthias Wessendorf
>
> Need JSF and Web 2.0?
> http://code.google.com/p/facesgoodies
>
> further stuff:
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> mail: matzew-at-apache-dot-org
>
>
>
>
>
> -- 
> Hazem Ahmed Saleh Ahmed
> http://www.jroller.com/page/HazemBlog
>
> [Web 2.0] GMaps Integration with JSF + Apache Tomahawk + JBoss a4j :
> http://code.google.com/p/gmaps4jsf/
>
>
>
>
>
> -- 
> Hazem Ahmed Saleh Ahmed
>
> Web blog:
>
> http://www.jroller.com/page/HazemBlog
>
> [Web 2.0] GMaps Integration with JSF + Apache Tomahawk + JBoss a4j:
> http://code.google.com/p/gmaps4jsf/
>
>
> Hi
>
> Just one question: as long as exists a 2.0.x branch of myfaces core,  
> should exists a branch for shared (4.0.x)? Changes on myfaces impl  
> could require changes on shared.
>
> regards
>
> Leonardo Uribe
>
>
>
> a>
>
>
> Hi
>
> Just one question: as long as exists a 2.0.x branch of myfaces core,  
> should exists a branch for shared (4.0.x)? Changes on myfaces impl  
> could require changes on shared.
>
> regards
>
> Leonardo Uribe
>
>
>
> v>

Re: JSF2.0 implementation

[Leonardo Uribe <lu...@gmail.com>]

On Thu, Aug 28, 2008 at 6:55 PM, Hazem Saleh <ha...@apache.org> wrote:

> Thank you Simon
>
>
> On Fri, Aug 29, 2008 at 2:53 AM, Simon Lessard <si...@gmail.com>wrote:
>
>> Ok,
>>
>> The branch is now compiling and TODOs of the following format were placed
>> in the newly created methods : // TODO: JSF 2.0 #xx
>>
>> We also created a JIRA ticket of every of those TODOs, so if you feel like
>> trying one, you can add a comment in JIRA saying that you're taking the
>> ticker. Before taking a ticket, make sure that no one else is currently
>> working on it to prevent clashes.
>>
>> The next step on my side is to add more TODOs for the updated methods and
>> create a JIRA ticket for them, then I'll get to coding myself.
>>
>>
>> Thanks,
>>
>> ~ Simon
>>
>>
>>
>> On Thu, Aug 28, 2008 at 7:19 PM, Simon Lessard <simon.lessard.3@gmail.com
>> > wrote:
>>
>>> Thank :) Although give me 10 minutes or so to fix something stupid I did
>>> before doing a checkout.
>>>
>>>
>>> Regards,
>>>
>>> ~ Simon
>>>
>>>
>>> On Thu, Aug 28, 2008 at 7:16 PM, Hazem Saleh <ha...@apache.org> wrote:
>>>
>>>> Thank you Simon. I will join this soon.
>>>>
>>>>
>>>> On Thu, Aug 28, 2008 at 7:13 PM, Simon Lessard <
>>>> simon.lessard.3@gmail.com> wrote:
>>>>
>>>>> Hi Bruno,
>>>>>
>>>>> So far my planing was:
>>>>>
>>>>> sequential
>>>>> 1. Create all new API classes: done
>>>>> 2. Add all new methods to the API, with empty TODO: JSF 2.0 comment in
>>>>> their body when they aren't abstract: in progress and I already found some
>>>>> strange stuff that I might raise on the EG group discussions as for why
>>>>> Application.getResourceHandler isn't abstract while all other get handler
>>>>> methods are: in progress
>>>>>
>>>>> *** At that point, IMPL will no longer compile ***
>>>>>
>>>>> 3. Add the missing signature in IMPL with empty TODO: JSF 2.0 comment
>>>>> in their body
>>>>>
>>>>> *** Everything should compile but don't work at all ***
>>>>>
>>>>> parallel
>>>>> 4. Modify the build plugin to include jsf 2.0 changes
>>>>> 5. Implement the API changes
>>>>> 6. Implement the IMPL changes
>>>>> 7. Implement the JS library
>>>>>
>>>>> I would really like to use Facelets code when required, but we'll have
>>>>> to make sure it's alright with legal discuss first I think, I'm not well
>>>>> versed enough in this kind of very specific issues.
>>>>>
>>>>> It's a very high level roadmap, We should probably use much finer
>>>>> granularity for point 5 to 7, but I'm not there yet.
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> ~ Simon
>>>>>
>>>>>
>>>>> On Thu, Aug 28, 2008 at 11:30 AM, Bruno Aranda <br...@gmail.com>wrote:
>>>>>
>>>>>> I am willing (as always) to contribute as much as my time permits to
>>>>>> the JSF 2.0 implementation. I tried to find in the list what is going to be
>>>>>> the big picture, the roadmap to have a JSF 2.0 implementation. Do we have
>>>>>> something like that? How are we going to integrate Facelets, for instance?
>>>>>> (good that is now under ASL!). What part are you developing at the moment?
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> Bruno
>>>>>>
>>>>>> 2008/8/28 Matthias Wessendorf <ma...@apache.org>
>>>>>>
>>>>>> On Thu, Aug 28, 2008 at 4:50 PM, Simon Lessard
>>>>>>> <si...@gmail.com> wrote:
>>>>>>> >
>>>>>>> >
>>>>>>> > On Thu, Aug 28, 2008 at 10:35 AM, Matthias Wessendorf <
>>>>>>> matzew@apache.org>
>>>>>>> > wrote:
>>>>>>> >>
>>>>>>> >> On Thu, Aug 28, 2008 at 4:24 PM, Simon Lessard
>>>>>>> >> <si...@gmail.com> wrote:
>>>>>>> >> > Hi Simon,
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> > On Thu, Aug 28, 2008 at 2:56 AM, Simon Kitching <
>>>>>>> skitching@apache.org>
>>>>>>> >> > wrote:
>>>>>>> >> >>
>>>>>>> >> >> I see from the commit list that a new JSF2.0 branch has been
>>>>>>> created.
>>>>>>> >> >>
>>>>>>> >> >> I don't remember seeing *any* kind of discussion or even
>>>>>>> announcement
>>>>>>> >> >> about this. While I am happy to see JSF2.0 work going on, this
>>>>>>> kind of
>>>>>>> >> >> approach does not seem to be at all in the "community" spirit.
>>>>>>> IMO,
>>>>>>> >> >> major
>>>>>>> >> >> events like this should be discussed beforehand.
>>>>>>> >> >
>>>>>>> >> > As mentioned by other people, there was a vote about this a
>>>>>>> while back .
>>>>>>> >> > Why
>>>>>>> >> > did I create it just now? Simply because my company agreed to
>>>>>>> provide
>>>>>>> >> > some
>>>>>>> >> > resource to help with the implementation and we were ready to
>>>>>>> get
>>>>>>> >> > started.
>>>>>>> >>
>>>>>>> >> One might ask here for a CCLA ;-)
>>>>>>> >> We did that for Oracle way back, and update once in a while all
>>>>>>> the
>>>>>>> >> contributors,
>>>>>>> >> that have signed the iCLA.
>>>>>>> >
>>>>>>> > Yeah, but Fujistu signed a CCLA already when I became commiter, so
>>>>>>> that's a
>>>>>>> > non issue as well.
>>>>>>>
>>>>>>> good.
>>>>>>>
>>>>>>> >
>>>>>>> >>
>>>>>>> >> >
>>>>>>> >> >>
>>>>>>> >> >> One issue, for example, is that the core-1.2 stuff is currently
>>>>>>> >> >> half-way-converted from the trinidad plugins to the
>>>>>>> >> >> myfaces-builder-plugin.
>>>>>>> >> >> So now it is branched, any changes need to be applied in two
>>>>>>> places.
>>>>>>> >> >
>>>>>>> >> > To be honest, I find this irrelevant, it's a branch, not a trunk
>>>>>>> and
>>>>>>> >> > I'll
>>>>>>> >> > most likely do some branch merging when core 1.2.x get release
>>>>>>> and the
>>>>>>> >> > plugin might have to change a little to support jsfVersion 2.0.
>>>>>>> >> >
>>>>>>> >> >>
>>>>>>> >> >> In addition, a large amount of code has just been committed by
>>>>>>> someone
>>>>>>> >> >> (slessard) who is not a particularly regular contributor to
>>>>>>> myfaces.
>>>>>>> >> >
>>>>>>> >> > I see even less relevance in that statement.
>>>>>>> >> >
>>>>>>> >> >>
>>>>>>> >> >> Where did this code come from? Do we need a code grant for it?
>>>>>>> Note
>>>>>>> >> >> that
>>>>>>> >> >> when code is developed iteratively on the dev list then there
>>>>>>> is no
>>>>>>> >> >> need for
>>>>>>> >> >> a grant. But a sudden code dump is different, even when
>>>>>>> contributed by
>>>>>>> >> >> someone who has signed a CLA.
>>>>>>> >> >
>>>>>>> >> > The code was coded just yesterday by me and is not much at all,
>>>>>>> creating
>>>>>>> >> > missing classes for the JavaDoc change log is in no matter a
>>>>>>> large
>>>>>>> >> > amount in
>>>>>>> >> > term of complexity. Also since I was the only author of it (my
>>>>>>> teammates
>>>>>>> >> > will wait until I have added the signatures). There's absolutely
>>>>>>> no need
>>>>>>> >> > of
>>>>>>> >> > code grant either.
>>>>>>> >>
>>>>>>> >> I agree on the code grant, b/c of it is really pretty trivial to
>>>>>>> >> create those API classes/interfaces
>>>>>>> >> (based on the javadoc log, as I said before).
>>>>>>> >> @signatures: you mean the iCLA / CCLA, aren't you ?
>>>>>>> >
>>>>>>> > nah, I meant method signatures, it will be easier for my teammates
>>>>>>> to know
>>>>>>> > what they have to do once there's a nice // TODO: Convert to JSF
>>>>>>> 2.0 added
>>>>>>> > in every new method's body.
>>>>>>> >
>>>>>>> > As far as I understand the legal issues (might have to fallback to
>>>>>>> > legal@apache.org though), they won't need a CLA until they become
>>>>>>> commiters.
>>>>>>> > I don't know if I should have the company add their names to the
>>>>>>> CCLA
>>>>>>>
>>>>>>> no. wrong
>>>>>>> cla == contributor license agreement.
>>>>>>> I usually ask for that after one or two patches. Never been an issue
>>>>>>> at all.
>>>>>>> We (from ORA) add those contributors to our CCLA, and fax the update
>>>>>>> to
>>>>>>> Sam Ruby (our ASF secretary).
>>>>>>>
>>>>>>> > however. Technically, we aren't bound contractualy by any
>>>>>>> intellectual
>>>>>>> > property transfer with my employer and we're developping outside
>>>>>>> normal
>>>>>>> > business hours so we aren't directly paid either for it so I don't
>>>>>>> know if
>>>>>>> > adding their name to the CCLA is even needed or not.
>>>>>>>
>>>>>>> that means, what you develop on your sparetime is yours... NO CCLA
>>>>>>> update
>>>>>>> required. Cool
>>>>>>>
>>>>>>> -Matthias
>>>>>>>
>>>>>>> >
>>>>>>> >
>>>>>>> > ~ Simon
>>>>>>> >
>>>>>>> >>
>>>>>>> >> >
>>>>>>> >> >>
>>>>>>> >> >> And with 3 branches to now maintain, we need to discuss whether
>>>>>>> and
>>>>>>> >> >> when
>>>>>>> >> >> we phase out maintenance of the jsf-1.1 branch. Currently when
>>>>>>> users
>>>>>>> >> >> provide
>>>>>>> >> >> patches in jira, they almost always provide a patch against
>>>>>>> only one
>>>>>>> >> >> version
>>>>>>> >> >> and the committer ports it, which does increase the load on
>>>>>>> existing
>>>>>>> >> >> committers. When do we stop asking committers to do this when
>>>>>>> patching
>>>>>>> >> >> bugs?
>>>>>>> >> >
>>>>>>> >> > I can take care of the branch merging, this is how we handled
>>>>>>> the
>>>>>>> >> > trinidad
>>>>>>> >> > 1.2 branch at first, Adam would do the merging every now and
>>>>>>> then, so
>>>>>>> >> > I'm
>>>>>>> >> > not asking the committers to do some extra work.
>>>>>>> >>
>>>>>>> >> yup. not a big deal. Also I doubt that that many folks will work
>>>>>>> >> there, on the branch.
>>>>>>> >> If the branch needs some merging... fine as well, IMO.
>>>>>>> >>
>>>>>>> >> >
>>>>>>> >> >>
>>>>>>> >> >> To repeat, I'm *happy* that jsf2.0 implementation is in
>>>>>>> progress, and
>>>>>>> >> >> appreciate people contributing time to write an
>>>>>>> ASF-2.0-licensed
>>>>>>> >> >> implementation. But it is a  standard saying at Apache that
>>>>>>> "community
>>>>>>> >> >> is
>>>>>>> >> >> more important than code", and the "community" aspect here
>>>>>>> seems to
>>>>>>> >> >> have
>>>>>>> >> >> been rather neglected...
>>>>>>> >> >
>>>>>>> >> > I don't agree at all here. Although it wasn't announced on the
>>>>>>> dev list,
>>>>>>> >> > the
>>>>>>> >> > JIRA ticket created to attach patches was speciafically for the
>>>>>>> >> > community.
>>>>>>> >>
>>>>>>> >> and the branch creation was also discussed.
>>>>>>> >>
>>>>>>> >> > Code provided by Fujitsu employees will never go through me with
>>>>>>> direct
>>>>>>> >> > commit, it will all be added as patches, even extra tests and
>>>>>>> >> > documentation
>>>>>>> >> > as we want them and everyone else willing to help get the credit
>>>>>>> for it.
>>>>>>> >>
>>>>>>> >> we do the same. Folks provide patches and jira tickets to describe
>>>>>>> the
>>>>>>> >> problem.
>>>>>>> >>
>>>>>>> >> > Furthermore, I personally didn't announce it because the branch
>>>>>>> will be
>>>>>>> >> > very
>>>>>>> >> > instable for a week or two until we finish adding the missing
>>>>>>> signatures
>>>>>>> >> > (impl might not even always compile).
>>>>>>> >>
>>>>>>> >> dev@ is a developers community; so that would be fine :-)
>>>>>>> >>
>>>>>>> >> -Matthias
>>>>>>> >>
>>>>>>> >> > If community wasn't important in the process we would just have
>>>>>>> used a
>>>>>>> >> > private repository at Fujitsu, worked on it for some time with
>>>>>>> my team,
>>>>>>> >> > then
>>>>>>> >> > commit some very large amount of code (real large) that would
>>>>>>> have
>>>>>>> >> > needed a
>>>>>>> >> > code grant, prevented the people to see at what rythm things
>>>>>>> were
>>>>>>> >> > progressing and contributing. The only point I *could* give you
>>>>>>> here is
>>>>>>> >> > that
>>>>>>> >> > maybe I should have annouced the creation directly on the dev
>>>>>>> list and
>>>>>>> >> > point
>>>>>>> >> > on the JIRA ticket and SVN url rather than relying only on JIRA
>>>>>>> ticket
>>>>>>> >> > report that get forwarded on the dev list.
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> > Regards,
>>>>>>> >> >
>>>>>>> >> > ~ Simon
>>>>>>> >> >
>>>>>>> >> >>
>>>>>>> >> >> Regards,
>>>>>>> >> >> Simon
>>>>>>> >> >>
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >>
>>>>>>> >>
>>>>>>> >>
>>>>>>> >> --
>>>>>>> >> Matthias Wessendorf
>>>>>>> >>
>>>>>>> >> Need JSF and Web 2.0?
>>>>>>> >> http://code.google.com/p/facesgoodies
>>>>>>> >>
>>>>>>> >> further stuff:
>>>>>>> >> blog: http://matthiaswessendorf.wordpress.com/
>>>>>>> >> sessions: http://www.slideshare.net/mwessendorf
>>>>>>> >> mail: matzew-at-apache-dot-org
>>>>>>> >
>>>>>>> >
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Matthias Wessendorf
>>>>>>>
>>>>>>> Need JSF and Web 2.0?
>>>>>>> http://code.google.com/p/facesgoodies
>>>>>>>
>>>>>>> further stuff:
>>>>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>>>>> sessions: http://www.slideshare.net/mwessendorf
>>>>>>> mail: matzew-at-apache-dot-org
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Hazem Ahmed Saleh Ahmed
>>>> http://www.jroller.com/page/HazemBlog
>>>>
>>>> [Web 2.0] GMaps Integration with JSF + Apache Tomahawk + JBoss a4j :
>>>> http://code.google.com/p/gmaps4jsf/
>>>>
>>>
>>>
>>
>
>
> --
> Hazem Ahmed Saleh Ahmed
>
> Web blog:
> http://www.jroller.com/page/HazemBlog
>
> [Web 2.0] GMaps Integration with JSF + Apache Tomahawk + JBoss a4j:
> http://code.google.com/p/gmaps4jsf/
>


Hi

Just one question: as long as exists a 2.0.x branch of myfaces core, should
exists a branch for shared (4.0.x)? Changes on myfaces impl could require
changes on shared.

regards

Leonardo Uribe

Re: JSF2.0 implementation

[Hazem Saleh <ha...@apache.org>]

Thank you Simon

On Fri, Aug 29, 2008 at 2:53 AM, Simon Lessard <si...@gmail.com>wrote:

> Ok,
>
> The branch is now compiling and TODOs of the following format were placed
> in the newly created methods : // TODO: JSF 2.0 #xx
>
> We also created a JIRA ticket of every of those TODOs, so if you feel like
> trying one, you can add a comment in JIRA saying that you're taking the
> ticker. Before taking a ticket, make sure that no one else is currently
> working on it to prevent clashes.
>
> The next step on my side is to add more TODOs for the updated methods and
> create a JIRA ticket for them, then I'll get to coding myself.
>
>
> Thanks,
>
> ~ Simon
>
>
>
> On Thu, Aug 28, 2008 at 7:19 PM, Simon Lessard <si...@gmail.com>wrote:
>
>> Thank :) Although give me 10 minutes or so to fix something stupid I did
>> before doing a checkout.
>>
>>
>> Regards,
>>
>> ~ Simon
>>
>>
>> On Thu, Aug 28, 2008 at 7:16 PM, Hazem Saleh <ha...@apache.org> wrote:
>>
>>> Thank you Simon. I will join this soon.
>>>
>>>
>>> On Thu, Aug 28, 2008 at 7:13 PM, Simon Lessard <
>>> simon.lessard.3@gmail.com> wrote:
>>>
>>>> Hi Bruno,
>>>>
>>>> So far my planing was:
>>>>
>>>> sequential
>>>> 1. Create all new API classes: done
>>>> 2. Add all new methods to the API, with empty TODO: JSF 2.0 comment in
>>>> their body when they aren't abstract: in progress and I already found some
>>>> strange stuff that I might raise on the EG group discussions as for why
>>>> Application.getResourceHandler isn't abstract while all other get handler
>>>> methods are: in progress
>>>>
>>>> *** At that point, IMPL will no longer compile ***
>>>>
>>>> 3. Add the missing signature in IMPL with empty TODO: JSF 2.0 comment in
>>>> their body
>>>>
>>>> *** Everything should compile but don't work at all ***
>>>>
>>>> parallel
>>>> 4. Modify the build plugin to include jsf 2.0 changes
>>>> 5. Implement the API changes
>>>> 6. Implement the IMPL changes
>>>> 7. Implement the JS library
>>>>
>>>> I would really like to use Facelets code when required, but we'll have
>>>> to make sure it's alright with legal discuss first I think, I'm not well
>>>> versed enough in this kind of very specific issues.
>>>>
>>>> It's a very high level roadmap, We should probably use much finer
>>>> granularity for point 5 to 7, but I'm not there yet.
>>>>
>>>>
>>>> Regards,
>>>>
>>>> ~ Simon
>>>>
>>>>
>>>> On Thu, Aug 28, 2008 at 11:30 AM, Bruno Aranda <br...@gmail.com>wrote:
>>>>
>>>>> I am willing (as always) to contribute as much as my time permits to
>>>>> the JSF 2.0 implementation. I tried to find in the list what is going to be
>>>>> the big picture, the roadmap to have a JSF 2.0 implementation. Do we have
>>>>> something like that? How are we going to integrate Facelets, for instance?
>>>>> (good that is now under ASL!). What part are you developing at the moment?
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Bruno
>>>>>
>>>>> 2008/8/28 Matthias Wessendorf <ma...@apache.org>
>>>>>
>>>>> On Thu, Aug 28, 2008 at 4:50 PM, Simon Lessard
>>>>>> <si...@gmail.com> wrote:
>>>>>> >
>>>>>> >
>>>>>> > On Thu, Aug 28, 2008 at 10:35 AM, Matthias Wessendorf <
>>>>>> matzew@apache.org>
>>>>>> > wrote:
>>>>>> >>
>>>>>> >> On Thu, Aug 28, 2008 at 4:24 PM, Simon Lessard
>>>>>> >> <si...@gmail.com> wrote:
>>>>>> >> > Hi Simon,
>>>>>> >> >
>>>>>> >> >
>>>>>> >> > On Thu, Aug 28, 2008 at 2:56 AM, Simon Kitching <
>>>>>> skitching@apache.org>
>>>>>> >> > wrote:
>>>>>> >> >>
>>>>>> >> >> I see from the commit list that a new JSF2.0 branch has been
>>>>>> created.
>>>>>> >> >>
>>>>>> >> >> I don't remember seeing *any* kind of discussion or even
>>>>>> announcement
>>>>>> >> >> about this. While I am happy to see JSF2.0 work going on, this
>>>>>> kind of
>>>>>> >> >> approach does not seem to be at all in the "community" spirit.
>>>>>> IMO,
>>>>>> >> >> major
>>>>>> >> >> events like this should be discussed beforehand.
>>>>>> >> >
>>>>>> >> > As mentioned by other people, there was a vote about this a while
>>>>>> back .
>>>>>> >> > Why
>>>>>> >> > did I create it just now? Simply because my company agreed to
>>>>>> provide
>>>>>> >> > some
>>>>>> >> > resource to help with the implementation and we were ready to get
>>>>>> >> > started.
>>>>>> >>
>>>>>> >> One might ask here for a CCLA ;-)
>>>>>> >> We did that for Oracle way back, and update once in a while all the
>>>>>> >> contributors,
>>>>>> >> that have signed the iCLA.
>>>>>> >
>>>>>> > Yeah, but Fujistu signed a CCLA already when I became commiter, so
>>>>>> that's a
>>>>>> > non issue as well.
>>>>>>
>>>>>> good.
>>>>>>
>>>>>> >
>>>>>> >>
>>>>>> >> >
>>>>>> >> >>
>>>>>> >> >> One issue, for example, is that the core-1.2 stuff is currently
>>>>>> >> >> half-way-converted from the trinidad plugins to the
>>>>>> >> >> myfaces-builder-plugin.
>>>>>> >> >> So now it is branched, any changes need to be applied in two
>>>>>> places.
>>>>>> >> >
>>>>>> >> > To be honest, I find this irrelevant, it's a branch, not a trunk
>>>>>> and
>>>>>> >> > I'll
>>>>>> >> > most likely do some branch merging when core 1.2.x get release
>>>>>> and the
>>>>>> >> > plugin might have to change a little to support jsfVersion 2.0.
>>>>>> >> >
>>>>>> >> >>
>>>>>> >> >> In addition, a large amount of code has just been committed by
>>>>>> someone
>>>>>> >> >> (slessard) who is not a particularly regular contributor to
>>>>>> myfaces.
>>>>>> >> >
>>>>>> >> > I see even less relevance in that statement.
>>>>>> >> >
>>>>>> >> >>
>>>>>> >> >> Where did this code come from? Do we need a code grant for it?
>>>>>> Note
>>>>>> >> >> that
>>>>>> >> >> when code is developed iteratively on the dev list then there is
>>>>>> no
>>>>>> >> >> need for
>>>>>> >> >> a grant. But a sudden code dump is different, even when
>>>>>> contributed by
>>>>>> >> >> someone who has signed a CLA.
>>>>>> >> >
>>>>>> >> > The code was coded just yesterday by me and is not much at all,
>>>>>> creating
>>>>>> >> > missing classes for the JavaDoc change log is in no matter a
>>>>>> large
>>>>>> >> > amount in
>>>>>> >> > term of complexity. Also since I was the only author of it (my
>>>>>> teammates
>>>>>> >> > will wait until I have added the signatures). There's absolutely
>>>>>> no need
>>>>>> >> > of
>>>>>> >> > code grant either.
>>>>>> >>
>>>>>> >> I agree on the code grant, b/c of it is really pretty trivial to
>>>>>> >> create those API classes/interfaces
>>>>>> >> (based on the javadoc log, as I said before).
>>>>>> >> @signatures: you mean the iCLA / CCLA, aren't you ?
>>>>>> >
>>>>>> > nah, I meant method signatures, it will be easier for my teammates
>>>>>> to know
>>>>>> > what they have to do once there's a nice // TODO: Convert to JSF 2.0
>>>>>> added
>>>>>> > in every new method's body.
>>>>>> >
>>>>>> > As far as I understand the legal issues (might have to fallback to
>>>>>> > legal@apache.org though), they won't need a CLA until they become
>>>>>> commiters.
>>>>>> > I don't know if I should have the company add their names to the
>>>>>> CCLA
>>>>>>
>>>>>> no. wrong
>>>>>> cla == contributor license agreement.
>>>>>> I usually ask for that after one or two patches. Never been an issue
>>>>>> at all.
>>>>>> We (from ORA) add those contributors to our CCLA, and fax the update
>>>>>> to
>>>>>> Sam Ruby (our ASF secretary).
>>>>>>
>>>>>> > however. Technically, we aren't bound contractualy by any
>>>>>> intellectual
>>>>>> > property transfer with my employer and we're developping outside
>>>>>> normal
>>>>>> > business hours so we aren't directly paid either for it so I don't
>>>>>> know if
>>>>>> > adding their name to the CCLA is even needed or not.
>>>>>>
>>>>>> that means, what you develop on your sparetime is yours... NO CCLA
>>>>>> update
>>>>>> required. Cool
>>>>>>
>>>>>> -Matthias
>>>>>>
>>>>>> >
>>>>>> >
>>>>>> > ~ Simon
>>>>>> >
>>>>>> >>
>>>>>> >> >
>>>>>> >> >>
>>>>>> >> >> And with 3 branches to now maintain, we need to discuss whether
>>>>>> and
>>>>>> >> >> when
>>>>>> >> >> we phase out maintenance of the jsf-1.1 branch. Currently when
>>>>>> users
>>>>>> >> >> provide
>>>>>> >> >> patches in jira, they almost always provide a patch against only
>>>>>> one
>>>>>> >> >> version
>>>>>> >> >> and the committer ports it, which does increase the load on
>>>>>> existing
>>>>>> >> >> committers. When do we stop asking committers to do this when
>>>>>> patching
>>>>>> >> >> bugs?
>>>>>> >> >
>>>>>> >> > I can take care of the branch merging, this is how we handled the
>>>>>> >> > trinidad
>>>>>> >> > 1.2 branch at first, Adam would do the merging every now and
>>>>>> then, so
>>>>>> >> > I'm
>>>>>> >> > not asking the committers to do some extra work.
>>>>>> >>
>>>>>> >> yup. not a big deal. Also I doubt that that many folks will work
>>>>>> >> there, on the branch.
>>>>>> >> If the branch needs some merging... fine as well, IMO.
>>>>>> >>
>>>>>> >> >
>>>>>> >> >>
>>>>>> >> >> To repeat, I'm *happy* that jsf2.0 implementation is in
>>>>>> progress, and
>>>>>> >> >> appreciate people contributing time to write an ASF-2.0-licensed
>>>>>> >> >> implementation. But it is a  standard saying at Apache that
>>>>>> "community
>>>>>> >> >> is
>>>>>> >> >> more important than code", and the "community" aspect here seems
>>>>>> to
>>>>>> >> >> have
>>>>>> >> >> been rather neglected...
>>>>>> >> >
>>>>>> >> > I don't agree at all here. Although it wasn't announced on the
>>>>>> dev list,
>>>>>> >> > the
>>>>>> >> > JIRA ticket created to attach patches was speciafically for the
>>>>>> >> > community.
>>>>>> >>
>>>>>> >> and the branch creation was also discussed.
>>>>>> >>
>>>>>> >> > Code provided by Fujitsu employees will never go through me with
>>>>>> direct
>>>>>> >> > commit, it will all be added as patches, even extra tests and
>>>>>> >> > documentation
>>>>>> >> > as we want them and everyone else willing to help get the credit
>>>>>> for it.
>>>>>> >>
>>>>>> >> we do the same. Folks provide patches and jira tickets to describe
>>>>>> the
>>>>>> >> problem.
>>>>>> >>
>>>>>> >> > Furthermore, I personally didn't announce it because the branch
>>>>>> will be
>>>>>> >> > very
>>>>>> >> > instable for a week or two until we finish adding the missing
>>>>>> signatures
>>>>>> >> > (impl might not even always compile).
>>>>>> >>
>>>>>> >> dev@ is a developers community; so that would be fine :-)
>>>>>> >>
>>>>>> >> -Matthias
>>>>>> >>
>>>>>> >> > If community wasn't important in the process we would just have
>>>>>> used a
>>>>>> >> > private repository at Fujitsu, worked on it for some time with my
>>>>>> team,
>>>>>> >> > then
>>>>>> >> > commit some very large amount of code (real large) that would
>>>>>> have
>>>>>> >> > needed a
>>>>>> >> > code grant, prevented the people to see at what rythm things were
>>>>>> >> > progressing and contributing. The only point I *could* give you
>>>>>> here is
>>>>>> >> > that
>>>>>> >> > maybe I should have annouced the creation directly on the dev
>>>>>> list and
>>>>>> >> > point
>>>>>> >> > on the JIRA ticket and SVN url rather than relying only on JIRA
>>>>>> ticket
>>>>>> >> > report that get forwarded on the dev list.
>>>>>> >> >
>>>>>> >> >
>>>>>> >> > Regards,
>>>>>> >> >
>>>>>> >> > ~ Simon
>>>>>> >> >
>>>>>> >> >>
>>>>>> >> >> Regards,
>>>>>> >> >> Simon
>>>>>> >> >>
>>>>>> >> >
>>>>>> >> >
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >> --
>>>>>> >> Matthias Wessendorf
>>>>>> >>
>>>>>> >> Need JSF and Web 2.0?
>>>>>> >> http://code.google.com/p/facesgoodies
>>>>>> >>
>>>>>> >> further stuff:
>>>>>> >> blog: http://matthiaswessendorf.wordpress.com/
>>>>>> >> sessions: http://www.slideshare.net/mwessendorf
>>>>>> >> mail: matzew-at-apache-dot-org
>>>>>> >
>>>>>> >
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Matthias Wessendorf
>>>>>>
>>>>>> Need JSF and Web 2.0?
>>>>>> http://code.google.com/p/facesgoodies
>>>>>>
>>>>>> further stuff:
>>>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>>>> sessions: http://www.slideshare.net/mwessendorf
>>>>>> mail: matzew-at-apache-dot-org
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Hazem Ahmed Saleh Ahmed
>>> http://www.jroller.com/page/HazemBlog
>>>
>>> [Web 2.0] GMaps Integration with JSF + Apache Tomahawk + JBoss a4j :
>>> http://code.google.com/p/gmaps4jsf/
>>>
>>
>>
>


-- 
Hazem Ahmed Saleh Ahmed

Web blog:
http://www.jroller.com/page/HazemBlog

[Web 2.0] GMaps Integration with JSF + Apache Tomahawk + JBoss a4j:
http://code.google.com/p/gmaps4jsf/

Re: JSF2.0 implementation

[Simon Lessard <si...@gmail.com>]

Ok,

The branch is now compiling and TODOs of the following format were placed in
the newly created methods : // TODO: JSF 2.0 #xx

We also created a JIRA ticket of every of those TODOs, so if you feel like
trying one, you can add a comment in JIRA saying that you're taking the
ticker. Before taking a ticket, make sure that no one else is currently
working on it to prevent clashes.

The next step on my side is to add more TODOs for the updated methods and
create a JIRA ticket for them, then I'll get to coding myself.


Thanks,

~ Simon


On Thu, Aug 28, 2008 at 7:19 PM, Simon Lessard <si...@gmail.com>wrote:

> Thank :) Although give me 10 minutes or so to fix something stupid I did
> before doing a checkout.
>
>
> Regards,
>
> ~ Simon
>
>
> On Thu, Aug 28, 2008 at 7:16 PM, Hazem Saleh <ha...@apache.org> wrote:
>
>> Thank you Simon. I will join this soon.
>>
>>
>> On Thu, Aug 28, 2008 at 7:13 PM, Simon Lessard <simon.lessard.3@gmail.com
>> > wrote:
>>
>>> Hi Bruno,
>>>
>>> So far my planing was:
>>>
>>> sequential
>>> 1. Create all new API classes: done
>>> 2. Add all new methods to the API, with empty TODO: JSF 2.0 comment in
>>> their body when they aren't abstract: in progress and I already found some
>>> strange stuff that I might raise on the EG group discussions as for why
>>> Application.getResourceHandler isn't abstract while all other get handler
>>> methods are: in progress
>>>
>>> *** At that point, IMPL will no longer compile ***
>>>
>>> 3. Add the missing signature in IMPL with empty TODO: JSF 2.0 comment in
>>> their body
>>>
>>> *** Everything should compile but don't work at all ***
>>>
>>> parallel
>>> 4. Modify the build plugin to include jsf 2.0 changes
>>> 5. Implement the API changes
>>> 6. Implement the IMPL changes
>>> 7. Implement the JS library
>>>
>>> I would really like to use Facelets code when required, but we'll have to
>>> make sure it's alright with legal discuss first I think, I'm not well versed
>>> enough in this kind of very specific issues.
>>>
>>> It's a very high level roadmap, We should probably use much finer
>>> granularity for point 5 to 7, but I'm not there yet.
>>>
>>>
>>> Regards,
>>>
>>> ~ Simon
>>>
>>>
>>> On Thu, Aug 28, 2008 at 11:30 AM, Bruno Aranda <br...@gmail.com>wrote:
>>>
>>>> I am willing (as always) to contribute as much as my time permits to the
>>>> JSF 2.0 implementation. I tried to find in the list what is going to be the
>>>> big picture, the roadmap to have a JSF 2.0 implementation. Do we have
>>>> something like that? How are we going to integrate Facelets, for instance?
>>>> (good that is now under ASL!). What part are you developing at the moment?
>>>>
>>>> Thanks!
>>>>
>>>> Bruno
>>>>
>>>> 2008/8/28 Matthias Wessendorf <ma...@apache.org>
>>>>
>>>> On Thu, Aug 28, 2008 at 4:50 PM, Simon Lessard
>>>>> <si...@gmail.com> wrote:
>>>>> >
>>>>> >
>>>>> > On Thu, Aug 28, 2008 at 10:35 AM, Matthias Wessendorf <
>>>>> matzew@apache.org>
>>>>> > wrote:
>>>>> >>
>>>>> >> On Thu, Aug 28, 2008 at 4:24 PM, Simon Lessard
>>>>> >> <si...@gmail.com> wrote:
>>>>> >> > Hi Simon,
>>>>> >> >
>>>>> >> >
>>>>> >> > On Thu, Aug 28, 2008 at 2:56 AM, Simon Kitching <
>>>>> skitching@apache.org>
>>>>> >> > wrote:
>>>>> >> >>
>>>>> >> >> I see from the commit list that a new JSF2.0 branch has been
>>>>> created.
>>>>> >> >>
>>>>> >> >> I don't remember seeing *any* kind of discussion or even
>>>>> announcement
>>>>> >> >> about this. While I am happy to see JSF2.0 work going on, this
>>>>> kind of
>>>>> >> >> approach does not seem to be at all in the "community" spirit.
>>>>> IMO,
>>>>> >> >> major
>>>>> >> >> events like this should be discussed beforehand.
>>>>> >> >
>>>>> >> > As mentioned by other people, there was a vote about this a while
>>>>> back .
>>>>> >> > Why
>>>>> >> > did I create it just now? Simply because my company agreed to
>>>>> provide
>>>>> >> > some
>>>>> >> > resource to help with the implementation and we were ready to get
>>>>> >> > started.
>>>>> >>
>>>>> >> One might ask here for a CCLA ;-)
>>>>> >> We did that for Oracle way back, and update once in a while all the
>>>>> >> contributors,
>>>>> >> that have signed the iCLA.
>>>>> >
>>>>> > Yeah, but Fujistu signed a CCLA already when I became commiter, so
>>>>> that's a
>>>>> > non issue as well.
>>>>>
>>>>> good.
>>>>>
>>>>> >
>>>>> >>
>>>>> >> >
>>>>> >> >>
>>>>> >> >> One issue, for example, is that the core-1.2 stuff is currently
>>>>> >> >> half-way-converted from the trinidad plugins to the
>>>>> >> >> myfaces-builder-plugin.
>>>>> >> >> So now it is branched, any changes need to be applied in two
>>>>> places.
>>>>> >> >
>>>>> >> > To be honest, I find this irrelevant, it's a branch, not a trunk
>>>>> and
>>>>> >> > I'll
>>>>> >> > most likely do some branch merging when core 1.2.x get release and
>>>>> the
>>>>> >> > plugin might have to change a little to support jsfVersion 2.0.
>>>>> >> >
>>>>> >> >>
>>>>> >> >> In addition, a large amount of code has just been committed by
>>>>> someone
>>>>> >> >> (slessard) who is not a particularly regular contributor to
>>>>> myfaces.
>>>>> >> >
>>>>> >> > I see even less relevance in that statement.
>>>>> >> >
>>>>> >> >>
>>>>> >> >> Where did this code come from? Do we need a code grant for it?
>>>>> Note
>>>>> >> >> that
>>>>> >> >> when code is developed iteratively on the dev list then there is
>>>>> no
>>>>> >> >> need for
>>>>> >> >> a grant. But a sudden code dump is different, even when
>>>>> contributed by
>>>>> >> >> someone who has signed a CLA.
>>>>> >> >
>>>>> >> > The code was coded just yesterday by me and is not much at all,
>>>>> creating
>>>>> >> > missing classes for the JavaDoc change log is in no matter a large
>>>>> >> > amount in
>>>>> >> > term of complexity. Also since I was the only author of it (my
>>>>> teammates
>>>>> >> > will wait until I have added the signatures). There's absolutely
>>>>> no need
>>>>> >> > of
>>>>> >> > code grant either.
>>>>> >>
>>>>> >> I agree on the code grant, b/c of it is really pretty trivial to
>>>>> >> create those API classes/interfaces
>>>>> >> (based on the javadoc log, as I said before).
>>>>> >> @signatures: you mean the iCLA / CCLA, aren't you ?
>>>>> >
>>>>> > nah, I meant method signatures, it will be easier for my teammates to
>>>>> know
>>>>> > what they have to do once there's a nice // TODO: Convert to JSF 2.0
>>>>> added
>>>>> > in every new method's body.
>>>>> >
>>>>> > As far as I understand the legal issues (might have to fallback to
>>>>> > legal@apache.org though), they won't need a CLA until they become
>>>>> commiters.
>>>>> > I don't know if I should have the company add their names to the CCLA
>>>>>
>>>>> no. wrong
>>>>> cla == contributor license agreement.
>>>>> I usually ask for that after one or two patches. Never been an issue at
>>>>> all.
>>>>> We (from ORA) add those contributors to our CCLA, and fax the update to
>>>>> Sam Ruby (our ASF secretary).
>>>>>
>>>>> > however. Technically, we aren't bound contractualy by any
>>>>> intellectual
>>>>> > property transfer with my employer and we're developping outside
>>>>> normal
>>>>> > business hours so we aren't directly paid either for it so I don't
>>>>> know if
>>>>> > adding their name to the CCLA is even needed or not.
>>>>>
>>>>> that means, what you develop on your sparetime is yours... NO CCLA
>>>>> update
>>>>> required. Cool
>>>>>
>>>>> -Matthias
>>>>>
>>>>> >
>>>>> >
>>>>> > ~ Simon
>>>>> >
>>>>> >>
>>>>> >> >
>>>>> >> >>
>>>>> >> >> And with 3 branches to now maintain, we need to discuss whether
>>>>> and
>>>>> >> >> when
>>>>> >> >> we phase out maintenance of the jsf-1.1 branch. Currently when
>>>>> users
>>>>> >> >> provide
>>>>> >> >> patches in jira, they almost always provide a patch against only
>>>>> one
>>>>> >> >> version
>>>>> >> >> and the committer ports it, which does increase the load on
>>>>> existing
>>>>> >> >> committers. When do we stop asking committers to do this when
>>>>> patching
>>>>> >> >> bugs?
>>>>> >> >
>>>>> >> > I can take care of the branch merging, this is how we handled the
>>>>> >> > trinidad
>>>>> >> > 1.2 branch at first, Adam would do the merging every now and then,
>>>>> so
>>>>> >> > I'm
>>>>> >> > not asking the committers to do some extra work.
>>>>> >>
>>>>> >> yup. not a big deal. Also I doubt that that many folks will work
>>>>> >> there, on the branch.
>>>>> >> If the branch needs some merging... fine as well, IMO.
>>>>> >>
>>>>> >> >
>>>>> >> >>
>>>>> >> >> To repeat, I'm *happy* that jsf2.0 implementation is in progress,
>>>>> and
>>>>> >> >> appreciate people contributing time to write an ASF-2.0-licensed
>>>>> >> >> implementation. But it is a  standard saying at Apache that
>>>>> "community
>>>>> >> >> is
>>>>> >> >> more important than code", and the "community" aspect here seems
>>>>> to
>>>>> >> >> have
>>>>> >> >> been rather neglected...
>>>>> >> >
>>>>> >> > I don't agree at all here. Although it wasn't announced on the dev
>>>>> list,
>>>>> >> > the
>>>>> >> > JIRA ticket created to attach patches was speciafically for the
>>>>> >> > community.
>>>>> >>
>>>>> >> and the branch creation was also discussed.
>>>>> >>
>>>>> >> > Code provided by Fujitsu employees will never go through me with
>>>>> direct
>>>>> >> > commit, it will all be added as patches, even extra tests and
>>>>> >> > documentation
>>>>> >> > as we want them and everyone else willing to help get the credit
>>>>> for it.
>>>>> >>
>>>>> >> we do the same. Folks provide patches and jira tickets to describe
>>>>> the
>>>>> >> problem.
>>>>> >>
>>>>> >> > Furthermore, I personally didn't announce it because the branch
>>>>> will be
>>>>> >> > very
>>>>> >> > instable for a week or two until we finish adding the missing
>>>>> signatures
>>>>> >> > (impl might not even always compile).
>>>>> >>
>>>>> >> dev@ is a developers community; so that would be fine :-)
>>>>> >>
>>>>> >> -Matthias
>>>>> >>
>>>>> >> > If community wasn't important in the process we would just have
>>>>> used a
>>>>> >> > private repository at Fujitsu, worked on it for some time with my
>>>>> team,
>>>>> >> > then
>>>>> >> > commit some very large amount of code (real large) that would have
>>>>> >> > needed a
>>>>> >> > code grant, prevented the people to see at what rythm things were
>>>>> >> > progressing and contributing. The only point I *could* give you
>>>>> here is
>>>>> >> > that
>>>>> >> > maybe I should have annouced the creation directly on the dev list
>>>>> and
>>>>> >> > point
>>>>> >> > on the JIRA ticket and SVN url rather than relying only on JIRA
>>>>> ticket
>>>>> >> > report that get forwarded on the dev list.
>>>>> >> >
>>>>> >> >
>>>>> >> > Regards,
>>>>> >> >
>>>>> >> > ~ Simon
>>>>> >> >
>>>>> >> >>
>>>>> >> >> Regards,
>>>>> >> >> Simon
>>>>> >> >>
>>>>> >> >
>>>>> >> >
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> --
>>>>> >> Matthias Wessendorf
>>>>> >>
>>>>> >> Need JSF and Web 2.0?
>>>>> >> http://code.google.com/p/facesgoodies
>>>>> >>
>>>>> >> further stuff:
>>>>> >> blog: http://matthiaswessendorf.wordpress.com/
>>>>> >> sessions: http://www.slideshare.net/mwessendorf
>>>>> >> mail: matzew-at-apache-dot-org
>>>>> >
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matthias Wessendorf
>>>>>
>>>>> Need JSF and Web 2.0?
>>>>> http://code.google.com/p/facesgoodies
>>>>>
>>>>> further stuff:
>>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>>> sessions: http://www.slideshare.net/mwessendorf
>>>>> mail: matzew-at-apache-dot-org
>>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>> Hazem Ahmed Saleh Ahmed
>> http://www.jroller.com/page/HazemBlog
>>
>> [Web 2.0] GMaps Integration with JSF + Apache Tomahawk + JBoss a4j :
>> http://code.google.com/p/gmaps4jsf/
>>
>
>

Re: JSF2.0 implementation

[Simon Lessard <si...@gmail.com>]

Thank :) Although give me 10 minutes or so to fix something stupid I did
before doing a checkout.


Regards,

~ Simon

On Thu, Aug 28, 2008 at 7:16 PM, Hazem Saleh <ha...@apache.org> wrote:

> Thank you Simon. I will join this soon.
>
>
> On Thu, Aug 28, 2008 at 7:13 PM, Simon Lessard <si...@gmail.com>wrote:
>
>> Hi Bruno,
>>
>> So far my planing was:
>>
>> sequential
>> 1. Create all new API classes: done
>> 2. Add all new methods to the API, with empty TODO: JSF 2.0 comment in
>> their body when they aren't abstract: in progress and I already found some
>> strange stuff that I might raise on the EG group discussions as for why
>> Application.getResourceHandler isn't abstract while all other get handler
>> methods are: in progress
>>
>> *** At that point, IMPL will no longer compile ***
>>
>> 3. Add the missing signature in IMPL with empty TODO: JSF 2.0 comment in
>> their body
>>
>> *** Everything should compile but don't work at all ***
>>
>> parallel
>> 4. Modify the build plugin to include jsf 2.0 changes
>> 5. Implement the API changes
>> 6. Implement the IMPL changes
>> 7. Implement the JS library
>>
>> I would really like to use Facelets code when required, but we'll have to
>> make sure it's alright with legal discuss first I think, I'm not well versed
>> enough in this kind of very specific issues.
>>
>> It's a very high level roadmap, We should probably use much finer
>> granularity for point 5 to 7, but I'm not there yet.
>>
>>
>> Regards,
>>
>> ~ Simon
>>
>>
>> On Thu, Aug 28, 2008 at 11:30 AM, Bruno Aranda <br...@gmail.com>wrote:
>>
>>> I am willing (as always) to contribute as much as my time permits to the
>>> JSF 2.0 implementation. I tried to find in the list what is going to be the
>>> big picture, the roadmap to have a JSF 2.0 implementation. Do we have
>>> something like that? How are we going to integrate Facelets, for instance?
>>> (good that is now under ASL!). What part are you developing at the moment?
>>>
>>> Thanks!
>>>
>>> Bruno
>>>
>>> 2008/8/28 Matthias Wessendorf <ma...@apache.org>
>>>
>>> On Thu, Aug 28, 2008 at 4:50 PM, Simon Lessard
>>>> <si...@gmail.com> wrote:
>>>> >
>>>> >
>>>> > On Thu, Aug 28, 2008 at 10:35 AM, Matthias Wessendorf <
>>>> matzew@apache.org>
>>>> > wrote:
>>>> >>
>>>> >> On Thu, Aug 28, 2008 at 4:24 PM, Simon Lessard
>>>> >> <si...@gmail.com> wrote:
>>>> >> > Hi Simon,
>>>> >> >
>>>> >> >
>>>> >> > On Thu, Aug 28, 2008 at 2:56 AM, Simon Kitching <
>>>> skitching@apache.org>
>>>> >> > wrote:
>>>> >> >>
>>>> >> >> I see from the commit list that a new JSF2.0 branch has been
>>>> created.
>>>> >> >>
>>>> >> >> I don't remember seeing *any* kind of discussion or even
>>>> announcement
>>>> >> >> about this. While I am happy to see JSF2.0 work going on, this
>>>> kind of
>>>> >> >> approach does not seem to be at all in the "community" spirit.
>>>> IMO,
>>>> >> >> major
>>>> >> >> events like this should be discussed beforehand.
>>>> >> >
>>>> >> > As mentioned by other people, there was a vote about this a while
>>>> back .
>>>> >> > Why
>>>> >> > did I create it just now? Simply because my company agreed to
>>>> provide
>>>> >> > some
>>>> >> > resource to help with the implementation and we were ready to get
>>>> >> > started.
>>>> >>
>>>> >> One might ask here for a CCLA ;-)
>>>> >> We did that for Oracle way back, and update once in a while all the
>>>> >> contributors,
>>>> >> that have signed the iCLA.
>>>> >
>>>> > Yeah, but Fujistu signed a CCLA already when I became commiter, so
>>>> that's a
>>>> > non issue as well.
>>>>
>>>> good.
>>>>
>>>> >
>>>> >>
>>>> >> >
>>>> >> >>
>>>> >> >> One issue, for example, is that the core-1.2 stuff is currently
>>>> >> >> half-way-converted from the trinidad plugins to the
>>>> >> >> myfaces-builder-plugin.
>>>> >> >> So now it is branched, any changes need to be applied in two
>>>> places.
>>>> >> >
>>>> >> > To be honest, I find this irrelevant, it's a branch, not a trunk
>>>> and
>>>> >> > I'll
>>>> >> > most likely do some branch merging when core 1.2.x get release and
>>>> the
>>>> >> > plugin might have to change a little to support jsfVersion 2.0.
>>>> >> >
>>>> >> >>
>>>> >> >> In addition, a large amount of code has just been committed by
>>>> someone
>>>> >> >> (slessard) who is not a particularly regular contributor to
>>>> myfaces.
>>>> >> >
>>>> >> > I see even less relevance in that statement.
>>>> >> >
>>>> >> >>
>>>> >> >> Where did this code come from? Do we need a code grant for it?
>>>> Note
>>>> >> >> that
>>>> >> >> when code is developed iteratively on the dev list then there is
>>>> no
>>>> >> >> need for
>>>> >> >> a grant. But a sudden code dump is different, even when
>>>> contributed by
>>>> >> >> someone who has signed a CLA.
>>>> >> >
>>>> >> > The code was coded just yesterday by me and is not much at all,
>>>> creating
>>>> >> > missing classes for the JavaDoc change log is in no matter a large
>>>> >> > amount in
>>>> >> > term of complexity. Also since I was the only author of it (my
>>>> teammates
>>>> >> > will wait until I have added the signatures). There's absolutely no
>>>> need
>>>> >> > of
>>>> >> > code grant either.
>>>> >>
>>>> >> I agree on the code grant, b/c of it is really pretty trivial to
>>>> >> create those API classes/interfaces
>>>> >> (based on the javadoc log, as I said before).
>>>> >> @signatures: you mean the iCLA / CCLA, aren't you ?
>>>> >
>>>> > nah, I meant method signatures, it will be easier for my teammates to
>>>> know
>>>> > what they have to do once there's a nice // TODO: Convert to JSF 2.0
>>>> added
>>>> > in every new method's body.
>>>> >
>>>> > As far as I understand the legal issues (might have to fallback to
>>>> > legal@apache.org though), they won't need a CLA until they become
>>>> commiters.
>>>> > I don't know if I should have the company add their names to the CCLA
>>>>
>>>> no. wrong
>>>> cla == contributor license agreement.
>>>> I usually ask for that after one or two patches. Never been an issue at
>>>> all.
>>>> We (from ORA) add those contributors to our CCLA, and fax the update to
>>>> Sam Ruby (our ASF secretary).
>>>>
>>>> > however. Technically, we aren't bound contractualy by any intellectual
>>>> > property transfer with my employer and we're developping outside
>>>> normal
>>>> > business hours so we aren't directly paid either for it so I don't
>>>> know if
>>>> > adding their name to the CCLA is even needed or not.
>>>>
>>>> that means, what you develop on your sparetime is yours... NO CCLA
>>>> update
>>>> required. Cool
>>>>
>>>> -Matthias
>>>>
>>>> >
>>>> >
>>>> > ~ Simon
>>>> >
>>>> >>
>>>> >> >
>>>> >> >>
>>>> >> >> And with 3 branches to now maintain, we need to discuss whether
>>>> and
>>>> >> >> when
>>>> >> >> we phase out maintenance of the jsf-1.1 branch. Currently when
>>>> users
>>>> >> >> provide
>>>> >> >> patches in jira, they almost always provide a patch against only
>>>> one
>>>> >> >> version
>>>> >> >> and the committer ports it, which does increase the load on
>>>> existing
>>>> >> >> committers. When do we stop asking committers to do this when
>>>> patching
>>>> >> >> bugs?
>>>> >> >
>>>> >> > I can take care of the branch merging, this is how we handled the
>>>> >> > trinidad
>>>> >> > 1.2 branch at first, Adam would do the merging every now and then,
>>>> so
>>>> >> > I'm
>>>> >> > not asking the committers to do some extra work.
>>>> >>
>>>> >> yup. not a big deal. Also I doubt that that many folks will work
>>>> >> there, on the branch.
>>>> >> If the branch needs some merging... fine as well, IMO.
>>>> >>
>>>> >> >
>>>> >> >>
>>>> >> >> To repeat, I'm *happy* that jsf2.0 implementation is in progress,
>>>> and
>>>> >> >> appreciate people contributing time to write an ASF-2.0-licensed
>>>> >> >> implementation. But it is a  standard saying at Apache that
>>>> "community
>>>> >> >> is
>>>> >> >> more important than code", and the "community" aspect here seems
>>>> to
>>>> >> >> have
>>>> >> >> been rather neglected...
>>>> >> >
>>>> >> > I don't agree at all here. Although it wasn't announced on the dev
>>>> list,
>>>> >> > the
>>>> >> > JIRA ticket created to attach patches was speciafically for the
>>>> >> > community.
>>>> >>
>>>> >> and the branch creation was also discussed.
>>>> >>
>>>> >> > Code provided by Fujitsu employees will never go through me with
>>>> direct
>>>> >> > commit, it will all be added as patches, even extra tests and
>>>> >> > documentation
>>>> >> > as we want them and everyone else willing to help get the credit
>>>> for it.
>>>> >>
>>>> >> we do the same. Folks provide patches and jira tickets to describe
>>>> the
>>>> >> problem.
>>>> >>
>>>> >> > Furthermore, I personally didn't announce it because the branch
>>>> will be
>>>> >> > very
>>>> >> > instable for a week or two until we finish adding the missing
>>>> signatures
>>>> >> > (impl might not even always compile).
>>>> >>
>>>> >> dev@ is a developers community; so that would be fine :-)
>>>> >>
>>>> >> -Matthias
>>>> >>
>>>> >> > If community wasn't important in the process we would just have
>>>> used a
>>>> >> > private repository at Fujitsu, worked on it for some time with my
>>>> team,
>>>> >> > then
>>>> >> > commit some very large amount of code (real large) that would have
>>>> >> > needed a
>>>> >> > code grant, prevented the people to see at what rythm things were
>>>> >> > progressing and contributing. The only point I *could* give you
>>>> here is
>>>> >> > that
>>>> >> > maybe I should have annouced the creation directly on the dev list
>>>> and
>>>> >> > point
>>>> >> > on the JIRA ticket and SVN url rather than relying only on JIRA
>>>> ticket
>>>> >> > report that get forwarded on the dev list.
>>>> >> >
>>>> >> >
>>>> >> > Regards,
>>>> >> >
>>>> >> > ~ Simon
>>>> >> >
>>>> >> >>
>>>> >> >> Regards,
>>>> >> >> Simon
>>>> >> >>
>>>> >> >
>>>> >> >
>>>> >>
>>>> >>
>>>> >>
>>>> >> --
>>>> >> Matthias Wessendorf
>>>> >>
>>>> >> Need JSF and Web 2.0?
>>>> >> http://code.google.com/p/facesgoodies
>>>> >>
>>>> >> further stuff:
>>>> >> blog: http://matthiaswessendorf.wordpress.com/
>>>> >> sessions: http://www.slideshare.net/mwessendorf
>>>> >> mail: matzew-at-apache-dot-org
>>>> >
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> Matthias Wessendorf
>>>>
>>>> Need JSF and Web 2.0?
>>>> http://code.google.com/p/facesgoodies
>>>>
>>>> further stuff:
>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>> sessions: http://www.slideshare.net/mwessendorf
>>>> mail: matzew-at-apache-dot-org
>>>>
>>>
>>>
>>
>
>
> --
> Hazem Ahmed Saleh Ahmed
> http://www.jroller.com/page/HazemBlog
>
> [Web 2.0] GMaps Integration with JSF + Apache Tomahawk + JBoss a4j :
> http://code.google.com/p/gmaps4jsf/
>

Re: JSF2.0 implementation

[Hazem Saleh <ha...@apache.org>]

Thank you Simon. I will join this soon.

On Thu, Aug 28, 2008 at 7:13 PM, Simon Lessard <si...@gmail.com>wrote:

> Hi Bruno,
>
> So far my planing was:
>
> sequential
> 1. Create all new API classes: done
> 2. Add all new methods to the API, with empty TODO: JSF 2.0 comment in
> their body when they aren't abstract: in progress and I already found some
> strange stuff that I might raise on the EG group discussions as for why
> Application.getResourceHandler isn't abstract while all other get handler
> methods are: in progress
>
> *** At that point, IMPL will no longer compile ***
>
> 3. Add the missing signature in IMPL with empty TODO: JSF 2.0 comment in
> their body
>
> *** Everything should compile but don't work at all ***
>
> parallel
> 4. Modify the build plugin to include jsf 2.0 changes
> 5. Implement the API changes
> 6. Implement the IMPL changes
> 7. Implement the JS library
>
> I would really like to use Facelets code when required, but we'll have to
> make sure it's alright with legal discuss first I think, I'm not well versed
> enough in this kind of very specific issues.
>
> It's a very high level roadmap, We should probably use much finer
> granularity for point 5 to 7, but I'm not there yet.
>
>
> Regards,
>
> ~ Simon
>
>
> On Thu, Aug 28, 2008 at 11:30 AM, Bruno Aranda <br...@gmail.com>wrote:
>
>> I am willing (as always) to contribute as much as my time permits to the
>> JSF 2.0 implementation. I tried to find in the list what is going to be the
>> big picture, the roadmap to have a JSF 2.0 implementation. Do we have
>> something like that? How are we going to integrate Facelets, for instance?
>> (good that is now under ASL!). What part are you developing at the moment?
>>
>> Thanks!
>>
>> Bruno
>>
>> 2008/8/28 Matthias Wessendorf <ma...@apache.org>
>>
>> On Thu, Aug 28, 2008 at 4:50 PM, Simon Lessard
>>> <si...@gmail.com> wrote:
>>> >
>>> >
>>> > On Thu, Aug 28, 2008 at 10:35 AM, Matthias Wessendorf <
>>> matzew@apache.org>
>>> > wrote:
>>> >>
>>> >> On Thu, Aug 28, 2008 at 4:24 PM, Simon Lessard
>>> >> <si...@gmail.com> wrote:
>>> >> > Hi Simon,
>>> >> >
>>> >> >
>>> >> > On Thu, Aug 28, 2008 at 2:56 AM, Simon Kitching <
>>> skitching@apache.org>
>>> >> > wrote:
>>> >> >>
>>> >> >> I see from the commit list that a new JSF2.0 branch has been
>>> created.
>>> >> >>
>>> >> >> I don't remember seeing *any* kind of discussion or even
>>> announcement
>>> >> >> about this. While I am happy to see JSF2.0 work going on, this kind
>>> of
>>> >> >> approach does not seem to be at all in the "community" spirit. IMO,
>>> >> >> major
>>> >> >> events like this should be discussed beforehand.
>>> >> >
>>> >> > As mentioned by other people, there was a vote about this a while
>>> back .
>>> >> > Why
>>> >> > did I create it just now? Simply because my company agreed to
>>> provide
>>> >> > some
>>> >> > resource to help with the implementation and we were ready to get
>>> >> > started.
>>> >>
>>> >> One might ask here for a CCLA ;-)
>>> >> We did that for Oracle way back, and update once in a while all the
>>> >> contributors,
>>> >> that have signed the iCLA.
>>> >
>>> > Yeah, but Fujistu signed a CCLA already when I became commiter, so
>>> that's a
>>> > non issue as well.
>>>
>>> good.
>>>
>>> >
>>> >>
>>> >> >
>>> >> >>
>>> >> >> One issue, for example, is that the core-1.2 stuff is currently
>>> >> >> half-way-converted from the trinidad plugins to the
>>> >> >> myfaces-builder-plugin.
>>> >> >> So now it is branched, any changes need to be applied in two
>>> places.
>>> >> >
>>> >> > To be honest, I find this irrelevant, it's a branch, not a trunk and
>>> >> > I'll
>>> >> > most likely do some branch merging when core 1.2.x get release and
>>> the
>>> >> > plugin might have to change a little to support jsfVersion 2.0.
>>> >> >
>>> >> >>
>>> >> >> In addition, a large amount of code has just been committed by
>>> someone
>>> >> >> (slessard) who is not a particularly regular contributor to
>>> myfaces.
>>> >> >
>>> >> > I see even less relevance in that statement.
>>> >> >
>>> >> >>
>>> >> >> Where did this code come from? Do we need a code grant for it? Note
>>> >> >> that
>>> >> >> when code is developed iteratively on the dev list then there is no
>>> >> >> need for
>>> >> >> a grant. But a sudden code dump is different, even when contributed
>>> by
>>> >> >> someone who has signed a CLA.
>>> >> >
>>> >> > The code was coded just yesterday by me and is not much at all,
>>> creating
>>> >> > missing classes for the JavaDoc change log is in no matter a large
>>> >> > amount in
>>> >> > term of complexity. Also since I was the only author of it (my
>>> teammates
>>> >> > will wait until I have added the signatures). There's absolutely no
>>> need
>>> >> > of
>>> >> > code grant either.
>>> >>
>>> >> I agree on the code grant, b/c of it is really pretty trivial to
>>> >> create those API classes/interfaces
>>> >> (based on the javadoc log, as I said before).
>>> >> @signatures: you mean the iCLA / CCLA, aren't you ?
>>> >
>>> > nah, I meant method signatures, it will be easier for my teammates to
>>> know
>>> > what they have to do once there's a nice // TODO: Convert to JSF 2.0
>>> added
>>> > in every new method's body.
>>> >
>>> > As far as I understand the legal issues (might have to fallback to
>>> > legal@apache.org though), they won't need a CLA until they become
>>> commiters.
>>> > I don't know if I should have the company add their names to the CCLA
>>>
>>> no. wrong
>>> cla == contributor license agreement.
>>> I usually ask for that after one or two patches. Never been an issue at
>>> all.
>>> We (from ORA) add those contributors to our CCLA, and fax the update to
>>> Sam Ruby (our ASF secretary).
>>>
>>> > however. Technically, we aren't bound contractualy by any intellectual
>>> > property transfer with my employer and we're developping outside normal
>>> > business hours so we aren't directly paid either for it so I don't know
>>> if
>>> > adding their name to the CCLA is even needed or not.
>>>
>>> that means, what you develop on your sparetime is yours... NO CCLA update
>>> required. Cool
>>>
>>> -Matthias
>>>
>>> >
>>> >
>>> > ~ Simon
>>> >
>>> >>
>>> >> >
>>> >> >>
>>> >> >> And with 3 branches to now maintain, we need to discuss whether and
>>> >> >> when
>>> >> >> we phase out maintenance of the jsf-1.1 branch. Currently when
>>> users
>>> >> >> provide
>>> >> >> patches in jira, they almost always provide a patch against only
>>> one
>>> >> >> version
>>> >> >> and the committer ports it, which does increase the load on
>>> existing
>>> >> >> committers. When do we stop asking committers to do this when
>>> patching
>>> >> >> bugs?
>>> >> >
>>> >> > I can take care of the branch merging, this is how we handled the
>>> >> > trinidad
>>> >> > 1.2 branch at first, Adam would do the merging every now and then,
>>> so
>>> >> > I'm
>>> >> > not asking the committers to do some extra work.
>>> >>
>>> >> yup. not a big deal. Also I doubt that that many folks will work
>>> >> there, on the branch.
>>> >> If the branch needs some merging... fine as well, IMO.
>>> >>
>>> >> >
>>> >> >>
>>> >> >> To repeat, I'm *happy* that jsf2.0 implementation is in progress,
>>> and
>>> >> >> appreciate people contributing time to write an ASF-2.0-licensed
>>> >> >> implementation. But it is a  standard saying at Apache that
>>> "community
>>> >> >> is
>>> >> >> more important than code", and the "community" aspect here seems to
>>> >> >> have
>>> >> >> been rather neglected...
>>> >> >
>>> >> > I don't agree at all here. Although it wasn't announced on the dev
>>> list,
>>> >> > the
>>> >> > JIRA ticket created to attach patches was speciafically for the
>>> >> > community.
>>> >>
>>> >> and the branch creation was also discussed.
>>> >>
>>> >> > Code provided by Fujitsu employees will never go through me with
>>> direct
>>> >> > commit, it will all be added as patches, even extra tests and
>>> >> > documentation
>>> >> > as we want them and everyone else willing to help get the credit for
>>> it.
>>> >>
>>> >> we do the same. Folks provide patches and jira tickets to describe the
>>> >> problem.
>>> >>
>>> >> > Furthermore, I personally didn't announce it because the branch will
>>> be
>>> >> > very
>>> >> > instable for a week or two until we finish adding the missing
>>> signatures
>>> >> > (impl might not even always compile).
>>> >>
>>> >> dev@ is a developers community; so that would be fine :-)
>>> >>
>>> >> -Matthias
>>> >>
>>> >> > If community wasn't important in the process we would just have used
>>> a
>>> >> > private repository at Fujitsu, worked on it for some time with my
>>> team,
>>> >> > then
>>> >> > commit some very large amount of code (real large) that would have
>>> >> > needed a
>>> >> > code grant, prevented the people to see at what rythm things were
>>> >> > progressing and contributing. The only point I *could* give you here
>>> is
>>> >> > that
>>> >> > maybe I should have annouced the creation directly on the dev list
>>> and
>>> >> > point
>>> >> > on the JIRA ticket and SVN url rather than relying only on JIRA
>>> ticket
>>> >> > report that get forwarded on the dev list.
>>> >> >
>>> >> >
>>> >> > Regards,
>>> >> >
>>> >> > ~ Simon
>>> >> >
>>> >> >>
>>> >> >> Regards,
>>> >> >> Simon
>>> >> >>
>>> >> >
>>> >> >
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Matthias Wessendorf
>>> >>
>>> >> Need JSF and Web 2.0?
>>> >> http://code.google.com/p/facesgoodies
>>> >>
>>> >> further stuff:
>>> >> blog: http://matthiaswessendorf.wordpress.com/
>>> >> sessions: http://www.slideshare.net/mwessendorf
>>> >> mail: matzew-at-apache-dot-org
>>> >
>>> >
>>>
>>>
>>>
>>> --
>>> Matthias Wessendorf
>>>
>>> Need JSF and Web 2.0?
>>> http://code.google.com/p/facesgoodies
>>>
>>> further stuff:
>>> blog: http://matthiaswessendorf.wordpress.com/
>>> sessions: http://www.slideshare.net/mwessendorf
>>> mail: matzew-at-apache-dot-org
>>>
>>
>>
>


-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

[Web 2.0] GMaps Integration with JSF + Apache Tomahawk + JBoss a4j :
http://code.google.com/p/gmaps4jsf/

Re: JSF2.0 implementation

[Matthias Wessendorf <ma...@apache.org>]

On Fri, Aug 29, 2008 at 9:56 AM, Bruno Aranda <br...@gmail.com> wrote:
> Sounds like a plan to me :) When I am back from holidays I will have a look,

perhaps we could add a *simple* roadmap.txt in the branch ;-)

-M

>
> Thanks!
>
> Bruno
>
> 2008/8/28 Simon Lessard <si...@gmail.com>
>>
>> Hi Bruno,
>>
>> So far my planing was:
>>
>> sequential
>> 1. Create all new API classes: done
>> 2. Add all new methods to the API, with empty TODO: JSF 2.0 comment in
>> their body when they aren't abstract: in progress and I already found some
>> strange stuff that I might raise on the EG group discussions as for why
>> Application.getResourceHandler isn't abstract while all other get handler
>> methods are: in progress
>>
>> *** At that point, IMPL will no longer compile ***
>>
>> 3. Add the missing signature in IMPL with empty TODO: JSF 2.0 comment in
>> their body
>>
>> *** Everything should compile but don't work at all ***
>>
>> parallel
>> 4. Modify the build plugin to include jsf 2.0 changes
>> 5. Implement the API changes
>> 6. Implement the IMPL changes
>> 7. Implement the JS library
>>
>> I would really like to use Facelets code when required, but we'll have to
>> make sure it's alright with legal discuss first I think, I'm not well versed
>> enough in this kind of very specific issues.
>>
>> It's a very high level roadmap, We should probably use much finer
>> granularity for point 5 to 7, but I'm not there yet.
>>
>>
>> Regards,
>>
>> ~ Simon
>>
>> On Thu, Aug 28, 2008 at 11:30 AM, Bruno Aranda <br...@gmail.com>
>> wrote:
>>>
>>> I am willing (as always) to contribute as much as my time permits to the
>>> JSF 2.0 implementation. I tried to find in the list what is going to be the
>>> big picture, the roadmap to have a JSF 2.0 implementation. Do we have
>>> something like that? How are we going to integrate Facelets, for instance?
>>> (good that is now under ASL!). What part are you developing at the moment?
>>>
>>> Thanks!
>>>
>>> Bruno
>>>
>>> 2008/8/28 Matthias Wessendorf <ma...@apache.org>
>>>>
>>>> On Thu, Aug 28, 2008 at 4:50 PM, Simon Lessard
>>>> <si...@gmail.com> wrote:
>>>> >
>>>> >
>>>> > On Thu, Aug 28, 2008 at 10:35 AM, Matthias Wessendorf
>>>> > <ma...@apache.org>
>>>> > wrote:
>>>> >>
>>>> >> On Thu, Aug 28, 2008 at 4:24 PM, Simon Lessard
>>>> >> <si...@gmail.com> wrote:
>>>> >> > Hi Simon,
>>>> >> >
>>>> >> >
>>>> >> > On Thu, Aug 28, 2008 at 2:56 AM, Simon Kitching
>>>> >> > <sk...@apache.org>
>>>> >> > wrote:
>>>> >> >>
>>>> >> >> I see from the commit list that a new JSF2.0 branch has been
>>>> >> >> created.
>>>> >> >>
>>>> >> >> I don't remember seeing *any* kind of discussion or even
>>>> >> >> announcement
>>>> >> >> about this. While I am happy to see JSF2.0 work going on, this
>>>> >> >> kind of
>>>> >> >> approach does not seem to be at all in the "community" spirit.
>>>> >> >> IMO,
>>>> >> >> major
>>>> >> >> events like this should be discussed beforehand.
>>>> >> >
>>>> >> > As mentioned by other people, there was a vote about this a while
>>>> >> > back .
>>>> >> > Why
>>>> >> > did I create it just now? Simply because my company agreed to
>>>> >> > provide
>>>> >> > some
>>>> >> > resource to help with the implementation and we were ready to get
>>>> >> > started.
>>>> >>
>>>> >> One might ask here for a CCLA ;-)
>>>> >> We did that for Oracle way back, and update once in a while all the
>>>> >> contributors,
>>>> >> that have signed the iCLA.
>>>> >
>>>> > Yeah, but Fujistu signed a CCLA already when I became commiter, so
>>>> > that's a
>>>> > non issue as well.
>>>>
>>>> good.
>>>>
>>>> >
>>>> >>
>>>> >> >
>>>> >> >>
>>>> >> >> One issue, for example, is that the core-1.2 stuff is currently
>>>> >> >> half-way-converted from the trinidad plugins to the
>>>> >> >> myfaces-builder-plugin.
>>>> >> >> So now it is branched, any changes need to be applied in two
>>>> >> >> places.
>>>> >> >
>>>> >> > To be honest, I find this irrelevant, it's a branch, not a trunk
>>>> >> > and
>>>> >> > I'll
>>>> >> > most likely do some branch merging when core 1.2.x get release and
>>>> >> > the
>>>> >> > plugin might have to change a little to support jsfVersion 2.0.
>>>> >> >
>>>> >> >>
>>>> >> >> In addition, a large amount of code has just been committed by
>>>> >> >> someone
>>>> >> >> (slessard) who is not a particularly regular contributor to
>>>> >> >> myfaces.
>>>> >> >
>>>> >> > I see even less relevance in that statement.
>>>> >> >
>>>> >> >>
>>>> >> >> Where did this code come from? Do we need a code grant for it?
>>>> >> >> Note
>>>> >> >> that
>>>> >> >> when code is developed iteratively on the dev list then there is
>>>> >> >> no
>>>> >> >> need for
>>>> >> >> a grant. But a sudden code dump is different, even when
>>>> >> >> contributed by
>>>> >> >> someone who has signed a CLA.
>>>> >> >
>>>> >> > The code was coded just yesterday by me and is not much at all,
>>>> >> > creating
>>>> >> > missing classes for the JavaDoc change log is in no matter a large
>>>> >> > amount in
>>>> >> > term of complexity. Also since I was the only author of it (my
>>>> >> > teammates
>>>> >> > will wait until I have added the signatures). There's absolutely no
>>>> >> > need
>>>> >> > of
>>>> >> > code grant either.
>>>> >>
>>>> >> I agree on the code grant, b/c of it is really pretty trivial to
>>>> >> create those API classes/interfaces
>>>> >> (based on the javadoc log, as I said before).
>>>> >> @signatures: you mean the iCLA / CCLA, aren't you ?
>>>> >
>>>> > nah, I meant method signatures, it will be easier for my teammates to
>>>> > know
>>>> > what they have to do once there's a nice // TODO: Convert to JSF 2.0
>>>> > added
>>>> > in every new method's body.
>>>> >
>>>> > As far as I understand the legal issues (might have to fallback to
>>>> > legal@apache.org though), they won't need a CLA until they become
>>>> > commiters.
>>>> > I don't know if I should have the company add their names to the CCLA
>>>>
>>>> no. wrong
>>>> cla == contributor license agreement.
>>>> I usually ask for that after one or two patches. Never been an issue at
>>>> all.
>>>> We (from ORA) add those contributors to our CCLA, and fax the update to
>>>> Sam Ruby (our ASF secretary).
>>>>
>>>> > however. Technically, we aren't bound contractualy by any intellectual
>>>> > property transfer with my employer and we're developping outside
>>>> > normal
>>>> > business hours so we aren't directly paid either for it so I don't
>>>> > know if
>>>> > adding their name to the CCLA is even needed or not.
>>>>
>>>> that means, what you develop on your sparetime is yours... NO CCLA
>>>> update
>>>> required. Cool
>>>>
>>>> -Matthias
>>>>
>>>> >
>>>> >
>>>> > ~ Simon
>>>> >
>>>> >>
>>>> >> >
>>>> >> >>
>>>> >> >> And with 3 branches to now maintain, we need to discuss whether
>>>> >> >> and
>>>> >> >> when
>>>> >> >> we phase out maintenance of the jsf-1.1 branch. Currently when
>>>> >> >> users
>>>> >> >> provide
>>>> >> >> patches in jira, they almost always provide a patch against only
>>>> >> >> one
>>>> >> >> version
>>>> >> >> and the committer ports it, which does increase the load on
>>>> >> >> existing
>>>> >> >> committers. When do we stop asking committers to do this when
>>>> >> >> patching
>>>> >> >> bugs?
>>>> >> >
>>>> >> > I can take care of the branch merging, this is how we handled the
>>>> >> > trinidad
>>>> >> > 1.2 branch at first, Adam would do the merging every now and then,
>>>> >> > so
>>>> >> > I'm
>>>> >> > not asking the committers to do some extra work.
>>>> >>
>>>> >> yup. not a big deal. Also I doubt that that many folks will work
>>>> >> there, on the branch.
>>>> >> If the branch needs some merging... fine as well, IMO.
>>>> >>
>>>> >> >
>>>> >> >>
>>>> >> >> To repeat, I'm *happy* that jsf2.0 implementation is in progress,
>>>> >> >> and
>>>> >> >> appreciate people contributing time to write an ASF-2.0-licensed
>>>> >> >> implementation. But it is a  standard saying at Apache that
>>>> >> >> "community
>>>> >> >> is
>>>> >> >> more important than code", and the "community" aspect here seems
>>>> >> >> to
>>>> >> >> have
>>>> >> >> been rather neglected...
>>>> >> >
>>>> >> > I don't agree at all here. Although it wasn't announced on the dev
>>>> >> > list,
>>>> >> > the
>>>> >> > JIRA ticket created to attach patches was speciafically for the
>>>> >> > community.
>>>> >>
>>>> >> and the branch creation was also discussed.
>>>> >>
>>>> >> > Code provided by Fujitsu employees will never go through me with
>>>> >> > direct
>>>> >> > commit, it will all be added as patches, even extra tests and
>>>> >> > documentation
>>>> >> > as we want them and everyone else willing to help get the credit
>>>> >> > for it.
>>>> >>
>>>> >> we do the same. Folks provide patches and jira tickets to describe
>>>> >> the
>>>> >> problem.
>>>> >>
>>>> >> > Furthermore, I personally didn't announce it because the branch
>>>> >> > will be
>>>> >> > very
>>>> >> > instable for a week or two until we finish adding the missing
>>>> >> > signatures
>>>> >> > (impl might not even always compile).
>>>> >>
>>>> >> dev@ is a developers community; so that would be fine :-)
>>>> >>
>>>> >> -Matthias
>>>> >>
>>>> >> > If community wasn't important in the process we would just have
>>>> >> > used a
>>>> >> > private repository at Fujitsu, worked on it for some time with my
>>>> >> > team,
>>>> >> > then
>>>> >> > commit some very large amount of code (real large) that would have
>>>> >> > needed a
>>>> >> > code grant, prevented the people to see at what rythm things were
>>>> >> > progressing and contributing. The only point I *could* give you
>>>> >> > here is
>>>> >> > that
>>>> >> > maybe I should have annouced the creation directly on the dev list
>>>> >> > and
>>>> >> > point
>>>> >> > on the JIRA ticket and SVN url rather than relying only on JIRA
>>>> >> > ticket
>>>> >> > report that get forwarded on the dev list.
>>>> >> >
>>>> >> >
>>>> >> > Regards,
>>>> >> >
>>>> >> > ~ Simon
>>>> >> >
>>>> >> >>
>>>> >> >> Regards,
>>>> >> >> Simon
>>>> >> >>
>>>> >> >
>>>> >> >
>>>> >>
>>>> >>
>>>> >>
>>>> >> --
>>>> >> Matthias Wessendorf
>>>> >>
>>>> >> Need JSF and Web 2.0?
>>>> >> http://code.google.com/p/facesgoodies
>>>> >>
>>>> >> further stuff:
>>>> >> blog: http://matthiaswessendorf.wordpress.com/
>>>> >> sessions: http://www.slideshare.net/mwessendorf
>>>> >> mail: matzew-at-apache-dot-org
>>>> >
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> Matthias Wessendorf
>>>>
>>>> Need JSF and Web 2.0?
>>>> http://code.google.com/p/facesgoodies
>>>>
>>>> further stuff:
>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>> sessions: http://www.slideshare.net/mwessendorf
>>>> mail: matzew-at-apache-dot-org
>>>
>>
>
>



-- 
Matthias Wessendorf

Need JSF and Web 2.0?
http://code.google.com/p/facesgoodies

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

Re: JSF2.0 implementation

[Bruno Aranda <br...@gmail.com>]

Sounds like a plan to me :) When I am back from holidays I will have a look,

Thanks!

Bruno

2008/8/28 Simon Lessard <si...@gmail.com>

> Hi Bruno,
>
> So far my planing was:
>
> sequential
> 1. Create all new API classes: done
> 2. Add all new methods to the API, with empty TODO: JSF 2.0 comment in
> their body when they aren't abstract: in progress and I already found some
> strange stuff that I might raise on the EG group discussions as for why
> Application.getResourceHandler isn't abstract while all other get handler
> methods are: in progress
>
> *** At that point, IMPL will no longer compile ***
>
> 3. Add the missing signature in IMPL with empty TODO: JSF 2.0 comment in
> their body
>
> *** Everything should compile but don't work at all ***
>
> parallel
> 4. Modify the build plugin to include jsf 2.0 changes
> 5. Implement the API changes
> 6. Implement the IMPL changes
> 7. Implement the JS library
>
> I would really like to use Facelets code when required, but we'll have to
> make sure it's alright with legal discuss first I think, I'm not well versed
> enough in this kind of very specific issues.
>
> It's a very high level roadmap, We should probably use much finer
> granularity for point 5 to 7, but I'm not there yet.
>
>
> Regards,
>
> ~ Simon
>
>
> On Thu, Aug 28, 2008 at 11:30 AM, Bruno Aranda <br...@gmail.com>wrote:
>
>> I am willing (as always) to contribute as much as my time permits to the
>> JSF 2.0 implementation. I tried to find in the list what is going to be the
>> big picture, the roadmap to have a JSF 2.0 implementation. Do we have
>> something like that? How are we going to integrate Facelets, for instance?
>> (good that is now under ASL!). What part are you developing at the moment?
>>
>> Thanks!
>>
>> Bruno
>>
>> 2008/8/28 Matthias Wessendorf <ma...@apache.org>
>>
>> On Thu, Aug 28, 2008 at 4:50 PM, Simon Lessard
>>> <si...@gmail.com> wrote:
>>> >
>>> >
>>> > On Thu, Aug 28, 2008 at 10:35 AM, Matthias Wessendorf <
>>> matzew@apache.org>
>>> > wrote:
>>> >>
>>> >> On Thu, Aug 28, 2008 at 4:24 PM, Simon Lessard
>>> >> <si...@gmail.com> wrote:
>>> >> > Hi Simon,
>>> >> >
>>> >> >
>>> >> > On Thu, Aug 28, 2008 at 2:56 AM, Simon Kitching <
>>> skitching@apache.org>
>>> >> > wrote:
>>> >> >>
>>> >> >> I see from the commit list that a new JSF2.0 branch has been
>>> created.
>>> >> >>
>>> >> >> I don't remember seeing *any* kind of discussion or even
>>> announcement
>>> >> >> about this. While I am happy to see JSF2.0 work going on, this kind
>>> of
>>> >> >> approach does not seem to be at all in the "community" spirit. IMO,
>>> >> >> major
>>> >> >> events like this should be discussed beforehand.
>>> >> >
>>> >> > As mentioned by other people, there was a vote about this a while
>>> back .
>>> >> > Why
>>> >> > did I create it just now? Simply because my company agreed to
>>> provide
>>> >> > some
>>> >> > resource to help with the implementation and we were ready to get
>>> >> > started.
>>> >>
>>> >> One might ask here for a CCLA ;-)
>>> >> We did that for Oracle way back, and update once in a while all the
>>> >> contributors,
>>> >> that have signed the iCLA.
>>> >
>>> > Yeah, but Fujistu signed a CCLA already when I became commiter, so
>>> that's a
>>> > non issue as well.
>>>
>>> good.
>>>
>>> >
>>> >>
>>> >> >
>>> >> >>
>>> >> >> One issue, for example, is that the core-1.2 stuff is currently
>>> >> >> half-way-converted from the trinidad plugins to the
>>> >> >> myfaces-builder-plugin.
>>> >> >> So now it is branched, any changes need to be applied in two
>>> places.
>>> >> >
>>> >> > To be honest, I find this irrelevant, it's a branch, not a trunk and
>>> >> > I'll
>>> >> > most likely do some branch merging when core 1.2.x get release and
>>> the
>>> >> > plugin might have to change a little to support jsfVersion 2.0.
>>> >> >
>>> >> >>
>>> >> >> In addition, a large amount of code has just been committed by
>>> someone
>>> >> >> (slessard) who is not a particularly regular contributor to
>>> myfaces.
>>> >> >
>>> >> > I see even less relevance in that statement.
>>> >> >
>>> >> >>
>>> >> >> Where did this code come from? Do we need a code grant for it? Note
>>> >> >> that
>>> >> >> when code is developed iteratively on the dev list then there is no
>>> >> >> need for
>>> >> >> a grant. But a sudden code dump is different, even when contributed
>>> by
>>> >> >> someone who has signed a CLA.
>>> >> >
>>> >> > The code was coded just yesterday by me and is not much at all,
>>> creating
>>> >> > missing classes for the JavaDoc change log is in no matter a large
>>> >> > amount in
>>> >> > term of complexity. Also since I was the only author of it (my
>>> teammates
>>> >> > will wait until I have added the signatures). There's absolutely no
>>> need
>>> >> > of
>>> >> > code grant either.
>>> >>
>>> >> I agree on the code grant, b/c of it is really pretty trivial to
>>> >> create those API classes/interfaces
>>> >> (based on the javadoc log, as I said before).
>>> >> @signatures: you mean the iCLA / CCLA, aren't you ?
>>> >
>>> > nah, I meant method signatures, it will be easier for my teammates to
>>> know
>>> > what they have to do once there's a nice // TODO: Convert to JSF 2.0
>>> added
>>> > in every new method's body.
>>> >
>>> > As far as I understand the legal issues (might have to fallback to
>>> > legal@apache.org though), they won't need a CLA until they become
>>> commiters.
>>> > I don't know if I should have the company add their names to the CCLA
>>>
>>> no. wrong
>>> cla == contributor license agreement.
>>> I usually ask for that after one or two patches. Never been an issue at
>>> all.
>>> We (from ORA) add those contributors to our CCLA, and fax the update to
>>> Sam Ruby (our ASF secretary).
>>>
>>> > however. Technically, we aren't bound contractualy by any intellectual
>>> > property transfer with my employer and we're developping outside normal
>>> > business hours so we aren't directly paid either for it so I don't know
>>> if
>>> > adding their name to the CCLA is even needed or not.
>>>
>>> that means, what you develop on your sparetime is yours... NO CCLA update
>>> required. Cool
>>>
>>> -Matthias
>>>
>>> >
>>> >
>>> > ~ Simon
>>> >
>>> >>
>>> >> >
>>> >> >>
>>> >> >> And with 3 branches to now maintain, we need to discuss whether and
>>> >> >> when
>>> >> >> we phase out maintenance of the jsf-1.1 branch. Currently when
>>> users
>>> >> >> provide
>>> >> >> patches in jira, they almost always provide a patch against only
>>> one
>>> >> >> version
>>> >> >> and the committer ports it, which does increase the load on
>>> existing
>>> >> >> committers. When do we stop asking committers to do this when
>>> patching
>>> >> >> bugs?
>>> >> >
>>> >> > I can take care of the branch merging, this is how we handled the
>>> >> > trinidad
>>> >> > 1.2 branch at first, Adam would do the merging every now and then,
>>> so
>>> >> > I'm
>>> >> > not asking the committers to do some extra work.
>>> >>
>>> >> yup. not a big deal. Also I doubt that that many folks will work
>>> >> there, on the branch.
>>> >> If the branch needs some merging... fine as well, IMO.
>>> >>
>>> >> >
>>> >> >>
>>> >> >> To repeat, I'm *happy* that jsf2.0 implementation is in progress,
>>> and
>>> >> >> appreciate people contributing time to write an ASF-2.0-licensed
>>> >> >> implementation. But it is a  standard saying at Apache that
>>> "community
>>> >> >> is
>>> >> >> more important than code", and the "community" aspect here seems to
>>> >> >> have
>>> >> >> been rather neglected...
>>> >> >
>>> >> > I don't agree at all here. Although it wasn't announced on the dev
>>> list,
>>> >> > the
>>> >> > JIRA ticket created to attach patches was speciafically for the
>>> >> > community.
>>> >>
>>> >> and the branch creation was also discussed.
>>> >>
>>> >> > Code provided by Fujitsu employees will never go through me with
>>> direct
>>> >> > commit, it will all be added as patches, even extra tests and
>>> >> > documentation
>>> >> > as we want them and everyone else willing to help get the credit for
>>> it.
>>> >>
>>> >> we do the same. Folks provide patches and jira tickets to describe the
>>> >> problem.
>>> >>
>>> >> > Furthermore, I personally didn't announce it because the branch will
>>> be
>>> >> > very
>>> >> > instable for a week or two until we finish adding the missing
>>> signatures
>>> >> > (impl might not even always compile).
>>> >>
>>> >> dev@ is a developers community; so that would be fine :-)
>>> >>
>>> >> -Matthias
>>> >>
>>> >> > If community wasn't important in the process we would just have used
>>> a
>>> >> > private repository at Fujitsu, worked on it for some time with my
>>> team,
>>> >> > then
>>> >> > commit some very large amount of code (real large) that would have
>>> >> > needed a
>>> >> > code grant, prevented the people to see at what rythm things were
>>> >> > progressing and contributing. The only point I *could* give you here
>>> is
>>> >> > that
>>> >> > maybe I should have annouced the creation directly on the dev list
>>> and
>>> >> > point
>>> >> > on the JIRA ticket and SVN url rather than relying only on JIRA
>>> ticket
>>> >> > report that get forwarded on the dev list.
>>> >> >
>>> >> >
>>> >> > Regards,
>>> >> >
>>> >> > ~ Simon
>>> >> >
>>> >> >>
>>> >> >> Regards,
>>> >> >> Simon
>>> >> >>
>>> >> >
>>> >> >
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Matthias Wessendorf
>>> >>
>>> >> Need JSF and Web 2.0?
>>> >> http://code.google.com/p/facesgoodies
>>> >>
>>> >> further stuff:
>>> >> blog: http://matthiaswessendorf.wordpress.com/
>>> >> sessions: http://www.slideshare.net/mwessendorf
>>> >> mail: matzew-at-apache-dot-org
>>> >
>>> >
>>>
>>>
>>>
>>> --
>>> Matthias Wessendorf
>>>
>>> Need JSF and Web 2.0?
>>> http://code.google.com/p/facesgoodies
>>>
>>> further stuff:
>>> blog: http://matthiaswessendorf.wordpress.com/
>>> sessions: http://www.slideshare.net/mwessendorf
>>> mail: matzew-at-apache-dot-org
>>>
>>
>>
>

Re: JSF2.0 implementation

[Simon Lessard <si...@gmail.com>]

Hi Bruno,

So far my planing was:

sequential
1. Create all new API classes: done
2. Add all new methods to the API, with empty TODO: JSF 2.0 comment in their
body when they aren't abstract: in progress and I already found some strange
stuff that I might raise on the EG group discussions as for why
Application.getResourceHandler isn't abstract while all other get handler
methods are: in progress

*** At that point, IMPL will no longer compile ***

3. Add the missing signature in IMPL with empty TODO: JSF 2.0 comment in
their body

*** Everything should compile but don't work at all ***

parallel
4. Modify the build plugin to include jsf 2.0 changes
5. Implement the API changes
6. Implement the IMPL changes
7. Implement the JS library

I would really like to use Facelets code when required, but we'll have to
make sure it's alright with legal discuss first I think, I'm not well versed
enough in this kind of very specific issues.

It's a very high level roadmap, We should probably use much finer
granularity for point 5 to 7, but I'm not there yet.


Regards,

~ Simon

On Thu, Aug 28, 2008 at 11:30 AM, Bruno Aranda <br...@gmail.com>wrote:

> I am willing (as always) to contribute as much as my time permits to the
> JSF 2.0 implementation. I tried to find in the list what is going to be the
> big picture, the roadmap to have a JSF 2.0 implementation. Do we have
> something like that? How are we going to integrate Facelets, for instance?
> (good that is now under ASL!). What part are you developing at the moment?
>
> Thanks!
>
> Bruno
>
> 2008/8/28 Matthias Wessendorf <ma...@apache.org>
>
> On Thu, Aug 28, 2008 at 4:50 PM, Simon Lessard
>> <si...@gmail.com> wrote:
>> >
>> >
>> > On Thu, Aug 28, 2008 at 10:35 AM, Matthias Wessendorf <
>> matzew@apache.org>
>> > wrote:
>> >>
>> >> On Thu, Aug 28, 2008 at 4:24 PM, Simon Lessard
>> >> <si...@gmail.com> wrote:
>> >> > Hi Simon,
>> >> >
>> >> >
>> >> > On Thu, Aug 28, 2008 at 2:56 AM, Simon Kitching <
>> skitching@apache.org>
>> >> > wrote:
>> >> >>
>> >> >> I see from the commit list that a new JSF2.0 branch has been
>> created.
>> >> >>
>> >> >> I don't remember seeing *any* kind of discussion or even
>> announcement
>> >> >> about this. While I am happy to see JSF2.0 work going on, this kind
>> of
>> >> >> approach does not seem to be at all in the "community" spirit. IMO,
>> >> >> major
>> >> >> events like this should be discussed beforehand.
>> >> >
>> >> > As mentioned by other people, there was a vote about this a while
>> back .
>> >> > Why
>> >> > did I create it just now? Simply because my company agreed to provide
>> >> > some
>> >> > resource to help with the implementation and we were ready to get
>> >> > started.
>> >>
>> >> One might ask here for a CCLA ;-)
>> >> We did that for Oracle way back, and update once in a while all the
>> >> contributors,
>> >> that have signed the iCLA.
>> >
>> > Yeah, but Fujistu signed a CCLA already when I became commiter, so
>> that's a
>> > non issue as well.
>>
>> good.
>>
>> >
>> >>
>> >> >
>> >> >>
>> >> >> One issue, for example, is that the core-1.2 stuff is currently
>> >> >> half-way-converted from the trinidad plugins to the
>> >> >> myfaces-builder-plugin.
>> >> >> So now it is branched, any changes need to be applied in two places.
>> >> >
>> >> > To be honest, I find this irrelevant, it's a branch, not a trunk and
>> >> > I'll
>> >> > most likely do some branch merging when core 1.2.x get release and
>> the
>> >> > plugin might have to change a little to support jsfVersion 2.0.
>> >> >
>> >> >>
>> >> >> In addition, a large amount of code has just been committed by
>> someone
>> >> >> (slessard) who is not a particularly regular contributor to myfaces.
>> >> >
>> >> > I see even less relevance in that statement.
>> >> >
>> >> >>
>> >> >> Where did this code come from? Do we need a code grant for it? Note
>> >> >> that
>> >> >> when code is developed iteratively on the dev list then there is no
>> >> >> need for
>> >> >> a grant. But a sudden code dump is different, even when contributed
>> by
>> >> >> someone who has signed a CLA.
>> >> >
>> >> > The code was coded just yesterday by me and is not much at all,
>> creating
>> >> > missing classes for the JavaDoc change log is in no matter a large
>> >> > amount in
>> >> > term of complexity. Also since I was the only author of it (my
>> teammates
>> >> > will wait until I have added the signatures). There's absolutely no
>> need
>> >> > of
>> >> > code grant either.
>> >>
>> >> I agree on the code grant, b/c of it is really pretty trivial to
>> >> create those API classes/interfaces
>> >> (based on the javadoc log, as I said before).
>> >> @signatures: you mean the iCLA / CCLA, aren't you ?
>> >
>> > nah, I meant method signatures, it will be easier for my teammates to
>> know
>> > what they have to do once there's a nice // TODO: Convert to JSF 2.0
>> added
>> > in every new method's body.
>> >
>> > As far as I understand the legal issues (might have to fallback to
>> > legal@apache.org though), they won't need a CLA until they become
>> commiters.
>> > I don't know if I should have the company add their names to the CCLA
>>
>> no. wrong
>> cla == contributor license agreement.
>> I usually ask for that after one or two patches. Never been an issue at
>> all.
>> We (from ORA) add those contributors to our CCLA, and fax the update to
>> Sam Ruby (our ASF secretary).
>>
>> > however. Technically, we aren't bound contractualy by any intellectual
>> > property transfer with my employer and we're developping outside normal
>> > business hours so we aren't directly paid either for it so I don't know
>> if
>> > adding their name to the CCLA is even needed or not.
>>
>> that means, what you develop on your sparetime is yours... NO CCLA update
>> required. Cool
>>
>> -Matthias
>>
>> >
>> >
>> > ~ Simon
>> >
>> >>
>> >> >
>> >> >>
>> >> >> And with 3 branches to now maintain, we need to discuss whether and
>> >> >> when
>> >> >> we phase out maintenance of the jsf-1.1 branch. Currently when users
>> >> >> provide
>> >> >> patches in jira, they almost always provide a patch against only one
>> >> >> version
>> >> >> and the committer ports it, which does increase the load on existing
>> >> >> committers. When do we stop asking committers to do this when
>> patching
>> >> >> bugs?
>> >> >
>> >> > I can take care of the branch merging, this is how we handled the
>> >> > trinidad
>> >> > 1.2 branch at first, Adam would do the merging every now and then, so
>> >> > I'm
>> >> > not asking the committers to do some extra work.
>> >>
>> >> yup. not a big deal. Also I doubt that that many folks will work
>> >> there, on the branch.
>> >> If the branch needs some merging... fine as well, IMO.
>> >>
>> >> >
>> >> >>
>> >> >> To repeat, I'm *happy* that jsf2.0 implementation is in progress,
>> and
>> >> >> appreciate people contributing time to write an ASF-2.0-licensed
>> >> >> implementation. But it is a  standard saying at Apache that
>> "community
>> >> >> is
>> >> >> more important than code", and the "community" aspect here seems to
>> >> >> have
>> >> >> been rather neglected...
>> >> >
>> >> > I don't agree at all here. Although it wasn't announced on the dev
>> list,
>> >> > the
>> >> > JIRA ticket created to attach patches was speciafically for the
>> >> > community.
>> >>
>> >> and the branch creation was also discussed.
>> >>
>> >> > Code provided by Fujitsu employees will never go through me with
>> direct
>> >> > commit, it will all be added as patches, even extra tests and
>> >> > documentation
>> >> > as we want them and everyone else willing to help get the credit for
>> it.
>> >>
>> >> we do the same. Folks provide patches and jira tickets to describe the
>> >> problem.
>> >>
>> >> > Furthermore, I personally didn't announce it because the branch will
>> be
>> >> > very
>> >> > instable for a week or two until we finish adding the missing
>> signatures
>> >> > (impl might not even always compile).
>> >>
>> >> dev@ is a developers community; so that would be fine :-)
>> >>
>> >> -Matthias
>> >>
>> >> > If community wasn't important in the process we would just have used
>> a
>> >> > private repository at Fujitsu, worked on it for some time with my
>> team,
>> >> > then
>> >> > commit some very large amount of code (real large) that would have
>> >> > needed a
>> >> > code grant, prevented the people to see at what rythm things were
>> >> > progressing and contributing. The only point I *could* give you here
>> is
>> >> > that
>> >> > maybe I should have annouced the creation directly on the dev list
>> and
>> >> > point
>> >> > on the JIRA ticket and SVN url rather than relying only on JIRA
>> ticket
>> >> > report that get forwarded on the dev list.
>> >> >
>> >> >
>> >> > Regards,
>> >> >
>> >> > ~ Simon
>> >> >
>> >> >>
>> >> >> Regards,
>> >> >> Simon
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Matthias Wessendorf
>> >>
>> >> Need JSF and Web 2.0?
>> >> http://code.google.com/p/facesgoodies
>> >>
>> >> further stuff:
>> >> blog: http://matthiaswessendorf.wordpress.com/
>> >> sessions: http://www.slideshare.net/mwessendorf
>> >> mail: matzew-at-apache-dot-org
>> >
>> >
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> Need JSF and Web 2.0?
>> http://code.google.com/p/facesgoodies
>>
>> further stuff:
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> mail: matzew-at-apache-dot-org
>>
>
>

Re: JSF2.0 implementation

[Matthias Wessendorf <ma...@apache.org>]

On Thu, Aug 28, 2008 at 5:30 PM, Bruno Aranda <br...@gmail.com> wrote:
> I am willing (as always) to contribute as much as my time permits to the JSF
> 2.0 implementation. I tried to find in the list what is going to be the big
> picture, the roadmap to have a JSF 2.0 implementation. Do we have something

no. I was beaten by Simon. My plan was to add those interfaces/APIs, that are
already know.

> like that? How are we going to integrate Facelets, for instance? (good that
> is now under ASL!). What part are you developing at the moment?

The RI folks checked it into their repos, AFAIK.
I bet to work under CDDL ;-)

These parts are not (yet) public, I think. Not sure...

-Matthias

>
> Thanks!
>
> Bruno
>
> 2008/8/28 Matthias Wessendorf <ma...@apache.org>
>>
>> On Thu, Aug 28, 2008 at 4:50 PM, Simon Lessard
>> <si...@gmail.com> wrote:
>> >
>> >
>> > On Thu, Aug 28, 2008 at 10:35 AM, Matthias Wessendorf
>> > <ma...@apache.org>
>> > wrote:
>> >>
>> >> On Thu, Aug 28, 2008 at 4:24 PM, Simon Lessard
>> >> <si...@gmail.com> wrote:
>> >> > Hi Simon,
>> >> >
>> >> >
>> >> > On Thu, Aug 28, 2008 at 2:56 AM, Simon Kitching
>> >> > <sk...@apache.org>
>> >> > wrote:
>> >> >>
>> >> >> I see from the commit list that a new JSF2.0 branch has been
>> >> >> created.
>> >> >>
>> >> >> I don't remember seeing *any* kind of discussion or even
>> >> >> announcement
>> >> >> about this. While I am happy to see JSF2.0 work going on, this kind
>> >> >> of
>> >> >> approach does not seem to be at all in the "community" spirit. IMO,
>> >> >> major
>> >> >> events like this should be discussed beforehand.
>> >> >
>> >> > As mentioned by other people, there was a vote about this a while
>> >> > back .
>> >> > Why
>> >> > did I create it just now? Simply because my company agreed to provide
>> >> > some
>> >> > resource to help with the implementation and we were ready to get
>> >> > started.
>> >>
>> >> One might ask here for a CCLA ;-)
>> >> We did that for Oracle way back, and update once in a while all the
>> >> contributors,
>> >> that have signed the iCLA.
>> >
>> > Yeah, but Fujistu signed a CCLA already when I became commiter, so
>> > that's a
>> > non issue as well.
>>
>> good.
>>
>> >
>> >>
>> >> >
>> >> >>
>> >> >> One issue, for example, is that the core-1.2 stuff is currently
>> >> >> half-way-converted from the trinidad plugins to the
>> >> >> myfaces-builder-plugin.
>> >> >> So now it is branched, any changes need to be applied in two places.
>> >> >
>> >> > To be honest, I find this irrelevant, it's a branch, not a trunk and
>> >> > I'll
>> >> > most likely do some branch merging when core 1.2.x get release and
>> >> > the
>> >> > plugin might have to change a little to support jsfVersion 2.0.
>> >> >
>> >> >>
>> >> >> In addition, a large amount of code has just been committed by
>> >> >> someone
>> >> >> (slessard) who is not a particularly regular contributor to myfaces.
>> >> >
>> >> > I see even less relevance in that statement.
>> >> >
>> >> >>
>> >> >> Where did this code come from? Do we need a code grant for it? Note
>> >> >> that
>> >> >> when code is developed iteratively on the dev list then there is no
>> >> >> need for
>> >> >> a grant. But a sudden code dump is different, even when contributed
>> >> >> by
>> >> >> someone who has signed a CLA.
>> >> >
>> >> > The code was coded just yesterday by me and is not much at all,
>> >> > creating
>> >> > missing classes for the JavaDoc change log is in no matter a large
>> >> > amount in
>> >> > term of complexity. Also since I was the only author of it (my
>> >> > teammates
>> >> > will wait until I have added the signatures). There's absolutely no
>> >> > need
>> >> > of
>> >> > code grant either.
>> >>
>> >> I agree on the code grant, b/c of it is really pretty trivial to
>> >> create those API classes/interfaces
>> >> (based on the javadoc log, as I said before).
>> >> @signatures: you mean the iCLA / CCLA, aren't you ?
>> >
>> > nah, I meant method signatures, it will be easier for my teammates to
>> > know
>> > what they have to do once there's a nice // TODO: Convert to JSF 2.0
>> > added
>> > in every new method's body.
>> >
>> > As far as I understand the legal issues (might have to fallback to
>> > legal@apache.org though), they won't need a CLA until they become
>> > commiters.
>> > I don't know if I should have the company add their names to the CCLA
>>
>> no. wrong
>> cla == contributor license agreement.
>> I usually ask for that after one or two patches. Never been an issue at
>> all.
>> We (from ORA) add those contributors to our CCLA, and fax the update to
>> Sam Ruby (our ASF secretary).
>>
>> > however. Technically, we aren't bound contractualy by any intellectual
>> > property transfer with my employer and we're developping outside normal
>> > business hours so we aren't directly paid either for it so I don't know
>> > if
>> > adding their name to the CCLA is even needed or not.
>>
>> that means, what you develop on your sparetime is yours... NO CCLA update
>> required. Cool
>>
>> -Matthias
>>
>> >
>> >
>> > ~ Simon
>> >
>> >>
>> >> >
>> >> >>
>> >> >> And with 3 branches to now maintain, we need to discuss whether and
>> >> >> when
>> >> >> we phase out maintenance of the jsf-1.1 branch. Currently when users
>> >> >> provide
>> >> >> patches in jira, they almost always provide a patch against only one
>> >> >> version
>> >> >> and the committer ports it, which does increase the load on existing
>> >> >> committers. When do we stop asking committers to do this when
>> >> >> patching
>> >> >> bugs?
>> >> >
>> >> > I can take care of the branch merging, this is how we handled the
>> >> > trinidad
>> >> > 1.2 branch at first, Adam would do the merging every now and then, so
>> >> > I'm
>> >> > not asking the committers to do some extra work.
>> >>
>> >> yup. not a big deal. Also I doubt that that many folks will work
>> >> there, on the branch.
>> >> If the branch needs some merging... fine as well, IMO.
>> >>
>> >> >
>> >> >>
>> >> >> To repeat, I'm *happy* that jsf2.0 implementation is in progress,
>> >> >> and
>> >> >> appreciate people contributing time to write an ASF-2.0-licensed
>> >> >> implementation. But it is a  standard saying at Apache that
>> >> >> "community
>> >> >> is
>> >> >> more important than code", and the "community" aspect here seems to
>> >> >> have
>> >> >> been rather neglected...
>> >> >
>> >> > I don't agree at all here. Although it wasn't announced on the dev
>> >> > list,
>> >> > the
>> >> > JIRA ticket created to attach patches was speciafically for the
>> >> > community.
>> >>
>> >> and the branch creation was also discussed.
>> >>
>> >> > Code provided by Fujitsu employees will never go through me with
>> >> > direct
>> >> > commit, it will all be added as patches, even extra tests and
>> >> > documentation
>> >> > as we want them and everyone else willing to help get the credit for
>> >> > it.
>> >>
>> >> we do the same. Folks provide patches and jira tickets to describe the
>> >> problem.
>> >>
>> >> > Furthermore, I personally didn't announce it because the branch will
>> >> > be
>> >> > very
>> >> > instable for a week or two until we finish adding the missing
>> >> > signatures
>> >> > (impl might not even always compile).
>> >>
>> >> dev@ is a developers community; so that would be fine :-)
>> >>
>> >> -Matthias
>> >>
>> >> > If community wasn't important in the process we would just have used
>> >> > a
>> >> > private repository at Fujitsu, worked on it for some time with my
>> >> > team,
>> >> > then
>> >> > commit some very large amount of code (real large) that would have
>> >> > needed a
>> >> > code grant, prevented the people to see at what rythm things were
>> >> > progressing and contributing. The only point I *could* give you here
>> >> > is
>> >> > that
>> >> > maybe I should have annouced the creation directly on the dev list
>> >> > and
>> >> > point
>> >> > on the JIRA ticket and SVN url rather than relying only on JIRA
>> >> > ticket
>> >> > report that get forwarded on the dev list.
>> >> >
>> >> >
>> >> > Regards,
>> >> >
>> >> > ~ Simon
>> >> >
>> >> >>
>> >> >> Regards,
>> >> >> Simon
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Matthias Wessendorf
>> >>
>> >> Need JSF and Web 2.0?
>> >> http://code.google.com/p/facesgoodies
>> >>
>> >> further stuff:
>> >> blog: http://matthiaswessendorf.wordpress.com/
>> >> sessions: http://www.slideshare.net/mwessendorf
>> >> mail: matzew-at-apache-dot-org
>> >
>> >
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> Need JSF and Web 2.0?
>> http://code.google.com/p/facesgoodies
>>
>> further stuff:
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> mail: matzew-at-apache-dot-org
>
>



-- 
Matthias Wessendorf

Need JSF and Web 2.0?
http://code.google.com/p/facesgoodies

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

Re: JSF2.0 implementation

[Bruno Aranda <br...@gmail.com>]

I am willing (as always) to contribute as much as my time permits to the JSF
2.0 implementation. I tried to find in the list what is going to be the big
picture, the roadmap to have a JSF 2.0 implementation. Do we have something
like that? How are we going to integrate Facelets, for instance? (good that
is now under ASL!). What part are you developing at the moment?

Thanks!

Bruno

2008/8/28 Matthias Wessendorf <ma...@apache.org>

> On Thu, Aug 28, 2008 at 4:50 PM, Simon Lessard
> <si...@gmail.com> wrote:
> >
> >
> > On Thu, Aug 28, 2008 at 10:35 AM, Matthias Wessendorf <matzew@apache.org
> >
> > wrote:
> >>
> >> On Thu, Aug 28, 2008 at 4:24 PM, Simon Lessard
> >> <si...@gmail.com> wrote:
> >> > Hi Simon,
> >> >
> >> >
> >> > On Thu, Aug 28, 2008 at 2:56 AM, Simon Kitching <skitching@apache.org
> >
> >> > wrote:
> >> >>
> >> >> I see from the commit list that a new JSF2.0 branch has been created.
> >> >>
> >> >> I don't remember seeing *any* kind of discussion or even announcement
> >> >> about this. While I am happy to see JSF2.0 work going on, this kind
> of
> >> >> approach does not seem to be at all in the "community" spirit. IMO,
> >> >> major
> >> >> events like this should be discussed beforehand.
> >> >
> >> > As mentioned by other people, there was a vote about this a while back
> .
> >> > Why
> >> > did I create it just now? Simply because my company agreed to provide
> >> > some
> >> > resource to help with the implementation and we were ready to get
> >> > started.
> >>
> >> One might ask here for a CCLA ;-)
> >> We did that for Oracle way back, and update once in a while all the
> >> contributors,
> >> that have signed the iCLA.
> >
> > Yeah, but Fujistu signed a CCLA already when I became commiter, so that's
> a
> > non issue as well.
>
> good.
>
> >
> >>
> >> >
> >> >>
> >> >> One issue, for example, is that the core-1.2 stuff is currently
> >> >> half-way-converted from the trinidad plugins to the
> >> >> myfaces-builder-plugin.
> >> >> So now it is branched, any changes need to be applied in two places.
> >> >
> >> > To be honest, I find this irrelevant, it's a branch, not a trunk and
> >> > I'll
> >> > most likely do some branch merging when core 1.2.x get release and the
> >> > plugin might have to change a little to support jsfVersion 2.0.
> >> >
> >> >>
> >> >> In addition, a large amount of code has just been committed by
> someone
> >> >> (slessard) who is not a particularly regular contributor to myfaces.
> >> >
> >> > I see even less relevance in that statement.
> >> >
> >> >>
> >> >> Where did this code come from? Do we need a code grant for it? Note
> >> >> that
> >> >> when code is developed iteratively on the dev list then there is no
> >> >> need for
> >> >> a grant. But a sudden code dump is different, even when contributed
> by
> >> >> someone who has signed a CLA.
> >> >
> >> > The code was coded just yesterday by me and is not much at all,
> creating
> >> > missing classes for the JavaDoc change log is in no matter a large
> >> > amount in
> >> > term of complexity. Also since I was the only author of it (my
> teammates
> >> > will wait until I have added the signatures). There's absolutely no
> need
> >> > of
> >> > code grant either.
> >>
> >> I agree on the code grant, b/c of it is really pretty trivial to
> >> create those API classes/interfaces
> >> (based on the javadoc log, as I said before).
> >> @signatures: you mean the iCLA / CCLA, aren't you ?
> >
> > nah, I meant method signatures, it will be easier for my teammates to
> know
> > what they have to do once there's a nice // TODO: Convert to JSF 2.0
> added
> > in every new method's body.
> >
> > As far as I understand the legal issues (might have to fallback to
> > legal@apache.org though), they won't need a CLA until they become
> commiters.
> > I don't know if I should have the company add their names to the CCLA
>
> no. wrong
> cla == contributor license agreement.
> I usually ask for that after one or two patches. Never been an issue at
> all.
> We (from ORA) add those contributors to our CCLA, and fax the update to
> Sam Ruby (our ASF secretary).
>
> > however. Technically, we aren't bound contractualy by any intellectual
> > property transfer with my employer and we're developping outside normal
> > business hours so we aren't directly paid either for it so I don't know
> if
> > adding their name to the CCLA is even needed or not.
>
> that means, what you develop on your sparetime is yours... NO CCLA update
> required. Cool
>
> -Matthias
>
> >
> >
> > ~ Simon
> >
> >>
> >> >
> >> >>
> >> >> And with 3 branches to now maintain, we need to discuss whether and
> >> >> when
> >> >> we phase out maintenance of the jsf-1.1 branch. Currently when users
> >> >> provide
> >> >> patches in jira, they almost always provide a patch against only one
> >> >> version
> >> >> and the committer ports it, which does increase the load on existing
> >> >> committers. When do we stop asking committers to do this when
> patching
> >> >> bugs?
> >> >
> >> > I can take care of the branch merging, this is how we handled the
> >> > trinidad
> >> > 1.2 branch at first, Adam would do the merging every now and then, so
> >> > I'm
> >> > not asking the committers to do some extra work.
> >>
> >> yup. not a big deal. Also I doubt that that many folks will work
> >> there, on the branch.
> >> If the branch needs some merging... fine as well, IMO.
> >>
> >> >
> >> >>
> >> >> To repeat, I'm *happy* that jsf2.0 implementation is in progress, and
> >> >> appreciate people contributing time to write an ASF-2.0-licensed
> >> >> implementation. But it is a  standard saying at Apache that
> "community
> >> >> is
> >> >> more important than code", and the "community" aspect here seems to
> >> >> have
> >> >> been rather neglected...
> >> >
> >> > I don't agree at all here. Although it wasn't announced on the dev
> list,
> >> > the
> >> > JIRA ticket created to attach patches was speciafically for the
> >> > community.
> >>
> >> and the branch creation was also discussed.
> >>
> >> > Code provided by Fujitsu employees will never go through me with
> direct
> >> > commit, it will all be added as patches, even extra tests and
> >> > documentation
> >> > as we want them and everyone else willing to help get the credit for
> it.
> >>
> >> we do the same. Folks provide patches and jira tickets to describe the
> >> problem.
> >>
> >> > Furthermore, I personally didn't announce it because the branch will
> be
> >> > very
> >> > instable for a week or two until we finish adding the missing
> signatures
> >> > (impl might not even always compile).
> >>
> >> dev@ is a developers community; so that would be fine :-)
> >>
> >> -Matthias
> >>
> >> > If community wasn't important in the process we would just have used a
> >> > private repository at Fujitsu, worked on it for some time with my
> team,
> >> > then
> >> > commit some very large amount of code (real large) that would have
> >> > needed a
> >> > code grant, prevented the people to see at what rythm things were
> >> > progressing and contributing. The only point I *could* give you here
> is
> >> > that
> >> > maybe I should have annouced the creation directly on the dev list and
> >> > point
> >> > on the JIRA ticket and SVN url rather than relying only on JIRA ticket
> >> > report that get forwarded on the dev list.
> >> >
> >> >
> >> > Regards,
> >> >
> >> > ~ Simon
> >> >
> >> >>
> >> >> Regards,
> >> >> Simon
> >> >>
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> Matthias Wessendorf
> >>
> >> Need JSF and Web 2.0?
> >> http://code.google.com/p/facesgoodies
> >>
> >> further stuff:
> >> blog: http://matthiaswessendorf.wordpress.com/
> >> sessions: http://www.slideshare.net/mwessendorf
> >> mail: matzew-at-apache-dot-org
> >
> >
>
>
>
> --
> Matthias Wessendorf
>
> Need JSF and Web 2.0?
> http://code.google.com/p/facesgoodies
>
> further stuff:
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> mail: matzew-at-apache-dot-org
>

Re: JSF2.0 implementation

[Matthias Wessendorf <ma...@apache.org>]

On Thu, Aug 28, 2008 at 4:50 PM, Simon Lessard
<si...@gmail.com> wrote:
>
>
> On Thu, Aug 28, 2008 at 10:35 AM, Matthias Wessendorf <ma...@apache.org>
> wrote:
>>
>> On Thu, Aug 28, 2008 at 4:24 PM, Simon Lessard
>> <si...@gmail.com> wrote:
>> > Hi Simon,
>> >
>> >
>> > On Thu, Aug 28, 2008 at 2:56 AM, Simon Kitching <sk...@apache.org>
>> > wrote:
>> >>
>> >> I see from the commit list that a new JSF2.0 branch has been created.
>> >>
>> >> I don't remember seeing *any* kind of discussion or even announcement
>> >> about this. While I am happy to see JSF2.0 work going on, this kind of
>> >> approach does not seem to be at all in the "community" spirit. IMO,
>> >> major
>> >> events like this should be discussed beforehand.
>> >
>> > As mentioned by other people, there was a vote about this a while back .
>> > Why
>> > did I create it just now? Simply because my company agreed to provide
>> > some
>> > resource to help with the implementation and we were ready to get
>> > started.
>>
>> One might ask here for a CCLA ;-)
>> We did that for Oracle way back, and update once in a while all the
>> contributors,
>> that have signed the iCLA.
>
> Yeah, but Fujistu signed a CCLA already when I became commiter, so that's a
> non issue as well.

good.

>
>>
>> >
>> >>
>> >> One issue, for example, is that the core-1.2 stuff is currently
>> >> half-way-converted from the trinidad plugins to the
>> >> myfaces-builder-plugin.
>> >> So now it is branched, any changes need to be applied in two places.
>> >
>> > To be honest, I find this irrelevant, it's a branch, not a trunk and
>> > I'll
>> > most likely do some branch merging when core 1.2.x get release and the
>> > plugin might have to change a little to support jsfVersion 2.0.
>> >
>> >>
>> >> In addition, a large amount of code has just been committed by someone
>> >> (slessard) who is not a particularly regular contributor to myfaces.
>> >
>> > I see even less relevance in that statement.
>> >
>> >>
>> >> Where did this code come from? Do we need a code grant for it? Note
>> >> that
>> >> when code is developed iteratively on the dev list then there is no
>> >> need for
>> >> a grant. But a sudden code dump is different, even when contributed by
>> >> someone who has signed a CLA.
>> >
>> > The code was coded just yesterday by me and is not much at all, creating
>> > missing classes for the JavaDoc change log is in no matter a large
>> > amount in
>> > term of complexity. Also since I was the only author of it (my teammates
>> > will wait until I have added the signatures). There's absolutely no need
>> > of
>> > code grant either.
>>
>> I agree on the code grant, b/c of it is really pretty trivial to
>> create those API classes/interfaces
>> (based on the javadoc log, as I said before).
>> @signatures: you mean the iCLA / CCLA, aren't you ?
>
> nah, I meant method signatures, it will be easier for my teammates to know
> what they have to do once there's a nice // TODO: Convert to JSF 2.0 added
> in every new method's body.
>
> As far as I understand the legal issues (might have to fallback to
> legal@apache.org though), they won't need a CLA until they become commiters.
> I don't know if I should have the company add their names to the CCLA

no. wrong
cla == contributor license agreement.
I usually ask for that after one or two patches. Never been an issue at all.
We (from ORA) add those contributors to our CCLA, and fax the update to
Sam Ruby (our ASF secretary).

> however. Technically, we aren't bound contractualy by any intellectual
> property transfer with my employer and we're developping outside normal
> business hours so we aren't directly paid either for it so I don't know if
> adding their name to the CCLA is even needed or not.

that means, what you develop on your sparetime is yours... NO CCLA update
required. Cool

-Matthias

>
>
> ~ Simon
>
>>
>> >
>> >>
>> >> And with 3 branches to now maintain, we need to discuss whether and
>> >> when
>> >> we phase out maintenance of the jsf-1.1 branch. Currently when users
>> >> provide
>> >> patches in jira, they almost always provide a patch against only one
>> >> version
>> >> and the committer ports it, which does increase the load on existing
>> >> committers. When do we stop asking committers to do this when patching
>> >> bugs?
>> >
>> > I can take care of the branch merging, this is how we handled the
>> > trinidad
>> > 1.2 branch at first, Adam would do the merging every now and then, so
>> > I'm
>> > not asking the committers to do some extra work.
>>
>> yup. not a big deal. Also I doubt that that many folks will work
>> there, on the branch.
>> If the branch needs some merging... fine as well, IMO.
>>
>> >
>> >>
>> >> To repeat, I'm *happy* that jsf2.0 implementation is in progress, and
>> >> appreciate people contributing time to write an ASF-2.0-licensed
>> >> implementation. But it is a  standard saying at Apache that "community
>> >> is
>> >> more important than code", and the "community" aspect here seems to
>> >> have
>> >> been rather neglected...
>> >
>> > I don't agree at all here. Although it wasn't announced on the dev list,
>> > the
>> > JIRA ticket created to attach patches was speciafically for the
>> > community.
>>
>> and the branch creation was also discussed.
>>
>> > Code provided by Fujitsu employees will never go through me with direct
>> > commit, it will all be added as patches, even extra tests and
>> > documentation
>> > as we want them and everyone else willing to help get the credit for it.
>>
>> we do the same. Folks provide patches and jira tickets to describe the
>> problem.
>>
>> > Furthermore, I personally didn't announce it because the branch will be
>> > very
>> > instable for a week or two until we finish adding the missing signatures
>> > (impl might not even always compile).
>>
>> dev@ is a developers community; so that would be fine :-)
>>
>> -Matthias
>>
>> > If community wasn't important in the process we would just have used a
>> > private repository at Fujitsu, worked on it for some time with my team,
>> > then
>> > commit some very large amount of code (real large) that would have
>> > needed a
>> > code grant, prevented the people to see at what rythm things were
>> > progressing and contributing. The only point I *could* give you here is
>> > that
>> > maybe I should have annouced the creation directly on the dev list and
>> > point
>> > on the JIRA ticket and SVN url rather than relying only on JIRA ticket
>> > report that get forwarded on the dev list.
>> >
>> >
>> > Regards,
>> >
>> > ~ Simon
>> >
>> >>
>> >> Regards,
>> >> Simon
>> >>
>> >
>> >
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> Need JSF and Web 2.0?
>> http://code.google.com/p/facesgoodies
>>
>> further stuff:
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> mail: matzew-at-apache-dot-org
>
>



-- 
Matthias Wessendorf

Need JSF and Web 2.0?
http://code.google.com/p/facesgoodies

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

Re: JSF2.0 implementation

[Simon Lessard <si...@gmail.com>]

On Thu, Aug 28, 2008 at 10:35 AM, Matthias Wessendorf <ma...@apache.org>wrote:

> On Thu, Aug 28, 2008 at 4:24 PM, Simon Lessard
> <si...@gmail.com> wrote:
> > Hi Simon,
> >
> >
> > On Thu, Aug 28, 2008 at 2:56 AM, Simon Kitching <sk...@apache.org>
> > wrote:
> >>
> >> I see from the commit list that a new JSF2.0 branch has been created.
> >>
> >> I don't remember seeing *any* kind of discussion or even announcement
> >> about this. While I am happy to see JSF2.0 work going on, this kind of
> >> approach does not seem to be at all in the "community" spirit. IMO,
> major
> >> events like this should be discussed beforehand.
> >
> > As mentioned by other people, there was a vote about this a while back .
> Why
> > did I create it just now? Simply because my company agreed to provide
> some
> > resource to help with the implementation and we were ready to get
> started.
>
> One might ask here for a CCLA ;-)
> We did that for Oracle way back, and update once in a while all the
> contributors,
> that have signed the iCLA.


Yeah, but Fujistu signed a CCLA already when I became commiter, so that's a
non issue as well.


>
>
> >
> >>
> >> One issue, for example, is that the core-1.2 stuff is currently
> >> half-way-converted from the trinidad plugins to the
> myfaces-builder-plugin.
> >> So now it is branched, any changes need to be applied in two places.
> >
> > To be honest, I find this irrelevant, it's a branch, not a trunk and I'll
> > most likely do some branch merging when core 1.2.x get release and the
> > plugin might have to change a little to support jsfVersion 2.0.
> >
> >>
> >> In addition, a large amount of code has just been committed by someone
> >> (slessard) who is not a particularly regular contributor to myfaces.
> >
> > I see even less relevance in that statement.
> >
> >>
> >> Where did this code come from? Do we need a code grant for it? Note that
> >> when code is developed iteratively on the dev list then there is no need
> for
> >> a grant. But a sudden code dump is different, even when contributed by
> >> someone who has signed a CLA.
> >
> > The code was coded just yesterday by me and is not much at all, creating
> > missing classes for the JavaDoc change log is in no matter a large amount
> in
> > term of complexity. Also since I was the only author of it (my teammates
> > will wait until I have added the signatures). There's absolutely no need
> of
> > code grant either.
>
> I agree on the code grant, b/c of it is really pretty trivial to
> create those API classes/interfaces
> (based on the javadoc log, as I said before).
> @signatures: you mean the iCLA / CCLA, aren't you ?


nah, I meant method signatures, it will be easier for my teammates to know
what they have to do once there's a nice // TODO: Convert to JSF 2.0 added
in every new method's body.

As far as I understand the legal issues (might have to fallback to
legal@apache.org though), they won't need a CLA until they become commiters.
I don't know if I should have the company add their names to the CCLA
however. Technically, we aren't bound contractualy by any intellectual
property transfer with my employer and we're developping outside normal
business hours so we aren't directly paid either for it so I don't know if
adding their name to the CCLA is even needed or not.


~ Simon


>
>
> >
> >>
> >> And with 3 branches to now maintain, we need to discuss whether and when
> >> we phase out maintenance of the jsf-1.1 branch. Currently when users
> provide
> >> patches in jira, they almost always provide a patch against only one
> version
> >> and the committer ports it, which does increase the load on existing
> >> committers. When do we stop asking committers to do this when patching
> bugs?
> >
> > I can take care of the branch merging, this is how we handled the
> trinidad
> > 1.2 branch at first, Adam would do the merging every now and then, so I'm
> > not asking the committers to do some extra work.
>
> yup. not a big deal. Also I doubt that that many folks will work
> there, on the branch.
> If the branch needs some merging... fine as well, IMO.
>
> >
> >>
> >> To repeat, I'm *happy* that jsf2.0 implementation is in progress, and
> >> appreciate people contributing time to write an ASF-2.0-licensed
> >> implementation. But it is a  standard saying at Apache that "community
> is
> >> more important than code", and the "community" aspect here seems to have
> >> been rather neglected...
> >
> > I don't agree at all here. Although it wasn't announced on the dev list,
> the
> > JIRA ticket created to attach patches was speciafically for the
> community.
>
> and the branch creation was also discussed.
>
> > Code provided by Fujitsu employees will never go through me with direct
> > commit, it will all be added as patches, even extra tests and
> documentation
> > as we want them and everyone else willing to help get the credit for it.
>
> we do the same. Folks provide patches and jira tickets to describe the
> problem.
>
> > Furthermore, I personally didn't announce it because the branch will be
> very
> > instable for a week or two until we finish adding the missing signatures
> > (impl might not even always compile).
>
> dev@ is a developers community; so that would be fine :-)
>
> -Matthias
>
> > If community wasn't important in the process we would just have used a
> > private repository at Fujitsu, worked on it for some time with my team,
> then
> > commit some very large amount of code (real large) that would have needed
> a
> > code grant, prevented the people to see at what rythm things were
> > progressing and contributing. The only point I *could* give you here is
> that
> > maybe I should have annouced the creation directly on the dev list and
> point
> > on the JIRA ticket and SVN url rather than relying only on JIRA ticket
> > report that get forwarded on the dev list.
> >
> >
> > Regards,
> >
> > ~ Simon
> >
> >>
> >> Regards,
> >> Simon
> >>
> >
> >
>
>
>
> --
> Matthias Wessendorf
>
> Need JSF and Web 2.0?
> http://code.google.com/p/facesgoodies
>
> further stuff:
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> mail: matzew-at-apache-dot-org
>

Re: JSF2.0 implementation

[Matthias Wessendorf <ma...@apache.org>]

On Thu, Aug 28, 2008 at 4:24 PM, Simon Lessard
<si...@gmail.com> wrote:
> Hi Simon,
>
>
> On Thu, Aug 28, 2008 at 2:56 AM, Simon Kitching <sk...@apache.org>
> wrote:
>>
>> I see from the commit list that a new JSF2.0 branch has been created.
>>
>> I don't remember seeing *any* kind of discussion or even announcement
>> about this. While I am happy to see JSF2.0 work going on, this kind of
>> approach does not seem to be at all in the "community" spirit. IMO, major
>> events like this should be discussed beforehand.
>
> As mentioned by other people, there was a vote about this a while back . Why
> did I create it just now? Simply because my company agreed to provide some
> resource to help with the implementation and we were ready to get started.

One might ask here for a CCLA ;-)
We did that for Oracle way back, and update once in a while all the
contributors,
that have signed the iCLA.

>
>>
>> One issue, for example, is that the core-1.2 stuff is currently
>> half-way-converted from the trinidad plugins to the myfaces-builder-plugin.
>> So now it is branched, any changes need to be applied in two places.
>
> To be honest, I find this irrelevant, it's a branch, not a trunk and I'll
> most likely do some branch merging when core 1.2.x get release and the
> plugin might have to change a little to support jsfVersion 2.0.
>
>>
>> In addition, a large amount of code has just been committed by someone
>> (slessard) who is not a particularly regular contributor to myfaces.
>
> I see even less relevance in that statement.
>
>>
>> Where did this code come from? Do we need a code grant for it? Note that
>> when code is developed iteratively on the dev list then there is no need for
>> a grant. But a sudden code dump is different, even when contributed by
>> someone who has signed a CLA.
>
> The code was coded just yesterday by me and is not much at all, creating
> missing classes for the JavaDoc change log is in no matter a large amount in
> term of complexity. Also since I was the only author of it (my teammates
> will wait until I have added the signatures). There's absolutely no need of
> code grant either.

I agree on the code grant, b/c of it is really pretty trivial to
create those API classes/interfaces
(based on the javadoc log, as I said before).
@signatures: you mean the iCLA / CCLA, aren't you ?

>
>>
>> And with 3 branches to now maintain, we need to discuss whether and when
>> we phase out maintenance of the jsf-1.1 branch. Currently when users provide
>> patches in jira, they almost always provide a patch against only one version
>> and the committer ports it, which does increase the load on existing
>> committers. When do we stop asking committers to do this when patching bugs?
>
> I can take care of the branch merging, this is how we handled the trinidad
> 1.2 branch at first, Adam would do the merging every now and then, so I'm
> not asking the committers to do some extra work.

yup. not a big deal. Also I doubt that that many folks will work
there, on the branch.
If the branch needs some merging... fine as well, IMO.

>
>>
>> To repeat, I'm *happy* that jsf2.0 implementation is in progress, and
>> appreciate people contributing time to write an ASF-2.0-licensed
>> implementation. But it is a  standard saying at Apache that "community is
>> more important than code", and the "community" aspect here seems to have
>> been rather neglected...
>
> I don't agree at all here. Although it wasn't announced on the dev list, the
> JIRA ticket created to attach patches was speciafically for the community.

and the branch creation was also discussed.

> Code provided by Fujitsu employees will never go through me with direct
> commit, it will all be added as patches, even extra tests and documentation
> as we want them and everyone else willing to help get the credit for it.

we do the same. Folks provide patches and jira tickets to describe the problem.

> Furthermore, I personally didn't announce it because the branch will be very
> instable for a week or two until we finish adding the missing signatures
> (impl might not even always compile).

dev@ is a developers community; so that would be fine :-)

-Matthias

> If community wasn't important in the process we would just have used a
> private repository at Fujitsu, worked on it for some time with my team, then
> commit some very large amount of code (real large) that would have needed a
> code grant, prevented the people to see at what rythm things were
> progressing and contributing. The only point I *could* give you here is that
> maybe I should have annouced the creation directly on the dev list and point
> on the JIRA ticket and SVN url rather than relying only on JIRA ticket
> report that get forwarded on the dev list.
>
>
> Regards,
>
> ~ Simon
>
>>
>> Regards,
>> Simon
>>
>
>



-- 
Matthias Wessendorf

Need JSF and Web 2.0?
http://code.google.com/p/facesgoodies

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

Re: JSF2.0 implementation

[Simon Lessard <si...@gmail.com>]

Hi Simon,


On Thu, Aug 28, 2008 at 2:56 AM, Simon Kitching <sk...@apache.org>wrote:

> I see from the commit list that a new JSF2.0 branch has been created.
>
> I don't remember seeing *any* kind of discussion or even announcement about
> this. While I am happy to see JSF2.0 work going on, this kind of approach
> does not seem to be at all in the "community" spirit. IMO, major events like
> this should be discussed beforehand.


As mentioned by other people, there was a vote about this a while back . Why
did I create it just now? Simply because my company agreed to provide some
resource to help with the implementation and we were ready to get started.


>
>
> One issue, for example, is that the core-1.2 stuff is currently
> half-way-converted from the trinidad plugins to the myfaces-builder-plugin.
> So now it is branched, any changes need to be applied in two places.


To be honest, I find this irrelevant, it's a branch, not a trunk and I'll
most likely do some branch merging when core 1.2.x get release and the
plugin might have to change a little to support jsfVersion 2.0.


>
>
> In addition, a large amount of code has just been committed by someone
> (slessard) who is not a particularly regular contributor to myfaces.


I see even less relevance in that statement.


> Where did this code come from? Do we need a code grant for it? Note that
> when code is developed iteratively on the dev list then there is no need for
> a grant. But a sudden code dump is different, even when contributed by
> someone who has signed a CLA.


The code was coded just yesterday by me and is not much at all, creating
missing classes for the JavaDoc change log is in no matter a large amount in
term of complexity. Also since I was the only author of it (my teammates
will wait until I have added the signatures). There's absolutely no need of
code grant either.


>
>
> And with 3 branches to now maintain, we need to discuss whether and when we
> phase out maintenance of the jsf-1.1 branch. Currently when users provide
> patches in jira, they almost always provide a patch against only one version
> and the committer ports it, which does increase the load on existing
> committers. When do we stop asking committers to do this when patching bugs?


I can take care of the branch merging, this is how we handled the trinidad
1.2 branch at first, Adam would do the merging every now and then, so I'm
not asking the committers to do some extra work.


>
>
> To repeat, I'm *happy* that jsf2.0 implementation is in progress, and
> appreciate people contributing time to write an ASF-2.0-licensed
> implementation. But it is a  standard saying at Apache that "community is
> more important than code", and the "community" aspect here seems to have
> been rather neglected...


I don't agree at all here. Although it wasn't announced on the dev list, the
JIRA ticket created to attach patches was speciafically for the community.
Code provided by Fujitsu employees will never go through me with direct
commit, it will all be added as patches, even extra tests and documentation
as we want them and everyone else willing to help get the credit for it.
Furthermore, I personally didn't announce it because the branch will be very
instable for a week or two until we finish adding the missing signatures
(impl might not even always compile).

If community wasn't important in the process we would just have used a
private repository at Fujitsu, worked on it for some time with my team, then
commit some very large amount of code (real large) that would have needed a
code grant, prevented the people to see at what rythm things were
progressing and contributing. The only point I *could* give you here is that
maybe I should have annouced the creation directly on the dev list and point
on the JIRA ticket and SVN url rather than relying only on JIRA ticket
report that get forwarded on the dev list.


Regards,

~ Simon


>
>
> Regards,
> Simon
>
>

Re: JSF2.0 implementation

[Matthias Wessendorf <ma...@apache.org>]

On Thu, Aug 28, 2008 at 9:00 AM, Zubin Wadia <zw...@gmail.com> wrote:
> Simon,
>
> You can do a search for Subject = '[OT] JSF 2.0' on the Dev list.
>
> I believe that discussion, begun by MW turned into a discussion about branch
> creation... then a couple of +1s followed.... and I assume that's where the
> branch was born.

correct.
Also, it has happened quite some times that some code was "just"
committed (or close to be)
-Orchestra (aka Fusion)
-Dojo-extensions, from Werner (are they already in?)

If you feel uncomfortable, please do a revert.

-Matthias

>
> Cheers,
>
> Zubin.
>
> On 8/28/08, Simon Kitching <sk...@apache.org> wrote:
>>
>> I see from the commit list that a new JSF2.0 branch has been created.
>>
>> I don't remember seeing *any* kind of discussion or even announcement
>> about this. While I am happy to see JSF2.0 work going on, this kind of
>> approach does not seem to be at all in the "community" spirit. IMO, major
>> events like this should be discussed beforehand.
>>
>> One issue, for example, is that the core-1.2 stuff is currently
>> half-way-converted from the trinidad plugins to the myfaces-builder-plugin.
>> So now it is branched, any changes need to be applied in two places.
>>
>> In addition, a large amount of code has just been committed by someone
>> (slessard) who is not a particularly regular contributor to myfaces. Where
>> did this code come from? Do we need a code grant for it? Note that when code
>> is developed iteratively on the dev list then there is no need for a grant.
>> But a sudden code dump is different, even when contributed by someone who
>> has signed a CLA.
>>
>> And with 3 branches to now maintain, we need to discuss whether and when
>> we phase out maintenance of the jsf-1.1 branch. Currently when users provide
>> patches in jira, they almost always provide a patch against only one version
>> and the committer ports it, which does increase the load on existing
>> committers. When do we stop asking committers to do this when patching bugs?
>>
>> To repeat, I'm *happy* that jsf2.0 implementation is in progress, and
>> appreciate people contributing time to write an ASF-2.0-licensed
>> implementation. But it is a  standard saying at Apache that "community is
>> more important than code", and the "community" aspect here seems to have
>> been rather neglected...
>>
>> Regards,
>> Simon
>>
>
>



-- 
Matthias Wessendorf

Need JSF and Web 2.0?
http://code.google.com/p/facesgoodies

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

Re: JSF2.0 implementation

[Matthias Wessendorf <ma...@apache.org>]

On Thu, Aug 28, 2008 at 9:10 AM, Simon Kitching <sk...@apache.org> wrote:
> But that thread is from Jun 04 - that is very nearly 3 months ago. Since
> then, nothing as far as I know.

ok, perhaps just a "hello, I have done some development on my machine,
is the myfaces community still willing to provide a JSF 2.0
implementation".
That would have been enough, IMO.

-Matthias

>
> Zubin Wadia schrieb:
>>
>> Simon,
>>
>> You can do a search for Subject = '[OT] JSF 2.0' on the Dev list.
>>
>> I believe that discussion, begun by MW turned into a discussion about
>> branch creation... then a couple of +1s followed.... and I assume that's
>> where the branch was born.
>>
>> Cheers,
>>
>> Zubin.
>>
>> On 8/28/08, *Simon Kitching* <skitching@apache.org
>> <ma...@apache.org>> wrote:
>>
>>    I see from the commit list that a new JSF2.0 branch has been created.
>>
>>    I don't remember seeing *any* kind of discussion or even
>>    announcement about this. While I am happy to see JSF2.0 work going
>>    on, this kind of approach does not seem to be at all in the
>>    "community" spirit. IMO, major events like this should be
>>    discussed beforehand.
>>
>>    One issue, for example, is that the core-1.2 stuff is currently
>>    half-way-converted from the trinidad plugins to the
>>    myfaces-builder-plugin. So now it is branched, any changes need to
>>    be applied in two places.
>>
>>    In addition, a large amount of code has just been committed by
>>    someone (slessard) who is not a particularly regular contributor
>>    to myfaces. Where did this code come from? Do we need a code grant
>>    for it? Note that when code is developed iteratively on the dev
>>    list then there is no need for a grant. But a sudden code dump is
>>    different, even when contributed by someone who has signed a CLA.
>>
>>    And with 3 branches to now maintain, we need to discuss whether
>>    and when we phase out maintenance of the jsf-1.1 branch. Currently
>>    when users provide patches in jira, they almost always provide a
>>    patch against only one version and the committer ports it, which
>>    does increase the load on existing committers. When do we stop
>>    asking committers to do this when patching bugs?
>>
>>    To repeat, I'm *happy* that jsf2.0 implementation is in progress,
>>    and appreciate people contributing time to write an
>>    ASF-2.0-licensed implementation. But it is a  standard saying at
>>    Apache that "community is more important than code", and the
>>    "community" aspect here seems to have been rather neglected...
>>
>>    Regards,
>>    Simon
>>
>>
>
>



-- 
Matthias Wessendorf

Need JSF and Web 2.0?
http://code.google.com/p/facesgoodies

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

Re: JSF2.0 implementation

[Simon Kitching <sk...@apache.org>]

But that thread is from Jun 04 - that is very nearly 3 months ago. Since 
then, nothing as far as I know.

Zubin Wadia schrieb:
> Simon,
>
> You can do a search for Subject = '[OT] JSF 2.0' on the Dev list.
>
> I believe that discussion, begun by MW turned into a discussion about 
> branch creation... then a couple of +1s followed.... and I assume 
> that's where the branch was born.
>
> Cheers,
>
> Zubin.
>
> On 8/28/08, *Simon Kitching* <skitching@apache.org 
> <ma...@apache.org>> wrote:
>
>     I see from the commit list that a new JSF2.0 branch has been created.
>
>     I don't remember seeing *any* kind of discussion or even
>     announcement about this. While I am happy to see JSF2.0 work going
>     on, this kind of approach does not seem to be at all in the
>     "community" spirit. IMO, major events like this should be
>     discussed beforehand.
>
>     One issue, for example, is that the core-1.2 stuff is currently
>     half-way-converted from the trinidad plugins to the
>     myfaces-builder-plugin. So now it is branched, any changes need to
>     be applied in two places.
>
>     In addition, a large amount of code has just been committed by
>     someone (slessard) who is not a particularly regular contributor
>     to myfaces. Where did this code come from? Do we need a code grant
>     for it? Note that when code is developed iteratively on the dev
>     list then there is no need for a grant. But a sudden code dump is
>     different, even when contributed by someone who has signed a CLA.
>
>     And with 3 branches to now maintain, we need to discuss whether
>     and when we phase out maintenance of the jsf-1.1 branch. Currently
>     when users provide patches in jira, they almost always provide a
>     patch against only one version and the committer ports it, which
>     does increase the load on existing committers. When do we stop
>     asking committers to do this when patching bugs?
>
>     To repeat, I'm *happy* that jsf2.0 implementation is in progress,
>     and appreciate people contributing time to write an
>     ASF-2.0-licensed implementation. But it is a  standard saying at
>     Apache that "community is more important than code", and the
>     "community" aspect here seems to have been rather neglected...
>
>     Regards,
>     Simon
>
>

Re: JSF2.0 implementation

[Zubin Wadia <zw...@gmail.com>]

Simon,

You can do a search for Subject = '[OT] JSF 2.0' on the Dev list.

I believe that discussion, begun by MW turned into a discussion about branch
creation... then a couple of +1s followed.... and I assume that's where the
branch was born.

Cheers,

Zubin.

On 8/28/08, Simon Kitching <sk...@apache.org> wrote:
>
> I see from the commit list that a new JSF2.0 branch has been created.
>
> I don't remember seeing *any* kind of discussion or even announcement about
> this. While I am happy to see JSF2.0 work going on, this kind of approach
> does not seem to be at all in the "community" spirit. IMO, major events like
> this should be discussed beforehand.
>
> One issue, for example, is that the core-1.2 stuff is currently
> half-way-converted from the trinidad plugins to the myfaces-builder-plugin.
> So now it is branched, any changes need to be applied in two places.
>
> In addition, a large amount of code has just been committed by someone
> (slessard) who is not a particularly regular contributor to myfaces. Where
> did this code come from? Do we need a code grant for it? Note that when code
> is developed iteratively on the dev list then there is no need for a grant.
> But a sudden code dump is different, even when contributed by someone who
> has signed a CLA.
>
> And with 3 branches to now maintain, we need to discuss whether and when we
> phase out maintenance of the jsf-1.1 branch. Currently when users provide
> patches in jira, they almost always provide a patch against only one version
> and the committer ports it, which does increase the load on existing
> committers. When do we stop asking committers to do this when patching bugs?
>
> To repeat, I'm *happy* that jsf2.0 implementation is in progress, and
> appreciate people contributing time to write an ASF-2.0-licensed
> implementation. But it is a  standard saying at Apache that "community is
> more important than code", and the "community" aspect here seems to have
> been rather neglected...
>
> Regards,
> Simon
>
>

Re: JSF2.0 implementation

[Matthias Wessendorf <ma...@apache.org>]

On Thu, Aug 28, 2008 at 8:56 AM, Simon Kitching <sk...@apache.org> wrote:
> I see from the commit list that a new JSF2.0 branch has been created.

which is good.

>
> I don't remember seeing *any* kind of discussion or even announcement about
> this. While I am happy to see JSF2.0 work going on, this kind of approach
> does not seem to be at all in the "community" spirit. IMO, major events like
> this should be discussed beforehand.

hrm, I was active on this thread:
http://www.mail-archive.com/dev@myfaces.apache.org/msg32651.html

>
> One issue, for example, is that the core-1.2 stuff is currently
> half-way-converted from the trinidad plugins to the myfaces-builder-plugin.
> So now it is branched, any changes need to be applied in two places.

that is true, but I think we can live with it.

>
> In addition, a large amount of code has just been committed by someone
> (slessard) who is not a particularly regular contributor to myfaces. Where
> did this code come from? Do we need a code grant for it? Note that when code

he is part of the Trinidad project; And it was already mentioned that
some "offline"
developments are OK. Remember the discussion with Werner's dojo extensions
for Tomahawk ?

> is developed iteratively on the dev list then there is no need for a grant.
> But a sudden code dump is different, even when contributed by someone who
> has signed a CLA.

in Werner's case it was not (at least that's what I remember from the
discussion)

>
> And with 3 branches to now maintain, we need to discuss whether and when we
> phase out maintenance of the jsf-1.1 branch. Currently when users provide
> patches in jira, they almost always provide a patch against only one version
> and the committer ports it, which does increase the load on existing
> committers. When do we stop asking committers to do this when patching bugs?

Why not putting JSF 1.1 to maintain stage;
Do some more JSF 1.2 releases (like Leo is planing to do)
and keep the JSF 2.0 "active". even if we need to re-branch
(or need to apply some other (plugin related) changes

>
> To repeat, I'm *happy* that jsf2.0 implementation is in progress, and
> appreciate people contributing time to write an ASF-2.0-licensed
> implementation. But it is a  standard saying at Apache that "community is
> more important than code", and the "community" aspect here seems to have
> been rather neglected...

Ok, we did a small discussion on that.
The code he added is listed in the JavaDoc, from the spec...
I think we are fine here.

-Matthias

>
> Regards,
> Simon
>
>



-- 
Matthias Wessendorf

Need JSF and Web 2.0?
http://code.google.com/p/facesgoodies

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org