Allocate maintainers to the bootstrapper repositories

[thecodejunkie]

Nancy has the ability to use any IoC container with the application you write. The container you choose is not only used to resolve dependencies in your modules etc. but is also an intricate part Nancy.

We use a concept we called the bootstrapper that wraps the container and uses it to compose the actual framework itself. No container, no framework at runtime :)

Right now we ship bootstrapper implementations for TinyIoC (shipped in Nancy.dll), Autofac, Ninject, StructureMap, Unity and Windsor. We would love to continue to do so, but in order to do this we are going to need a bit of help from the community.

We are looking for Nancy users, that use the various bootstrappers that we ship and that has a good understanding of the underlying container that it uses. Essentially we are looking for people to work with us to make sure that the various bootstrapper implementations are as good as they possibly can be, both now and moving forward.

This would be done by having you work with us and get commit access to the bootstrapper repository that you want to help maintain. We are not necessarily looking for just a single contributor per bootstrapper, so if there are multiple people interested, then we are happy to let you work as a team.

You would, of course, work close with the core Nancy team because we need to be able to discuss changes to the bootstrapper architecture and the impact it would have on the bootstrapper implementations.

We have a test suite for the expected behaviour of a bootstrapper implementation (help verify lifetime scopes etc.) and we are looking into writing some documentation that explains the expectations and lifetime of a bootstrapper to help you understand the mechanics when helping us maintain the various implementations.

If you are interested in helping out, leave a comment along with the name(s) of the bootstrapper(s) that you would be interested in getting involved in and we'll take it from there.

Thanks!

PS. If you choose to participate then you are not signing up for a life-sentence (in case you want to)! We understand that peoples availability will change after time, just as it do for us in the Nancy team. We will also see about getting 2-3 contributors on each boostrapper and have you work as a team. That should help reduce the amount of effort required

Potential maintainers

• Autofac:
• Ninject:
• StructureMap:
• Unity:
• Windsor:

TODO

Let's build up a check-list of things needed to be done to make this happen. Share your thoughts, suggestions and ideas!

[davidwhitney]

Yeah, I use the Ninject bootstrapper in a couple of things - if you guys need a hand..

[thecodejunkie]

@davidwhitney Cool. Looking for 2 things. We need to draft a spec for how a bootstrapper needs to behave and then fix our implementations to make sure the use the containers in the best & correct way to satisfy these behaviours.

Second is to have people helps us maintain them.. make sure they're compatible with the latest container version .. work with us to update them if something changes in Nancy that needs to be reflected in the boostrappers etc.

[adamhathcock]

I can help as a heavy Unity user. I need it to work with Nancy and I'd do it on my own anyway :)

[asbjornu]

I'd love to help maintain the StructureMap bootstrapper, as per NancyFx/Nancy.Bootstrappers.StructureMap#20. I'm looking forward to reading the bootstrapper spec and for a extensive test suite to test the implementation against. 😃

[gregsochanik]

I'm also interested in giving a hand with the StructureMap bootstrapper, as we use heavily in house.

[davidwhitney]

@thecodejunkie do you have any draft-specs for other parts of the Nancy ecosystem at the moment (for stylistic inspiration)? Guess the obvious next steps are to start fleshing out a draft spec on a wiki page somewhere...

[BlueBasher]

I use Unity quit a lot at work right now and have some Nancy experience (not a real hardcore user though) so I could help with the unity bootstrapper if you'd like.

[thecodejunkie]

Added a "ps" to the main topic

[dvee81]

I actively use NancyFx/Nancy.Bootstrappers.Autofac. I would love to help maintain it.

[thecodejunkie]

Great! So far I see StructureMap, Unity and Autofac being mentioned. Need NInject and Windsor as well!

Give us a week or so to sort out the finer details, but please if you have any ideas/suggestions etc.. please keep adding them here. Do you have anything in particular that we should document to make this easier? The idea is to setup github teams (perhaps one per bootstrapper) and give people commit access to the repository. Publishing new version will (for the time being) be in our control

[grumpydev]

Documenting the expectations will be pretty straightforward, there's not much to it - one thing I'm toying with is either updating the existing base class, or creating a new one, for containers where they support a "request container", but prefer to have their request scoped dependencies registered at startup.

