> -----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 objects. The reason it's enticing to move it
> in-house is that implementations of the externalcontext depend a lot on
> JSF itself. Enhancements/bug fixes could parallel those in faces and
> the
> bridge. Still, all I really need are portlet JSF test classes. I don't
> really care where it lives although I'd prefer to contribute to only
> one
> project. :)

I don't really see why the physical location affects the ability to fix bugs
or do enhancements in parallel, unless it depends on some common
implementation classes. Or, are you talking more about releases?

Well, I'm happy whether it's in MyFaces or Shale, as long as we can update
it for JSF 1.2 and the Bridge. So, if you want it to be part of MyFaces and
are willing to deal with the work of getting it established, I think you'd
have a good case. 

What do others think (especially Gary)?

> Kito D. Mann wrote:
> >
> > *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 about moving Shale
> over to
> > > MyFaces, people were worried about resources for maintaining it.
> And
> > Shale
> > > is an *existing* code base :-). I think it'd make a lot more sense
> to
> > > migrate the existing suites to JSF 2 branches.
> > >
> >
> > The big issue I had with merging was that the majority didn't want to
> > bring over all of shale. At this point, I don't think it would be
> > responsible just to drop support unless you could offer a comparable
> > feature.
> >
> > True. I thought it might make sense to bring the biggest pieces over
> > to MyFaces, but if we can revive part of Shale's development, I'm
> fine
> > with that too. I just wanted to avoid atrophy of the entire Shale
> code
> > base :-).
> >
> > The shale's test library is one of the few that have not been
> > reinvented over and over and that seemed to be where the root
> interest
> > is with myfaces.
> >
> > In terms of maintaining Shale, we most certainly encourage
> > contributions the same as myfaces :-)
> >
> > Of course :-).
> >
> > Gary
> >
> >
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > Kito D. Mann - Author, JavaServer Faces in Action
> > > http://www.virtua.com - JSF/Java EE consulting, training, and
> mentoring
> > > http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
> > > phone: +1 203-653-2989
> > > fax: +1 203-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 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
> > > > exis! ting re nderkits going forward. Getting MyFaces core up to
> > 2.0 is
> > > > going to take away interest from the new project as is getting
> > > > renderkits like Trinidad to be JSF 2.0 compatible. This is not to
> say
> > > > that there isn't an interest in this, but one could spend
> hundreds of
> > > > developer hours getting their head around Trinidad alone, and
> without
> > > > the support of the majority of those currently active in the
> > community,
> > > > this project may be doomed from the start. You may be able to
> > leverage
> > > > some resources from other projects by moving as much stuff as
> > possible
> > > > into the commons, but projects of this scope take a lot of time
> > and my
> > > > guess is that you're basically looking at growing a new
> community.
> > > >
> > > > I would seriously look at bringing a project of this scope into
> > > > incubator first. It'll hopefully help you to build the community
> you
> > &! gt; > ; need.
> > > >
> > > > Scott
> > > >
> > > > Bruno Aranda wrote:
> > > > > 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 and Tobago, any help is welcome too. At
> the
> > end,
> > > > > it is up to each individual :)
> > > > >
> > > > > Cheers,
> > > > >
> > > > > Bruno
> > > > >
> > > > > On 31/03/2008, *simon*
> > > > > > wrote:
> > > > >
> > > > > 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 time
> it's
> > > > > therefore possible to discard the bits that have too much
> overlap
> > > > with
> > > > > other projects (esp Trinidad).
> > > > >
> > > > > That doesn't mean that the current Tomahawk will be abandoned,
> > > > but
> > > > > it is
> > > > > an opportunity to scavenge the best bits for commons and
> discard
> > > > the
> > > > > rest. But I'd really like to see new stuff go into the
> "commons"
> > > > > projects myself. Whether commons is JSF1.2 or JSF2.0 depends on
> > > > the
> > > > > relative progress of commons vs the JSF spec I suppose :-).
> > > ! > &g t;
> > > > > I can't see Trinidad being rewritten anytime soon; that's a
> > > > pretty big
> > > > > job. Just getting a core JSF-2.0 implementation done is likely
> to
> > > > suck
> > > > > up all the spare time of the current myfaces contributors. And,
> > > > > like for
> > > > > Tomahawk, there is a big pool of people who want to use
> Trinidad
> > > > on
> > > > > JSF1.2 (including the committers employed by Oracle) so the
> > > > > current form
> > > > > of Trinidad will not be going away in the near future.
> > > > >
> > > > > I'm not aware of anything in JSF2.0 that is a radical
> improvement
> > > > over
> > > > > JSF1.2. Lots of nice bits, but does it really make components
> > > > work
> > > > > faster or vastly more efficient than can be done within JSF1.2?
> > > > >
> > > > > Regards,
> > > > >
> > > ! > &g t; Simon
> > > > >
> > > > >
> > > > > On Mon, 2008-03-31 at 13:50 -0600, Scott O'Bryan wrote:
> > > > > > +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 going forward and I would suspect the other
> > > > > renderkits
> > > > > > are as well.
> > > > > >
> > > > > > Scott
> > > > > >
> > > > > > Jesse Alexander (KSFH 323) wrote:
> > > > > > > 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 missing some "cool" components
> > > > > > > - partially have duplicated components
> > > > > > > - are partially missing important concepts
> > > > > > >
> > > > > > > JSF 2.0 brings a new concept to do components.
> > > > > > >
> > > > > > > Now it would be possible to update each component set to
> JSF
> > > > > 2.0...
> > > > > > > but a Tomahawk/JSF2 is "expected" to ! be back ward
> compatible.
> > > > So it
> > > > > > > would be difficult to radically change components or
> > > > eliminate
> > > > > some
> > > > > > > duplicates...
> > > > > > >
> > > > > > > Whereas a new component set that would
> > > > > > > - take all good concepts from the existing 3 component sets
> > > > > > > (and maybe some more from other comp-sets?)
> > > > > > > - deliver a clean set of components
> > > > > > > - just do it for JSF 2.0
> > > > > > > - not have to take backwards compatibility into
> consideration
> > > > > > >
> > > > > > >
> > > > > > > I think if such a new component set would fit, then it
> would
> > > > > be now the
> > > > > > > right time to think about the requirements... and as soon
> as
> > > > a
> > > > > > &g! t; work able beta is around the first steps for the
> > realization
> > > > > could be
> > > > > > > made...
> > > > > > >
> > > > > > > regards
> > > > > > > Alexander
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > >
> >

Reply via email to