> -----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 expressing sentiments that the moving of shale-test is not > something I would oppose. It is frustrating though to have to port the > bridges ExternalContext logic to another platform. The logic in JSF is > largely tivial, but the Bridge environment has some extra complexities. > > Understand also that I was in no way proposing the need to make > configuration of your webapp matter for your test environment. Just > because one may use a piece of implementation from another project > doesn't mean you need to use the whole thing. My point was that much > of > the code in shale-test is unnecessary *IF* you are able to leverage the > same work from an already built faces container. This is something > that > shale cannot do currently and it leaves maintenance for changes to > ExternalContext (in both the portal and servlet environments) > co-existing in two locations. > > Moving on, Gary, since your a PMC of shale, what would be the chances > that we can add Portlet 1.0/JSF 1.2 testcases to shale-test. I believe > Kito was looking at doing some of this work and I would be interrested > also. I know that the Bridge can certainly use it (not necessarily for > the TCK, but for build-time unit tests, and certainly my > myfaces-commons-configurator project and my ExternalContextUtils in the > myfaces-commons-util. Would the community be open to adding portlet > support?
I'm certainly willing to help. There are some changes I'd like to make for shale-test in general anyway. > Paul Spencer wrote: > > Gary, > > I also use shale-test. One of the feature in the unreleased 1.1.0 > > allows you the test against any JSF 1.1/1.2 implementation without > > having to replace the faces.xml configuration inside the test. Thus > > keeping the test framework independent from an implantation. Which is > a > > good thing and something I support. Gary VanMatre has been named > > Shale's PMC, and hopefully he, with our help, will revive the > community. > > > > FYI: Their have been many threads related to moving parts of Shale > into > > MyFaces. Lets not start another one while Shale is still alive. > > > > > > Paul Spencer > > > > > > > > > > Gary VanMatre wrote: > >> -------------- Original message ---------------------- > >> From: "Scott O'Bryan" <[EMAIL PROTECTED]> > >>>> 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 releases are part of it. I was meerly bringing up that the > >>> Bridge (even MyFaces) have impls which perform the logic for > >>> "ExternalContext" expected of their various specs. These are > >>> duplicated somewhat in the shale-tests. If it were moved over to > >>> faces, both the core-team and the bridge team would be able to > >>> maintain the test harnesses with the code they are writing. For > >>> instance, Mock the Bridge and Servlet API's and Mock the > >>> FacesContextFactory. It would, in turn, return an ExternalContext > >>> which (while being based off the myfaces or bridge impl) would also > >>> expose the setters needed to test thing. But ultimately, the > >>> underlying implementations would run under the covers. This would > >>> much easier reflect reality. > >>> > >>> That said, I was just bringing up the idea that I wouldn't argue > >>> against it. The Bridge (and some of the projects I'm doing in > >>> commons) need released versions of a portlet test harness and I > >>> wouldn't mind adding these test cases to Trinidad either. Whether > I > >>> pull them from Shale or MyFaces makes no real difference to me, but > >>> I could help maintain them better if they were in MyFaces -- for a > >>> current committer of shale I am not. :) > >>> > >> > >> Well, I'm not a MyFaces committer either. Ok, I'll bore you - I had > >> to work on Clay under Struts for 6 months submitting patches to the > >> code I contributed before I > >> was nominated to join. > >> Of course, that was then and this is now but I'd like to see Shale > >> grow as a community. > >> The reality is that the majority of Shale was Craig's work. I don't > >> think that anyone would > >> dispute that. David Geary also had a hand in the inception. That's > >> why I'm into the all or nothing versus the cafeteria plan. Shale > >> test is one of the nuggets. The annotation and remoting are also > >> being used as the foundation - point of discussion for JSF 2.0. > >> Shale controller + shale dialog is a simplified version of ADFc 11g. > >> I don't know... I think we all know how to work together amongst > >> apache communities. I'm sorta disappointed but at the same time it > >> makes sense. I remember Ted Husted > >> (someone else I have great respect for) saying open source is > >> sometimes like a jealous mistress. I think he might have told me > >> that just before the merger with webwork. > >> The interesting bit there is that struts 1.x code base still exists. > >> > >> Gary > >> > >> > >> > >>> Scott > >>>> 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 > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> > >>>> > >> > >> > > > >
