Re: Shale test status
On Mon, Oct 20, 2008 at 10:49 AM, Gary VanMatre [EMAIL PROTECTED] wrote: I'd rather see the Shale community grow this library and the Shale project. However, if the communities feel that the only way we can find volunteers to contribute to its ongoing growth (seems a bit snobbish) is to move to MyFaces, then so be it. +1. I'm not saying I'm dead set against a MyFaces merger. If that's the best thing for the Shale project, then let's go do it. But I would much rather see efforts to grow the Shale community, rather than take one node that has a lot of interest and move it somewhere else. I don't think we've really explored the options that involve keeping all of Shale here. As to Simon's argument that Shale Test is linked exclusively to JSF, I think that applies to the whole framework. We can't work towards a JSF 2 version of the other components without having a JSF 2 codebase to link to. So if Test is being held back by that dependency then so is the rest of the project. Greg
Re: Shale test status
Hi Greb, My problem isn't that Shale Test is linked to JSF, it's that MyFaces API is linked to Shale-Test (while not to any other module). The part of Shale-test we're using to test MyFaces isn't even linked to Shale other than for historical reason (no harm intended here, it's merely factual). If the base test classes don't get moved to MyFaces, then we're more or less condemning MyFaces API to wait for RI to be released so that Shale-test can depend on it to be updated to 2.0 API, or forcing MyFaces API to redevelop the base test classes, or release versions without running unit tests on the API. If you see any other way, please share it, because that would fix the issue here. Regards, ~ Simon On Wed, Oct 22, 2008 at 10:48 AM, Greg Reddin [EMAIL PROTECTED] wrote: On Mon, Oct 20, 2008 at 10:49 AM, Gary VanMatre [EMAIL PROTECTED] wrote: I'd rather see the Shale community grow this library and the Shale project. However, if the communities feel that the only way we can find volunteers to contribute to its ongoing growth (seems a bit snobbish) is to move to MyFaces, then so be it. +1. I'm not saying I'm dead set against a MyFaces merger. If that's the best thing for the Shale project, then let's go do it. But I would much rather see efforts to grow the Shale community, rather than take one node that has a lot of interest and move it somewhere else. I don't think we've really explored the options that involve keeping all of Shale here. As to Simon's argument that Shale Test is linked exclusively to JSF, I think that applies to the whole framework. We can't work towards a JSF 2 version of the other components without having a JSF 2 codebase to link to. So if Test is being held back by that dependency then so is the rest of the project. Greg
Re: Shale test status
On Wed, Oct 22, 2008 at 10:45 AM, Simon Lessard [EMAIL PROTECTED] wrote: If the base test classes don't get moved to MyFaces, then we're more or less condemning MyFaces API to wait for RI to be released so that Shale-test can depend on it to be updated to 2.0 API, or forcing MyFaces API to redevelop the base test classes, or release versions without running unit tests on the API. I'm trying to make sure I understand the issue so please bear with me. If shale-test depends on 2.0 RI and 2.0 RI is not yet released, then shale-test cannot be upgraded, no matter where it lives, correct? If so, then a JSF 2.0 development branch could be created (either in Shale or MyFaces) so work can be done on a 2.0 version of shale-test. That development branch could depend on a snapshot of JSF 2.0 (whether the snapshot is MyFaces or something else) while it is in development. Once there is a release of the 2.0 API anywhere, then shale-test can be released, then MyFaces, once passing all tests, can be released. Have I identified the situation correctly? If so, then I can see how it would be more convenient for the MyFaces community for shale-test to live there. But it could further isolate the Shale community by moving a vibrant part of Shale out. I would rather see more cooperation occur. If we get enough folks to commit to Shale (even just test) then Shale releases don't have to be such a backlog. I don't think MyFaces are the only people relying on or benefitting from shale-test so it might not be a good idea to tie shale-test releases into MyFaces. Greg
Re: Shale test status
Hi Greg, See inline. ~ Simon On Wed, Oct 22, 2008 at 12:19 PM, Greg Reddin [EMAIL PROTECTED] wrote: On Wed, Oct 22, 2008 at 10:45 AM, Simon Lessard [EMAIL PROTECTED] wrote: If the base test classes don't get moved to MyFaces, then we're more or less condemning MyFaces API to wait for RI to be released so that Shale-test can depend on it to be updated to 2.0 API, or forcing MyFaces API to redevelop the base test classes, or release versions without running unit tests on the API. I'm trying to make sure I understand the issue so please bear with me. If shale-test depends on 2.0 RI and 2.0 RI is not yet released, then shale-test cannot be upgraded, no matter where it lives, correct? Correct. If so, then a JSF 2.0 development branch could be created (either in Shale or MyFaces) so work can be done on a 2.0 version of shale-test. That development branch could depend on a snapshot of JSF 2.0 (whether the snapshot is MyFaces or something else) while it is in development. Yes, but you're assuming that there is a -SNAPHOT version and that's the root of the problem. We cannot even create snapshot version as Continuum is going to whine about test not passing since we depend on shale-test which itself isn't ready for 2.0 since it is waiting for API 2.0 to exist. So, to get a -SNAPSHOT somewhere in the Maven repository we have to either do an alpha release of the API disabling unit tests, or create our own base test classes and no longer depend on Shale-Test (we would more or less recreate Shale-test in a way). If we cannot do either of those options, then we can't release or even JUnit test the new code until JSF RI is released so that Shale-test depends on it, so that in turn MyFaces API can build have an official release and finally so that Shale-Test 2.0 can use MyFaces API 2.0 as a dependency rather than RI. Once there is a release of the 2.0 API anywhere, then shale-test can be released, then MyFaces, once passing all tests, can be released. Have I identified the situation correctly? Yup, exactly, but the anywhere here means RI since MyFaces depends on Shale-test. If so, then I can see how it would be more convenient for the MyFaces community for shale-test to live there. But it could further isolate the Shale community by moving a vibrant part of Shale out. I would rather see more cooperation occur. If we get enough folks to commit to Shale (even just test) then Shale releases don't have to be such a backlog. I don't know the whole Shale test framework, however would it be possible or conceivable to not move it completely, simply moving the core classes that are inherently linked to the API (FacesContext, Application and such) and keep everything else under shale test umbrella? Or is the whole framework composed of such core classes? I don't think MyFaces are the only people relying on or benefitting from shale-test so it might not be a good idea to tie shale-test releases into MyFaces. Of course not, we would have to work out something on that matter so that everyones using shale-test keep fully compatibility without even changing their pom, this could be achieved (in case it was moved completely or in part to MyFaces) by having shale-test depend on myfaces-api's test-jar for example. Greg
Re: Shale test status
-- Original message -- From: Matthias Wessendorf [EMAIL PROTECTED] On Sun, Oct 19, 2008 at 11:34 PM, Kito Mann [EMAIL PROTECTED] wrote: Hey Simon, I don't think this has been officially decided. Check out the recent thread on this topic. However, if you're going to be making changes for JSF 2, this might be a good time to move it over to MyFaces. I don't think Gary agrees, though :-). I am also +1 on the move ;-) Humm, well, I don't understand why shale test is excluded from the normal community protocol. For goodness sakes, what if every project felt it necessary to pull commons digester into their own just because they use it. I'd rather see the Shale community grow this library and the Shale project. However, if the communities feel that the only way we can find volunteers to contribute to its ongoing growth (seems a bit snobbish) is to move to MyFaces, then so be it. On Sun, Oct 19, 2008 at 1:04 PM, Simon Lessard [EMAIL PROTECTED] wrote: Hi, I'm working on implementing JSF 2.0 for MyFaces and as you may know, MyFaces uses Shale test for its unit testing. However, the new API and contracts involved in JSF 2.0 make it so that current test fails with an UnsupportedOperationException since some test implementations don't override the new method that weren't marked abstract for binary code compatibility. Anyway, my point is, what is the current status and roadmap for shale-test framework? Should JSF 2.0 changes be applied to it or will it be integrated in in part or completely in MyFaces with time? Thanks, ~ Simon -- Kito D. Mann -- Author, JavaServer Faces in Action http://twitter.com/kito99 http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info +1 203-404-4848 x3 * Sign up for the JSF Central newsletter! http://oi.vresp.com/?fid=ac048d0e17 * -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: Shale test status
Hi Craig, The difference is the test framework, or at least a part of it, is linked exclusively to JSF. More practically, what this mean is that we have a cyclic reference between the API and the test. For example, the test framework depends on FacesContext. However, since we like Shale test framework, we also test the API with the framework, now this is a chicken or egg issue. This is even more problematic in case of JSF 2.0 since there's no released API to depend on, so I cannot modify the framework even by depending on SNAPSHOT pseudo release since I cannot build those with unit test sicne those unit tests aren't 2.0 compliant. I guess it would be possible to create a pseudo release skipping unit tests, but it seems against the standard quality reputation of Apache to do so. So, personally, I would have liked to put the JSF part of the framework in MyFaces test project and release the test jar at the same time as the core so that people can still use it as a dependency. Regards, ~ Simon On Mon, Oct 20, 2008 at 11:49 AM, Gary VanMatre [EMAIL PROTECTED]wrote: -- Original message -- From: Matthias Wessendorf [EMAIL PROTECTED] On Sun, Oct 19, 2008 at 11:34 PM, Kito Mann [EMAIL PROTECTED] wrote: Hey Simon, I don't think this has been officially decided. Check out the recent thread on this topic. However, if you're going to be making changes for JSF 2, this might be a good time to move it over to MyFaces. I don't think Gary agrees, though :-). I am also +1 on the move ;-) Humm, well, I don't understand why shale test is excluded from the normal community protocol. For goodness sakes, what if every project felt it necessary to pull commons digester into their own just because they use it. I'd rather see the Shale community grow this library and the Shale project. However, if the communities feel that the only way we can find volunteers to contribute to its ongoing growth (seems a bit snobbish) is to move to MyFaces, then so be it. On Sun, Oct 19, 2008 at 1:04 PM, Simon Lessard [EMAIL PROTECTED] wrote: Hi, I'm working on implementing JSF 2.0 for MyFaces and as you may know, MyFaces uses Shale test for its unit testing. However, the new API and contracts involved in JSF 2.0 make it so that current test fails with an UnsupportedOperationException since some test implementations don't override the new method that weren't marked abstract for binary code compatibility. Anyway, my point is, what is the current status and roadmap for shale-test framework? Should JSF 2.0 changes be applied to it or will it be integrated in in part or completely in MyFaces with time? Thanks, ~ Simon -- Kito D. Mann -- Author, JavaServer Faces in Action http://twitter.com/kito99 http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info +1 203-404-4848 x3 * Sign up for the JSF Central newsletter! http://oi.vresp.com/?fid=ac048d0e17 * -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: Shale test status
Oups, I meant Gary sorry... Dunno why I confused you with Craig... On Mon, Oct 20, 2008 at 12:17 PM, Simon Lessard [EMAIL PROTECTED]wrote: Hi Craig, The difference is the test framework, or at least a part of it, is linked exclusively to JSF. More practically, what this mean is that we have a cyclic reference between the API and the test. For example, the test framework depends on FacesContext. However, since we like Shale test framework, we also test the API with the framework, now this is a chicken or egg issue. This is even more problematic in case of JSF 2.0 since there's no released API to depend on, so I cannot modify the framework even by depending on SNAPSHOT pseudo release since I cannot build those with unit test sicne those unit tests aren't 2.0 compliant. I guess it would be possible to create a pseudo release skipping unit tests, but it seems against the standard quality reputation of Apache to do so. So, personally, I would have liked to put the JSF part of the framework in MyFaces test project and release the test jar at the same time as the core so that people can still use it as a dependency. Regards, ~ Simon On Mon, Oct 20, 2008 at 11:49 AM, Gary VanMatre [EMAIL PROTECTED]wrote: -- Original message -- From: Matthias Wessendorf [EMAIL PROTECTED] On Sun, Oct 19, 2008 at 11:34 PM, Kito Mann [EMAIL PROTECTED] wrote: Hey Simon, I don't think this has been officially decided. Check out the recent thread on this topic. However, if you're going to be making changes for JSF 2, this might be a good time to move it over to MyFaces. I don't think Gary agrees, though :-). I am also +1 on the move ;-) Humm, well, I don't understand why shale test is excluded from the normal community protocol. For goodness sakes, what if every project felt it necessary to pull commons digester into their own just because they use it. I'd rather see the Shale community grow this library and the Shale project. However, if the communities feel that the only way we can find volunteers to contribute to its ongoing growth (seems a bit snobbish) is to move to MyFaces, then so be it. On Sun, Oct 19, 2008 at 1:04 PM, Simon Lessard [EMAIL PROTECTED] wrote: Hi, I'm working on implementing JSF 2.0 for MyFaces and as you may know, MyFaces uses Shale test for its unit testing. However, the new API and contracts involved in JSF 2.0 make it so that current test fails with an UnsupportedOperationException since some test implementations don't override the new method that weren't marked abstract for binary code compatibility. Anyway, my point is, what is the current status and roadmap for shale-test framework? Should JSF 2.0 changes be applied to it or will it be integrated in in part or completely in MyFaces with time? Thanks, ~ Simon -- Kito D. Mann -- Author, JavaServer Faces in Action http://twitter.com/kito99 http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info +1 203-404-4848 x3 * Sign up for the JSF Central newsletter! http://oi.vresp.com/?fid=ac048d0e17 * -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
