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
>

Reply via email to