Re: shale-test location (was RE: JSF 2.0 component set)
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 -
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? Scott 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
RE: shale-test location (was RE: JSF 2.0 component set)
-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 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. I don't see why you still can't use the internals of these projects, though. Either way, it increases the number of dependencies for shale-test. 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. :) Fair enough. 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
RE: shale-test location (was RE: JSF 2.0 component set)
-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
RE: shale-test location (was RE: JSF 2.0 component set)
-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
Re: shale-test location (was RE: JSF 2.0 component set)
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 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
Re: shale-test location (was RE: JSF 2.0 component set)
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. :) 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
Re: shale-test location (was RE: JSF 2.0 component set)
Yeah, Craig was doing that just before one of the apache conferences - the one in Austin. We had a co-presentation. He was the primary and instead of putting together the slides, he was working on the 1.2 mock objects. Scott, you know that I'm *not* the kind of guy that is good with public speaking. For Craig, it was just another 20-minute task that he did the night before :--) Gary -- Original message -- From: Scott O'Bryan [EMAIL PROTECTED] 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 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
Re: shale-test location (was RE: JSF 2.0 component set)
-- 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,
