The intent was that Nhibernate.Core would be available for other package authors to reference in cases where they wanted fine-grained control over the 'composition' of their packages.
The canonical example I had in mind when thinking this scenario out was that of Castle's ActiveRecord. It would (conceivably) be possible for the Castle ActiveRecord package to depend directly on Nhibernate.Castle (or, if Castle is to be the 'default', then on just the 'Nhibernate' package). But if the Castle.ActiveRecord package were to take this dependency in this manner then they would be at the mercy of the version of Castle that is specified in OUR packages rather than being able to state their version requirements for themselves. so... Castle.ActiveRecord --> Castle.Nhibernate ...or... Castle.ActiveRecord --> Nhibernate ...would force them to 'accept' the version constraints for Castle.Core that *we* define in the NH packages. But... Castle.ActiveRecord --> Nhibernate.Core --> Castle.Core ...would permit them to state their dependency on NH with whatever version constraints they wanted to enforce in their own packages. Its possible that this scenario is just an edge case and I (honestly) have trouble suggesting another use-case than just Castle.ActiveRecord so maybe this is over-thinking the problem and introducing unnecessary complexity. On the other hand, I wonder if its the case that a hypothetical future Nhibernate.Caches.MemCacheD package needs a dependency on 'Nhibernate' (with the default proxyfactoryfactory) rather than just on Nhibernate.Core. Maybe you're right that the dependency for *all* nhcontrib-style packages would be best-stated in terms of nh-with-the-default-proxy, but if so then suppose I've done the following: 1. added Nhibernate.Linfu package b/c I *know* that's what I want 2. add the Nhibernate.Caches.MemCacheD package b/c I want to use 2nd level caching When I get to step #2, this will (needlessly) bring in Nhibernate (with default proxyproxyfactory) which in turn (as suggested earlier) will probably 'pass-thru' to bring in the Nhibernate.Castle package unnecessarily. AFAIK NuGet doesn't let you state dependencies as "at least one of the following must be present: Nhibernate.Castle, Nhibernate.LinFu, or Nhibernate.Spring..." (which is sort of how I would think it would be best for the nhcontrib-style packages to state their dependencies). What do you (and others) think is the best way to address this --? If we think it best for these to take dependencies on just 'Nhiberate' (w. default proxyproxyfactory) and we consider the Castle.ActiveRecord scenario to be an unsupportable edge case then maybe Nhibernate.Core *can* just go away.... Steve Bohlen [email protected] http://blog.unhandled-exceptions.com http://twitter.com/sbohlen On Mon, Mar 14, 2011 at 9:45 AM, Fabio Maulo <[email protected]> wrote: > Which is the sense NHibernate.Core, that should be the only one referenced > by frameworks depending on NH as NHV, NHSR, NHSP, NHE, NHCH, ConfORM), if NH > has an embedded dynamic-proxy system ? > > On Sun, Mar 13, 2011 at 6:31 PM, Stephen Bohlen <[email protected]> wrote: > >> As discussed elsewhere, Fabio (with some periodic input from myself) has >> been working to define NuGet packaging structures for NH3.x. >> >> As presently designed, the packaging structure for NH3.x looks like this >> (*generalized* so you get the idea; this is NOT exactly their full contents, >> but an abstract of how they are structured): >> >> ******** >> Package: NHibernate >> Semantic Contents: the nhibernate.dll assembly >> Dependencies: none >> ******** >> Package: NHibernate.Castle >> Semantic Contents: the ProxyFactoryFactory for Castle >> Dependencies: "NHibernate", <the Castle dynamic proxy assembly(ies)> >> ******** >> Package: NHibernate.LinFu >> Semantic Contents: the ProxyFactoryFactory for LinFu >> Dependencies: "NHibernate", <the LinFu dynamic proxy assembly(ies)> >> ******** >> Package: NHibernate.Spring >> Semantic Contents: the ProxyFactoryFactory for Spring.NET >> Dependencies: "NHibernate", <the Spring.NET dynamic proxy assembly(ies)> >> ******** >> >> Essentially, the "Nhibernate" package is 'bare' NH3.x with no >> ProxyFactoryFactory included and is intended only to be used as a 'reference >> package' for other packages (either created by NH team or otherwise) that >> for any particular reason do not want/need any of the specific >> ProxyFactoryFactory packages. >> >> The design intent here was that the 'typical' NH adopter would select one >> of the "Nhibernate.<proxyfactory>" packages that was to their liking. >> >> While this approach would seem to achieve this goal, its not without its >> limitations, as many have pointed out in various venues: >> >> - naming the 'bare' (proxy-less) package simply "NHibernate" is >> potentially confusing as its 'generic' name increases the likelihood that >> it >> will be selected by a high percentage of adopters unaware of the nuances >> of >> needing to select one of the higher-level (ProxyFactoryFactory) packages; >> this is likely to result in people adding this package in error and not >> ending up with a complete, fully-functional NH-based solution (and no >> clear >> indication to them as to why this is the case) >> - this approach requires the NH adopter to make a conscious decision >> when adding their desired package re: which ProxyFactoryFactory >> infrastructure they want to use; it has been suggested elsewhere that this >> represents an "implementation detail" within NH that the vast majority of >> NH >> adopters should not want/need to concern themselves with >> >> From the beginning of the introduction of the ProxyFactoryFactory, NH has >> refrained from making any one of the ProxyFactoryFactory implementations >> 'the default' and has treated all proxy engines equally. If we choose to >> shield the user from this implementation detail in our packaging by >> providing a 'default' for the 'standard' NH package, then we need to decide >> which ProxyFactoryFactory implementation will be that default. >> >> At first glance, the logical choice seems to be the LinFu proxy engine >> since its the the lightest-weight of those available (because its >> narrowly-focused on being 'only' a dynamic proxy engine and is not also >> trying to be an IoC container at the same time). Because of its more narrow >> scope/feature set, its also probably the least-likely to version-collide >> with other assemblies in users' projects. >> >> However, since the Castle dynamic proxy engine is presently the only one >> of the several to support the 'full' set of NH features (e.g., lazy >> properties), this probably makes it the best choice as the 'default' >> ProxyFactoryFactory (at least until features like lazy-properties can be >> supported by the LinFu dynamic proxy). >> >> So I am proposing the following revision to the present packaging approach >> and asking for comment/feedback on this re-design: >> >> ******** >> Package: "NHibernate.Core" >> Semantic Contents: the nhibernate.dll assembly >> Dependencies: none >> ******** >> Package: NHibernate >> Semantic Contents: the ProxyFactoryFactory for Castle >> Dependencies: "NHibernate.Core", <the Castle dynamic proxy assembly(ies)> >> ******** >> Package: NHibernate.Castle >> Semantic Contents: the ProxyFactoryFactory for Castle >> Dependencies: "NHibernate", <the Castle dynamic proxy assembly(ies)> >> ******** >> Package: NHibernate.LinFu >> Semantic Contents: the ProxyFactoryFactory for LinFu >> Dependencies: "NHibernate", <the LinFu dynamic proxy assembly(ies)> >> ******** >> Package: NHibernate.Spring >> Semantic Contents: the ProxyFactoryFactory for Spring.NET >> Dependencies: "NHibernate", <the Spring.NET dynamic proxy assembly(ies)> >> ******** >> >> This revised approach is intended to ameliorate most of the perceived >> shortcoming of the existing packaging design by: >> >> - using "NHibernate.Core" as the name of the 'bare' nh package; this >> (when present in the NuGet list alongside the new plain 'Nhibernate' >> package) should help to discourage users from inappropriately referencing >> it >> directly (fingers crossed here!) >> - making the 'plain' "NHibernate" package a fully-functional >> distribution that will "just work" for adopters (provided, of course, that >> they properly configure NH once adding the package <g>); its *hoped* that >> naming it just plain "NHibernate" will increase the chances that adopters >> will select it as the package to add (e.g., its name matches "what they >> were >> looking for") >> - still offering the original ProxyFactoryFactory-specific packages >> for those adopters 'more aware' of the pros and cons of their making a >> specific choice >> >> Before we proceed to make any of these modifications, we would like some >> feedback re: this planned approach in the following areas: >> >> 1. please comment on the proposed choice of Castle as the dynamic >> proxy engine for the 'default' NH package >> 2. please comment on the proposed new structure of package >> dependencies >> >> Thanks in advance, >> >> Steve Bohlen >> [email protected] >> http://blog.unhandled-exceptions.com >> http://twitter.com/sbohlen >> > > > > -- > Fabio Maulo > >
