> That said, its my belief that if you go to your installed packages ... > ... be ready to spend some time resolving any issues this introduces ...
Agreed. I reckon the proposal for the structure looks good ... and can always get better as newer versions of NuGet support more features. From: Stephen Bohlen Sent: Monday, March 14, 2011 11:01 AM To: [email protected] Subject: Re: [nhibernate-development] Re: NHibernate 3.x NuGet packaging (re)design The point re: a silent change to which represents the default is a good one (since, as you say, configuration changes would be needed to address this as well). Its my hope that by the time such a default would change, NuGet would provide some facility to handle this (e.g., if/when a 'silent update' of an existing package were to introduce 'breaking changes'). Until that time, it might very well be that we're 'stuck' with the initial choice of default ProxyFactoryFactory. That said, its my belief that if you go to your installed packages for a solution and click some kind of "update all to latest" action in NuGet that you should be willing to accept that this might introduce breaking changes into your existing solution/project and thus be ready to spend some time resolving any issues this introduces (e.g., I don't think there is a contract in NuGet, explicit or implied, that subsequent packages have to be non-breaking with prior). Or maybe there is :) Its probably too soon in the NuGet 'era' for more than a handful of projects in NuGet to have undergone anything close to a 'real world' upgrade cycle, so there's little ability to predict what conventions will arise to handle such upgrade scenarios. Time will tell, I'm sure, but good point overall re: the challenge of managing such a proposed future change. Steve Bohlen [email protected] http://blog.unhandled-exceptions.com http://twitter.com/sbohlen On Mon, Mar 14, 2011 at 4:47 AM, Richard Brown (gmail) <[email protected]> wrote: On question 1: Castle seems like the sensible option to me. In addition to (currently) providing the most functionality I’m guessing it has the widest current adoption (since many projects will have used NHibernate before the implementation of ProxyFactoryFactory); On question 2: I’m happy with the naming convention. Will there be any issues with changing the default package to point to a different proxy implementation if (say) LinFu becomes the preferred default option at a future date? That is, can we reasonably expect everyone’s projects to happily accept a silent update to which proxy they are using ... especially when they still have to explicitly configure the proxy (either programmatically or in .config files)? From: Stephen Bohlen Sent: Sunday, March 13, 2011 11:22 PM To: [email protected] Subject: Re: [nhibernate-development] Re: NHibernate 3.x NuGet packaging (re)design There is no actual 'first-class' aliasing facility in NuGet (sadly), but your suggestion *is* implementable, if 'indirectly'. By defining 'Nhibernate' as only an 'empty' package with nothing but a dependency on Nhibernate.Castle, in effect it would have 'alias' support AFAIK. This would have the benefit of a) avoiding an additional 'actual' package (with content) that we'd have to maintain and b) provide a simple mechanism to switch the default if we wanted to do so at some future point (for any reason). Effectively we would then need to just re-state the dependency(ies) for the 'Nhibernate' package as being (example) "Nhibernate.LinFu" instead of "Nhibernate.Castle" as would be the initial case as of now. I like the idea (less to maintain/keep in sync). Steve Bohlen [email protected] http://blog.unhandled-exceptions.com http://twitter.com/sbohlen On Sun, Mar 13, 2011 at 7:16 PM, Richard Birkby <[email protected]> wrote: Would it be possible for NHibernate to depend only on NHibernate.Castle, thus becoming essentially an alias. In fact, does Nuget support a 1st class alias facility? I like calling it Core. It's exactly what I had in mind before I read your proposal. Richard On 13 Mar 2011, at 21:37, Stephen Bohlen <[email protected]> wrote: Sorry, since I copied and pasted the list of packages, I failed to (completely) edit the second of the two list of packages (showing those proposed). Here's the list of proposed package structure as I *meant* to provide it: ******** 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.Core", <the Castle dynamic proxy assembly(ies)> ******** Package: NHibernate.LinFu Semantic Contents: the ProxyFactoryFactory for LinFu Dependencies: "NHibernate.Core", <the LinFu dynamic proxy assembly(ies)> ******** Package: NHibernate.Spring Semantic Contents: the ProxyFactoryFactory for Spring.NET Dependencies: "NHibernate.Core", <the Spring.NET dynamic proxy assembly(ies)> ******** That's what I get for typing too fast... :) Steve Bohlen [email protected] http://blog.unhandled-exceptions.com http://twitter.com/sbohlen On Sun, Mar 13, 2011 at 5: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: a.. 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) b.. 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: a.. 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!) b.. 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") c.. 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
