Shale test status

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

Matthias Wessendorf

2008-10-20 07:09:32 UTC

Post by Kito Mann
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 ;-)

Post by Kito Mann
On Sun, Oct 19, 2008 at 1:04 PM, Simon Lessard

--
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

Paul Spencer

2008-10-20 16:09:09 UTC

I tend to agree with Gary on this one. We need to grow the community.

My other objection to moving Shale is based around it's implementation
independents. By maintaining Shale's independence, we minimize the risk
of including a MyFaces implementation dependency, like myfaces-common,
into Shale-test. Yes, I know may of Shale's committers are MyFaces
committers.

Going forward, I would like to see Shale's sub-projects have their own
release cycle, but this discussion should be held in a different thread.

Paul Spencer

Post by Kito Mann
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.

Post by Kito Mann
On Sun, Oct 19, 2008 at 1:04 PM, Simon Lessard

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
http://twitter.com/mwessendorf

Gary VanMatre

2008-10-20 15:49:10 UTC

-------------- Original message ----------------------

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.

Post by Kito Mann
On Sun, Oct 19, 2008 at 1:04 PM, Simon Lessard

--
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

Simon Lessard

2008-10-20 16:17:51 UTC

Oups, I meant Gary sorry... Dunno why I confused you with Craig...

On Mon, Oct 20, 2008 at 12:17 PM, Simon Lessard

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

Post by Gary VanMatre
-------------- Original message ----------------------

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.

Post by Kito Mann
On Sun, Oct 19, 2008 at 1:04 PM, Simon Lessard

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

Post by Kito Mann
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

Post by Matthias Wessendorf
*
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

Simon Lessard

2008-10-20 16:17:15 UTC

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

Post by Gary VanMatre
-------------- Original message ----------------------

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.

Post by Kito Mann
On Sun, Oct 19, 2008 at 1:04 PM, Simon Lessard

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

Post by Kito Mann
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

Post by Matthias Wessendorf
*
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

Greg Reddin

2008-10-22 14:48:49 UTC

Post by Gary VanMatre
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

Simon Lessard

2008-10-22 15:45:07 UTC

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

Post by Gary VanMatre

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

Greg Reddin

2008-10-22 16:19:29 UTC

On Wed, Oct 22, 2008 at 10:45 AM, Simon Lessard

Post by Simon Lessard
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

Simon Lessard

2008-10-22 16:41:06 UTC