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
>
>
