Community Involvement and Project Status
We are currently on the 0.8 release which is the first community publication. The interface structure is fairly well set, but may be changing. My goal is to keep changes to the external interface to a minimum. I will be focusing on internal refinement leading
up to release which includes:
- Refactor: further refine the state change and event raising process. The process is almost too-well factored at this point, meaning that one excess layer is in place. This is non-impacting to the end-user of the library.
- Speed: moving mockery composition away from using IoC to compose at runtime. This was handy during development, but run-over-run reliance for composing the mockery itself is unnecessary.
- Test: Tests on the mockery itself were removed with an eye toward using mockery itself to run the tests, however testing the structure with itself is (1) confusing and (2) makes refactoring mockery itself more awkward.
- Samples: Create a better set of sample Mockery uses for showing real world uses.
- Documentation: Continue working on calling out the documentation
As Mockery progresses, the list of needs for the project will change. This page is dedicated to listing the areas where the community can contribute and point to resources to aid in building these components.
A. Support for an expanded range of IoC containers. These containers must have an associated
implementation to run. The current unimplemented list includes:
- Castle Windsor:http://www.castleproject.org/container/index.html
- Ninject 2.x (Ninject 1.x does not support the CommonServiceLocator AFAIK)
reference implementation for IoC support
is listed in the autofac implementation. This is a single file implementation by virtue of autofac capabiliities.
IoC Support Component Naming Convention
The IoC Support Components must implement an assembly. Because of the way Mockery is using MEF to locate an assembly at runtime, the name must follow the convention: