I was imagining there would be something like an
NHibernate.ByteCode.Castle or NHibernate.Castle package. Once
installed, it would add Castle.Core and NHibernate.ByteCode.Castle as
project references. It would also add the bytecode configuration
information to the config file. NuGet easily allows you to specify
config lines that are added and removed as packages are added and
removed. Then, to use NHibernate, the user would need to do something
like:
Install-Package NHibernate.ByteCode.Castle
Install-Package NHibernate.Database.PostgreSQL9
This would implicitly add NHibernate.Core and any other required
packages like Npgsql. It would also configure the castle bytecode
provider and set up the PostgreSQL dialect and drivers.
In my limited imagination, all the user would need to do is set the
config string and write their NHibernate code. It would be beneficial
to provide example code, but that can also be done through
documentation. Given how pluggable NHibernate is, I don't see a
convenient way to avoid making decisions without the help of a getting
started document.
If they wanted logging, they could add something like:
Install-Package NHibernate.Logging.Log4Net
In essence, NuGet "composability" is built primarily around additive
only fragments. For example, you can add an assembly reference or add
a line to a config file. When the package manager is removed, the
package manager will also remove those lines.
There are advanced capabilities around the creation of new powershell
commands, but after thinking about it a bit, I don't feel they're
necessary for the time being.
Patrick Earl
On Tue, Jan 18, 2011 at 9:52 AM, Fabio Maulo <[email protected]> wrote:
> btw, back to the matter of the thread, the real problems for NuGet are
> others.
> We have to check "composition capability" where the NuGet package is
> available for a NH's "option".
> For bytecode I'm thinking about a little improvement to avoid the mandatory
> configuration (the same done for the logger where the log4net dll is present
> in bin folder)... but even this is another matter.
> Steve Bohlen will check the actual capability of NuGet then we will
> elaborate a proposal for a modification where we can't work around possible
> limitations.
>
> On Tue, Jan 18, 2011 at 1:38 PM, Patrick Earl <[email protected]> wrote:
>>
>> For the record, the correct version of Antlr is not available in
>> NuGet. That said, I'd prefer to not even have potential dependency
>> issues with Antlr and ReLinq. Those assemblies have their own release
>> cycles and at least Antlr is generally useful in many projects. I'm
>> concerned that we'll make people's lives difficult with versioning and
>> Antlr. They might want to use the latest version in their project,
>> but NHibernate would be tied to 3.2 for example.
>>
>> As far as I can see it, the ILMerge leads to the following.
>>
>> Advantages:
>> - Single dll for NHibernate core.
>> - No version conflicts with external use of Antlr or ReLinq.
>> - Reduces chance of problems in the future if we change our internal
>> dependencies. For example, a user might have added a reference to one
>> of these dependencies, but now it's no longer needed.
>> - Makes understanding required dlls and packaging easier for end users.
>> - Hides internal implementation details of Antlr and ReLinq.
>>
>> Disadvantages:
>> - Hides internal implementation details of Antlr and ReLinq. Yes,
>> this is also a disadvantage, since there may be cases where we want to
>> expose some Antlr or ReLinq functionality directly. That said, I
>> believe the best approach ultimately is to provide an NHibernate
>> "wrapper" into any required functionality. This ensures easy
>> replacement and a clean API where you don't randomly hook into the
>> internal parser for example.
>>
>> For me at least, the advantages significantly outweigh the potential
>> issues. Are there other things I'm missing here?
>>
>> Patrick Earl
>>
>> On Tue, Jan 18, 2011 at 9:14 AM, Fabio Maulo <[email protected]> wrote:
>> > There are cases where the ILMerge may generate more problems than it
>> > solve,
>> > take care.
>> > Where NuGet-packs are not available we can include the DLLs directly.
>> >
>> > On Tue, Jan 18, 2011 at 1:06 AM, Patrick Earl <[email protected]> wrote:
>> >>
>> >> Okay, I used ILMerge, internalizing the ReLinq and Antlr assemblies,
>> >> and aside from one tiny change to a unit test (was checking for a
>> >> specific Antlr exception), the unit tests still pass. The
>> >> internalization process avoids conflicts if people choose to use
>> >> ReLinq or Antlr in their own projects.
>> >>
>> >> I propose that we utilize ILMerge to avoid versioning and distribution
>> >> problems with these two internal-use assemblies.
>> >>
>> >> Patrick Earl
>> >>
>> >> On Mon, Jan 17, 2011 at 6:51 PM, Patrick Earl <[email protected]> wrote:
>> >> > Does the ReLinq team have any plans to release a package anytime in
>> >> > the
>> >> > future?
>> >> >
>> >> > Are there thoughts around ILMerging ReLinq and Antlr? As far as I'm
>> >> > concerned, they're basically internal implementation details.
>> >> >
>> >> > Patrick Earl
>> >> >
>> >> > On Mon, Jan 17, 2011 at 5:00 PM, Fabio Maulo <[email protected]>
>> >> > wrote:
>> >> >> - Log4Net is unneeded.
>> >> >> - we have to check the existence of NuGet packages only for Antlr
>> >> >> and
>> >> >> re-linq
>> >> >> - NH shouldn't have a "default" choice for the bytecode provider
>> >> >> because we
>> >> >> don't want hurt any other OSS project (Castle, Spring, LinFu are in
>> >> >> the
>> >> >> same
>> >> >> level of preference for us). Perhaps we may have a default when we
>> >> >> will
>> >> >> have
>> >> >> dynamic-proxy included in .NET.
>> >> >> - As a mature OSS project, and even more thinking in DCVS, the
>> >> >> <authors>
>> >> >> should contain: "look at commits and then add Hibernate committers"
>> >> >> - The dependency on the NuGet-pack for Castle/LinFu/Spring should be
>> >> >> related, where possible, only to the DLLs needed by NHibernate and
>> >> >> not
>> >> >> to
>> >> >> the whole suite.
>> >> >> - The NAnt's target named package should includes the execution of a
>> >> >> target
>> >> >> named : NuGetDeploy
>> >> >>
>> >> >>
>> >> >> On Mon, Jan 17, 2011 at 1:53 PM, 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
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Fabio Maulo
>> >> >>
>> >> >>
>> >> >
>> >
>> >
>> >
>> > --
>> > Fabio Maulo
>> >
>> >
>
>
>
> --
> Fabio Maulo
>
>
