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 Fri, 29 Aug 2008 15:23:54 GMT
 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
<mwessendorf@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 <<simon.lessard.3@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 < <hazems@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 <<simon.lessard.3@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 <<brunoaranda@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 < <matzew@apache.org>matzew@apache.org>
>>>>>
>>>>> On Thu, Aug 28, 2008 at 4:50 PM, Simon Lessard
>>>>>> < <simon.lessard.3@gmail.com>simon.lessard.3@gmail.com>
wrote:
>>>>>> >
>>>>>> >
>>>>>> > On Thu, Aug 28, 2008 at 10:35 AM, Matthias Wessendorf <<matzew@apache.org>
>>>>>> matzew@apache.org>
>>>>>> > wrote:
>>>>>> >>
>>>>>> >> On Thu, Aug 28, 2008 at 4:24 PM, Simon Lessard
>>>>>> >> < <simon.lessard.3@gmail.com>simon.lessard.3@gmail.com>
wrote:
>>>>>> >> > Hi Simon,
>>>>>> >> >
>>>>>> >> >
>>>>>> >> > On Thu, Aug 28, 2008 at 2:56 AM, Simon Kitching <<skitching@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
>>>>>> > <legal@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/
>>>
>>
>>
>

Mime
View raw message