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@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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev




--
blog: http://in.relation.to/Bloggers/Jay
_______________________________________________
seam-dev mailing list
seam-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev

--
http://in.relation.to/Bloggers/Pete




--
blog: http://in.relation.to/Bloggers/Jay