Just another couple quick comments:
1. A fake NHibernate package with an install doc would make it easy
to recommend nhcontrib packages for particular purposes. We can help
shorten the time it takes for the user get a fully functioning set of
packages.
2. I believe the configuration system in NuGet is just additive. I
don't know how it handles replacements. In any case, trying to do
config replacements instead of additions might be a can of worms.
Patrick Earl
On Mon, Mar 14, 2011 at 9:35 AM, Patrick Earl <[email protected]> wrote:
> I'm certainly in support of having a separate NHibernate.Core package.
> I don't think it's necessary for every contrib package to reference
> everything needed to get up and running. I think NHibernate users
> aren't typically going to start with the idea that "I want this one
> add-on", but will instead likely use NHibernate first and add things
> on from there. If you consider people that are running different
> databases, the necessity of multi-step installation seems more clear.
> For example, to get a bare package running for PostgreSQL, you'd need
> something like:
>
> NHiberante.Core
> NHibernate.ByteCode.Castle
> NHibernate.Databases.PostgreSQL
>
> We would actually want NHibernate.ByteCode.Castle to do some
> configuration and set up the proxy factory factory setting for us. If
> you had LinFu installed, and then were forced to install
> NHibernate(+castle) because of a dependency, it might change your
> LinFu proxy settings to Castle proxy settings.
>
> Note that I changed the name of Castle, to ByteCode.Castle. If we
> classify them into groups, it may become more clear how to use them.
> For example, imagine we have this list:
>
> NHibernate.Core
> NHibernate.ByteCode.Castle
> NHibernate.ByteCode.LinFu
> NHibernate.ByteCode.Spring
> NHibernate.Database.MsSql2008 (adds appropriate connection strings and
> standard properties to user's config file)
> NHibernate.Database.PostgreSQL
> NHibernate.Database.SQLite
>
> Any sort of introductory docs could simply state that the user needs
> to select one of each... one ByteCode, one Database. At the very
> least, when the user searches for NHibernate, they'll wonder what
> these "ByteCode" and "Database" categories are, and that might prompt
> them to read the description, letting them know what they need to
> install. I actually think it's fair to use the descriptions of these
> packages to convey information on requirements in our scenario.
> Granted, you might still end up with a user just installing
> "NHibernate" by name.
>
> Here's a new idea. Make NHibernate a dummy package that isn't
> actually needed for anything. All you would get is a file explaining
> what other packages you need to install. Then there's no possibility
> of people depending on the wrong packages. If needed though, I
> generally support the use of castle as the default proxy provider.
>
> I think it's important that the packages come with configuration.
> It's not generally the assemblies themselves that are the hard part of
> getting NH running, but the associated config. Once the user has
> selected their two packages, they should only really need to change
> the example connection string in the config and start writing some
> code.
>
> Patrick Earl
>
> On Mon, Mar 14, 2011 at 8:15 AM, Stephen Bohlen <[email protected]> wrote:
>> 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:
>>
>> added Nhibernate.Linfu package b/c I *know* that's what I want
>> 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
>
