myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthias Wessendorf <mwessend...@gmail.com>
Subject Re: JSF2.0 implementation
Date Fri, 29 Aug 2008 05:18:16 GMT


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 <hazems@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  
> <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 <matzew@apache.org>
>
> On Thu, Aug 28, 2008 at 4:50 PM, Simon Lessard
> <simon.lessard.3@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
> >> <simon.lessard.3@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/
>
>

Mime
View raw message