Can we have a Facilities repository?

[ghost]

Currently Castle.Windsor has all it's facilities baked into to the same solution/repository. Breaking changes to the facilities mean major version increments for the Castle.Windsor NuGet itself although nothing was broken or changed in this project. Would it be possible to create a Facilities repository so we can semver them separately?

I am referring to #330 where a breaking change was introduced to Castle.Facilities.Logging. This would also make the work on #283 happen in isolation before we move up and finally remove System.Web from Castle.Windsor.

[jonorossi]

When we moved to git from subversion a decade or so again we did split up Windsor more and it turned out really bad, really painful.

Just looking through the facilities we've got I can't see the desire to split it out. Maybe the WCF facility but if we split it out it'll likely not get maintained at all.

• Startable (in Castle.Windsor.dll)
  • Part of the built-in standard facilities
• TypedFactory (in Castle.Windsor.dll)
  • Part of the built-in standard facilities
• Castle.Facilities.EventWiring
  • Mature, but I don't think this is used very much
• Castle.Facilities.FactorySupport
  • In maintenance mode, prefer UsingFactoryMethod
• Castle.Facilities.Logging
  • Will become even smaller after Deprecate Logging Facility's LoggerImplementation enum #336
• Castle.Facilities.Synchronize
  • Mature, but I don't think is used very much
• Castle.Facilities.WcfIntegration
  • Mature, used by many but I can't imagine people using it for new projects

Would it be possible to create a Facilities repository so we can semver them separately?

I'm not sure this is a good idea, projects that have done this become very painful to work out what version of each package to use. Maybe a new facility could be done seperate but I think anything you expect most users to actually use should just be versioned in lock step.

This would also make the work on #283 happen in isolation before we move up and finally remove System.Web from Castle.Windsor.

Sorry, I need more justification/convincing that this would improve things because I don't see it.

[ghost]

You are right. Given the current state of play and the things we have on the Windsor board probably not. My feeling about what is there currently:

• Startable (in Castle.Windsor.dll)
  • Found this peculiar, could never get to stop to work. Roll your own is much easier. Delete?
• TypedFactory (in Castle.Windsor.dll)
  • Let's keep it.
• Castle.Facilities.EventWiring
  • Never used it at all. Delete?
• Castle.Facilities.FactorySupport
  • Agreed, UsingFactoryMethod is probably the best thing. Delete?
• Castle.Facilities.Logging
  • It is awesome again.
• Castle.Facilities.Synchronize
  • Honestly don't care about this one. Delete?
• Castle.Facilities.WcfIntegration
  • This will be a thing with netcore considering connected services, and eventually ... once they migrate it. I personally don't use it but there is future here.

My feeling on stuff we need to bring back/add.

• Active Record (would love to hear your thoughts on this, I know nothing).
• NHibernate (this went walkies, still love this would be great to get this back).
• EntityFramework (hate it but love it at the same time).
• RabbitMQ (but using EasyNetQ, sorry Hammet! Derek Greer also had a go at this but Mike won IMHO).
• CacheManager (used this for scale safe caching in the cloud)
• ElasticSearch.NET (exposing this in Castle would be grand, good team)
• Redis (would be good if we could get something going here)
• CouchDB (this is also cool, used it once)
• MongoDB (like this stuff too, used it a fair bit)

Just spit balling here. Does this really need to be lock stepped with an IoC container?

If you still disagree because we are focused on the now, I will happily close this issue. I am thinking future. Even though #330 was not taken, I am OK with that, many benefits by not doing it that way(which I agreed with) but what I did learn, was that just 2 extra projects completely crippled the Windsor build in terms of speed. NuGet restore time is the real killer here.

A no for the now is a no, and I am prepared to respect that.

[ghost]

Closing this after reading castleproject/Core#292. The tone does not come across well and I get that lock stepping makes things easier. Let's just pass on this for now.

[hconceicao]

The Startable is extensivenly used, including other facilities out there. The Event Wiring never got traction, afaik. It's there cause it don't depends in anything else than .net runtime.

Even in the "golden years", with a bunch more contributors than today, was very hard to maintain external facilities in sync with the main core/windsor releases. It became specially hard when it envolves a third part fx/lib that have a release cycle of its own.

Moving out to another repo will be a death sentence, imo. Now, if it's a good or bad thing to have some of them killed/sunsetted it's up to you guys to decide ;)

[ghost]

@hconceicao - Thanks for your input.

[jonorossi]

The Startable is extensivenly used, including other facilities out there. The Event Wiring never got traction, afaik. It's there cause it don't depends in anything else than .net runtime.

I agree, I've used Startable many times successfully. Never used Event Wiring, to me it seemed limited and configuration heavy.

Now, if it's a good or bad thing to have some of them killed/sunsetted it's up to you guys to decide ;)

Thanks for jumping in, I agree that some should be deprecated. Windsor is unfortunately seen as the big container because it does bring along quite a bit of baggage.

My feeling on stuff we need to bring back/add.

Active Record (would love to hear your thoughts on this, I know nothing).
NHibernate (this went walkies, still love this would be great to get this back).
EntityFramework (hate it but love it at the same time).
RabbitMQ (but using EasyNetQ, sorry Hammet! Derek Greer also had a go at this but Mike won IMHO).
CacheManager (used this for scale safe caching in the cloud)
ElasticSearch.NET (exposing this in Castle would be grand, good team)
Redis (would be good if we could get something going here)
CouchDB (this is also cool, used it once)
MongoDB (like this stuff too, used it a fair bit)

Castle ActiveRecord is dead (unless a maintainer wants to revive it); few seem to care about NHibernate for new projects; ...; we had a heap of facilities for all sorts of things in the past but most don't get maintained. For many cases it is trivial for someone to write their own facility which is a positive to Windsor's capabilities.

Just spit balling here. Does this really need to be lock stepped with an IoC container?

@fir3pho3nixx It doesn't, but I'm not seeing how the benefits outweigh the disadvantages. What I'm mostly looking at it the current facilities and the only one that I could see some benefit of being moved to its own repository and versioned by itself is the WCF facility, the rest belong to Windsor. For example, versioning the logging facility separately to Windsor.dll feels to me like the versioning problems with the corefx, i.e. using System.Runtime 4.3.0 and System.Collections 4.0.0. Microsoft realised pretty quickly this doesn't work well and so created the NETStandard.Library virtual package.

I'd be open to having new facilities in their own repo with their own versioning, however @hconceicao is right that if there is no one actively maintaining those projects they'll die by staleness, however that does give us the easy option of then moving them to the deprecated GitHub org where they can stay until a new maintainer comes on board.

I've created #339 for the further discussion of existing facilities, any new facilities you'd like to create just open an issue and we'll make a decision where they can go.

[ghost]

@jonorossi - Cool, let's move the discussion over there.