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/
