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
>

Reply via email to