agreed - as long as RF can grab the individual module from seam ( and not
pull in others ) it should be fine. The concern would be too many cross
project dependencies making working with just one of the projects tricky (
and harder to productize ).
On Tue, May 5, 2009 at 8:33 AM, Pete Muir <pmuir(a)redhat.com> wrote:
Can we share these mocks like we discussed for graph validation - RF
imports the module from the "Seam" space - but the Seam module doesn't
depend on other Seam code?
On 30 Apr 2009, at 15:13, Jay Balunas wrote:
You may also want to check out
>
http://www.jboss.org/community/wiki/TestDrivenJSFDevelopment
>
> Alex Smirnov has been working on this to help with RF 4.0 development.
> Perhaps we can collaborate.
>
> On Wed, Apr 29, 2009 at 11:10 AM, Dan Allen <dan.j.allen(a)gmail.com>
> wrote:
> It's hard to believe that for as long as JSF has been around, the only
> decent repository of mocks for the JSF API comes not from the
> implementation, but rather from all but dead and irrelevant project at
> Apache (Shale). Of course, Seam 2 forged it's own path and has a healthy set
> of mocks, although still somewhat incomplete and vagrant. In the Seam 3
> spirit of modularity, I would like to migrate the Seam 2 mocks into a mock
> module in Seam 3 that provides mock/stub object for various Java EE APIs. I
> plan to categorize them by spec under the org.jboss.seam.mock folder
>
> JSF - org.jboss.seam.mock.faces
> Servlet - org.jboss.seam.mock.servlet
> etc
>
> This module should not depend on any other module so that it is easy to
> reuse, perhaps even outside of the Seam framework. Perhaps seam-mock can end
> up replacing Shale test. Who knows. We'll just let it play out. Please
> contribute your ideas/use cases!
>
>
http://anonsvn.jboss.org/repos/seam/modules/trunk/mock/
>
> As for the functionality, my feeling is that the mocks should be
> functional as long as each class behaves like a bean. That means it
> shouldn't parse XML documents or make similar assumptions. But they should
> be easy enough to extend that perhaps you can add that functionality in your
> test case or we can think about providing an additional subclass or helper
> if the need is common (perhaps parsing an web.xml document).
>
> -Dan
>
> --
> Dan Allen
> Senior Software Engineer, Red Hat | Author of Seam in Action
>
>
http://mojavelinux.com
>
http://mojavelinux.com/seaminaction
>
http://in.relation.to/Bloggers/Dan
>
> NOTE: While I make a strong effort to keep up with my email on a daily
> basis, personal or other work matters can sometimes keep me away
> from my email. If you contact me, but don't hear back for more than a
> week,
> it is very likely that I am excessively backlogged or the message was
> caught in the spam filters. Please don't hesitate to resend a message if
> you feel that it did not reach my attention.
>
> _______________________________________________
> seam-dev mailing list
> seam-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/seam-dev
>
>
>
>
> --
> blog:
http://in.relation.to/Bloggers/Jay
> _______________________________________________
> seam-dev mailing list
> seam-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/seam-dev
>
--
Pete Muir
http://www.seamframework.org
http://in.relation.to/Bloggers/Pete