We will still need a "request startup" style method that can register things though, as there's always things that you can actually only register at request startup, but if we can minimise the amount of registrations done every requests for containers where that's a big perf hit than that would be useful.

[wilhen01]

We use the Ninject bootstrapper on all our Nancy-based projects in house (which we have quite a few of) so I'm interested in helping to maintain it. What sort of time commitments are we talking? My boss has given me leeway to spend an hour or two a week doing this around project work, if it's more than that I'm not sure I'll be able to commit to it.

[thecodejunkie]

@wilhen01 Hi. That sounds like it would be more than enough time. The initial pass would be to look over the current implementation and fine tune it (make sure we use it as efficiently as possible for performance reasons).. I don't see why that can't be an ongoing process. Every now and then we might change the bootstrapper contract, i.e by adding/changing something in the base class, that needs to be propagated out to our various bootstrappers. Usually the modifications are small, because, as you can see from the implementations there's not a lot of code in a bootstrapper

Hopefully we'll find at least one more (ideally two more?) Ninject users that could help co-maintain the Ninject bootstapper together with you.

[wilhen01]

@thecodejunkie Sounds good! Count me in :)

I'll have a glance at the existing implementation and familiarise myself with the code.

[davidwhitney]

@wilhen01 @thecodejunkie happy to help with Ninject stuff, spend years using Ninject in loads of stuff - and use that bootstrapper in one of my own products.

[thecodejunkie]

@davidwhitney oh sorry.. ofc. you where the first one to replied and I somehow missed that when I was summing up =/

[davidwhitney]

Hey, just following up on this - still interested in this initiative? Anyone kicked off work on a spec or is it up for grabs?

[asbjornu]

I'm still on board and got my sleeves rolled up for whenever the @thecodejunkie and @grumpydev decides it's time we get our hands dirty. 💪

[scott-xu]

@thecodejunkie I'm a collaborator of Ninject org and I'd like to take care of the Nancy's Ninject bootstrapper.

[scott-xu]

Actually I did submitted some PRs to that repo.

[thecodejunkie]

Hey guys.. sorry for the silence.. we've not dropped the ball on this. There's been busy times for a couple of weeks, leading up to people going on vacations and conferences. I'm back home next week and will pick this up again. If you don't hear back form me in a week, just ping me here again and I will be reminded! ;)

[danbarua]

I'm an ex-Windsor user, I started looking at other containers as I found the per-request-container implementation in the Windsor Bootstrapper just didn't work as expected. I vaguely remember some improvements being made to Windsor's child container implementation since the README was written 2 years ago so it may be worth revisiting. (I may be wrong on that.)

Does anyone still use Windsor on new projects or have we all moved on?

edit I'm talking out of my arse ^ ignore the above.

[asbjornu]

@thecodejunkie We're still waiting for a resolution on this. The most important thing for me isn't necessarily having official maintainer status, but rather a set of tests that the implementation needs to comply with. How far have you, @grumpydev et al gotten on this? Any progress since November 5th 2014? 😃

[grumpydev]

There are a set of tests around lifetimes etc, but unfortunately they aren't great and are a pain to implement - something could be done with a set of scenarios and the testing framework though I guess, although when scanning is involved it's hard to isolate unless we end up with a multitude of projects.

[asbjornu]

@grumpydev Great! What I'd love to see is a NuGet package called Nancy.Bootstrappers.Testing or something similar, where all the different assertions are placed and where each bootstrapper implementation can take care of fulfilling the requirements. This way, it's easy to continually update Nancy along with its bootstrapping requirements, which in the core of Nancy will be fulfilled by TinyIoC.

If you could start implementing such a package for the tests revolving around TinyIoC within the Nancy solution, we can work together on improving it and ensuring that Nancy's requirements are taken care of. Each container will of course have edge cases that the core test suite can't cater to, so each bootstrapper implementation will need its own set of tests on top of the common ones, but having a common test suite would take us a long way and give us a lot more robust and complete implementations than what we have today, I'm sure.

[jvandertil]

I can give a hand with the StructureMap bootstrapper :)

[asbjornu]

@thecodejunkie: Can you please elaborate on why this was closed?