:[EMAIL PROTECTED]
*Sent:* Wednesday, April 02, 2008 11:16 AM
*To:* MyFaces Development; [EMAIL PROTECTED]; 'MyFaces Development'
*Cc:* Kito D. Mann
*Subject:* RE: JSF 2.0 component set
From: Kito D. Mann [EMAIL PROTECTED]
I just want to add that when we were talking about moving Shale
, April 02, 2008 11:16 AM
*To:* MyFaces Development; [EMAIL PROTECTED]; 'MyFaces Development'
*Cc:* Kito D. Mann
*Subject:* RE: JSF 2.0 component set
From: Kito D. Mann [EMAIL PROTECTED]
I just want to add that when we were talking about moving Shale
over to
MyFaces, people
-Original Message-
From: Scott O'Bryan [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 03, 2008 6:39 PM
To: [EMAIL PROTECTED]
Cc: 'MyFaces Development'; 'Gary VanMatre'
Subject: Re: shale-test location (was RE: JSF 2.0 component set)
I don't really see why the physical location
-Original Message-
From: Scott O'Bryan [mailto:[EMAIL PROTECTED]
Sent: Friday, April 04, 2008 12:12 PM
To: MyFaces Development
Subject: Re: shale-test location (was RE: JSF 2.0 component set)
Yeah, the conversation has already gone on longer then I intended. I
was merely
From: Gary VanMatre [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 02, 2008 11:16 AM
To: MyFaces Development; [EMAIL PROTECTED]; 'MyFaces Development'
Cc: Kito D. Mann
Subject: RE: JSF 2.0 component set
From: Kito D. Mann [EMAIL PROTECTED]
I just want to add that when we were talking
; [EMAIL PROTECTED]; 'MyFaces Development'
*Cc:* Kito D. Mann
*Subject:* RE: JSF 2.0 component set
From: Kito D. Mann [EMAIL PROTECTED]
I just want to add that when we were talking about moving Shale over to
MyFaces, people were worried about resources for maintaining it. And
Shale
is an *existing
-Original Message-
From: Scott O'Bryan [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 03, 2008 3:21 PM
To: MyFaces Development
Cc: 'Gary VanMatre'
Subject: Re: JSF 2.0 component set
I foresee an exact copy of the functionality outlined by shale-test,
only with portlet mock
Kito - ShaleTest is already JSF 1.2
Scott
Kito D. Mann wrote:
-Original Message-
From: Scott O'Bryan [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 03, 2008 3:21 PM
To: MyFaces Development
Cc: 'Gary VanMatre'
Subject: Re: JSF 2.0 component set
I foresee an exact copy
02, 2008 11:16 AM
*To:* MyFaces Development; [EMAIL PROTECTED]; 'MyFaces Development'
*Cc:* Kito D. Mann
*Subject:* RE: JSF 2.0 component set
From: Kito D. Mann [EMAIL PROTECTED]
I just want to add that when we were talking about moving Shale
over to
MyFaces, people were
-
From: Scott O'Bryan [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 03, 2008 3:21 PM
To: MyFaces Development
Cc: 'Gary VanMatre'
Subject: Re: JSF 2.0 component set
I foresee an exact copy of the functionality outlined by shale-test,
only with portlet mock objects. The reason it's enticing
:
*From:* Gary VanMatre [mailto:[EMAIL PROTECTED]
*Sent:* Wednesday, April 02, 2008 11:16 AM
*To:* MyFaces Development; [EMAIL PROTECTED]; 'MyFaces Development'
*Cc:* Kito D. Mann
*Subject:* RE: JSF 2.0 component set
From: Kito D. Mann [EMAIL PROTECTED]
I just want to add
: Monday, March 31, 2008 4:39 PM
To: MyFaces Development
Subject: Re: JSF 2.0 component set
Bruno, I totally agree, but we don't want a lot of dead projects out
there either. My point, and I think Simon's as well, is that much of
the contributions to the MyFaces Projects and renderkits
You're absolutely right that it can happen if enough people are
interested in doing it. That's what OSS is all about. And if
it happens,
that would be great.
This is the main target for my initial post: check whether enough
interested developers could be found.
My comment is just about
I am wondering whether the event of JSF 2.0 would not be a good
moment to create a new component set.
Well... another component set?
The main thoughts behind it are
- the 3 MyFaces component sets
- are somewhat incompatible
- have each their good points
- have some weak points
- are
Hi!
Now it would be possible to update each component set to JSF 2.0...
but a Tomahawk/JSF2 is expected to be backward compatible. So it
would be difficult to radically change components or eliminate some
duplicates...
+1
I'd like to see this too, though, I think Oracle wouldn't give up
+0
While I see the merit of starting over (and certainly wouldn't argue
against a new component set based off of 2.0), I don't think we should
abadon/restrict renderkits from continuing to support emerging
standards. I know that many of the folks on Trinidad are interested in
supporting 2.0
Well Trinidad is not an Oracle product, it's an Apache product.
Nonetheless, I imagine it would be a good bet that Oracle would want to
continue to support Trinidad going forward. That said, there is no
reason that someone couldn't start a new renderkit. The code is
open-sourced. I just
the JSF 2.0
programming model and concepts? It would not preclude Tomahawk, Tobago
et al from moving to JSF 2.0 if that is the choice, but at the same time
it would provide a fresh, unified JSF 2.0 component set that isn't
hamstrung by backwards compatibility concerns and could move in its own
Tomahawk certainly does need a radical refresh. It's got some useful
stuff, but is very ugly internally.
There is slow work going on at the moment on something called the
myfaces commons projects (or some similar name). The idea is to split
up tomahawk into about 4 different pieces. At the same
to JSF 2.0 if that is the choice,
but at the same time it would provide a fresh, unified JSF 2.0
component set that isn't hamstrung by backwards compatibility concerns
and could move in its own direction if need be.
On a related note, what is the status of MyFaces and JSF 2.0? Is
there any
I don't see why not we could start a new component set for jsf 2.0 if there
is enough interest within the developers and users. This is a community
thing and if people worked heavily in such a project and the result was
good, I don't see why it should not exist. If others want to maintain
Trinidad
You're absolutely right that it can happen if enough people are
interested in doing it. That's what OSS is all about. And if it happens,
that would be great.
My comment is just about what is *likely* to happen without any sudden
new inflow of volunteers. The original poster suggested it would be
You beat me to it.. :)
simon wrote:
You're absolutely right that it can happen if enough people are
interested in doing it. That's what OSS is all about. And if it happens,
that would be great.
My comment is just about what is *likely* to happen without any sudden
new inflow of volunteers.
Bruno, I totally agree, but we don't want a lot of dead projects out
there either. My point, and I think Simon's as well, is that much of
the contributions to the MyFaces Projects and renderkits comes from
companies and individuals who have a vested interest in supporting the
existing
programming model and concepts? It would not
preclude Tomahawk, Tobago et al from moving to JSF 2.0 if that is the
choice, but at the same time it would provide a fresh, unified JSF
2.0 component set that isn't hamstrung by backwards compatibility
concerns and could move in its own direction if need
and concepts? It
would not preclude Tomahawk, Tobago et al from moving to JSF 2.0 if
that is the choice, but at the same time it would provide a fresh,
unified JSF 2.0 component set that isn't hamstrung by backwards
compatibility concerns and could move in its own direction if need be.
On a related
-653-2988
-Original Message-
From: Scott O'Bryan [mailto:[EMAIL PROTECTED]
Sent: Monday, March 31, 2008 4:39 PM
To: MyFaces Development
Subject: Re: JSF 2.0 component set
Bruno, I totally agree, but we don't want a lot of dead projects out
there either. My point, and I think Simon's
: Re: JSF 2.0 component set
Bruno, I totally agree, but we don't want a lot of dead projects out
there either. My point, and I think Simon's as well, is that much
of
the contributions to the MyFaces Projects and renderkits comes from
companies and individuals who have a vested interest
-Original Message-
From: Scott O'Bryan [mailto:[EMAIL PROTECTED]
Sent: Monday, March 31, 2008 5:07 PM
To: MyFaces Development
Subject: Re: JSF 2.0 component set
That is a good point and this is even worse. Shale not only has an
existing code base, but also an existing community
Cool, yay.. Not only can the bridge use it for some testing, but I've
got a commons project I'd like to use it with. Not to mention Trinidad.
I wouldn't argue if you guys wanted to move shale-test over though. :)
The Bridge needs something similar to support testing of portlet JSF
30 matches
Mail list logo
