myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Lessard" <simon.lessar...@gmail.com>
Subject Re: JSF2.0 implementation
Date Thu, 28 Aug 2008 16:13:37 GMT
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
>>
>
>

Mime
View raw message