I fear that the real trouble here is actually considerably *worse* than just
the ByteCode Provider choice and opens up combinatorial explosion when you
consider all of the other variables (e.g., DB dialects, 2nd-level Cache
Providers, etc.) that would potentially need to be combined into packages.

As an example, if we were to provide an NH Package that 'defaulted' to
Castle's ByteCode provider and then someone wanted to add the LinFu ByteCode
provider, AFAIK with NuGet they would have to 'manually' remove the
now-extraneous reference to Castle from their solution (e.g., the NuGet
package for the LinFu ByteCode Provider cannot 'uninstall' all or part of
the NH+Castle package...and I'm not sure a user would want PackageA to be
able to uninstall parts of PackageB anyway as a design philosophy anyway
<g>).  So (IMO) we would end up creating a NH.Core package *anyway* in order
to support the 'compositional' nature of NH's binary dependencies.

Given all of this, I don't see much choice but to do NHibernate.Core which
can have hard dependencies on non-variable packages (like log4net) and then
have other packages for all of the other variable items that NH supports,
each of them stating a dependency on the NH.Core package.

(unless, of course, there's some NuGet 'trick' that I may be overlooking --
I'm the farthest thing from a NuGet expert by any stretch of the imagination
though I have been following its evolution quite closely in re: its general
feature set)

There are a number of these kinds of OSS projects (where pick-and-choose
your combination of other 'addons' is a prevalent adoption meme) and I don't
see great support for this kind of thing (presently) in NuGet b/c the
'package' is the atomic unit of adding/removing dependencies (again, unless
I'm overlooking some aspect of NuGet that I may simply be unaware of).

Steve Bohlen
[email protected]
http://blog.unhandled-exceptions.com
http://twitter.com/sbohlen


On Mon, Jan 17, 2011 at 11:53 AM, Patrick Earl <[email protected]> wrote:

> I've been thinking about creating a NuGet package for NHibernate and
> I'm curious if anyone's had any thoughts about this area?
>
> As far as I can see, the biggest decision is how to package the
> different pieces (ex. Castle.ByteCode, Log4Net, etc.).  I've been
> playing with a couple ideas in my head:
>
> 1.  Have an NHibernate.Core package that includes on the basics, then
> have things like NHibernate.Castle, NHibernate.LinFu,
> NHibernate.Log4Net that add on the extra pieces.
> 2.  Have an NHibernate package that includes all the bytecode
> providers and configures Castle by default.
>
> Thoughts?
>
>        Patrick Earl
>

Reply via email to