myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <craig...@apache.org>
Subject Re: [maven] Weird dependency problem
Date Thu, 12 Jan 2006 17:09:23 GMT
On 1/12/06, Sean Schofield <sean.schofield@gmail.com> wrote:
>
> Temproarily I have fixed this by copying the MockFacesContext and
> making it a inner class called MockFacesContext2.  We should probably
> come up with something better long term though.
>
> Maybe we could use the Shale Test Framework.  Its already got a lot of
> mock objects for JSF.  I haven't looked at it too carefully but I
> think we should consider it.  Since its only for unit tests I don't
> see the problem of having a dependency on Shale.  Although the unit
> tests probably depend on myfaces-api so maybe we run into the same
> issue?


The Shale test framework depends only on the servlet, JSP, and JSF apis ...
it has no dependencies on the rest of Shale.  It is packaged in a manner
where the test framework could be released separately from an overall Shale
release, if that becomes appropriate.

The current framework implements everything I needed to test the Shale
framework components themselves, plus the example applications.  There are
still quite a few UnsupportedOperationException exceptions, but the intent
is to fill in the implementations of those methods as they become needed.
Other users are starting to provide patches for this kind of thing as well.

Sean


Craig


On 1/12/06, Sean Schofield <sean.schofield@gmail.com> wrote:
> > I'm trying to run Bruno's patches which fix the unit tests (nice work
> > by the way!)  Anyways, one of the tests in commons requires
> > MockFacesContext which is in api.  The issue is that it can't find
> > MockFacesContext even with the commons-api dependency.  This is
> > because the mock stuff is in the *test* resources and so is not made
> > available to other modules with a dependency on api.
> >
> > The only solution I can think of is to move the MockFacesContext to
> > commons but that introduces a circular dependency issue.  We could
> > have two copies of the mock object I suppose ... (or one of them could
> > be a private inner class.)
> >
> > Ideas?
> >
> > Sean
> >
>

Mime
View raw message