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
