Thank you Simon On Fri, Aug 29, 2008 at 2:53 AM, Simon Lessard <[EMAIL PROTECTED]>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 <[EMAIL PROTECTED]>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 <[EMAIL PROTECTED]> wrote: >> >>> Thank you Simon. I will join this soon. >>> >>> >>> On Thu, Aug 28, 2008 at 7:13 PM, Simon Lessard < >>> [EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>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 <[EMAIL PROTECTED]> >>>>> >>>>> On Thu, Aug 28, 2008 at 4:50 PM, Simon Lessard >>>>>> <[EMAIL PROTECTED]> wrote: >>>>>> > >>>>>> > >>>>>> > On Thu, Aug 28, 2008 at 10:35 AM, Matthias Wessendorf < >>>>>> [EMAIL PROTECTED]> >>>>>> > wrote: >>>>>> >> >>>>>> >> On Thu, Aug 28, 2008 at 4:24 PM, Simon Lessard >>>>>> >> <[EMAIL PROTECTED]> wrote: >>>>>> >> > Hi Simon, >>>>>> >> > >>>>>> >> > >>>>>> >> > On Thu, Aug 28, 2008 at 2:56 AM, Simon Kitching < >>>>>> [EMAIL PROTECTED]> >>>>>> >> > 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 >>>>>> > [EMAIL PROTECTED] 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/
