Making it harder to access the re-linq APIs is one of the main
benefits. It ensures that the public face of the NHibernate ORM is
complete. Otherwise, people potentially start to rely on the internal
implementation details. If we replace parts of re-linq at some point,
then the user has to rewrite their code. Providing the assemblies
publicly implies that it's safe to use the functionality, but I don't
think the goal is to make re-linq part of the public NHibernate API.
Even keeping track of the public NHibernate API itself is more than
enough effort.
I do see your point about the backwards-compatibility, but I think
this situation is going to be rare enough that it would warrant having
the user recompile.
Patrick Earl
On Thu, Jan 20, 2011 at 4:36 AM, Wenig, Stefan <[email protected]> wrote:
> Hi
>
>
>
> There are currently no NuGet packs for re-linq that we know of, and we have
> no immediate plans to create some.
>
> I’d suggest you just deliver the assembly with the NH package for now. I
> don’t recommend ILMerge. As you said, it would make it harder for the
> developer to access re-linq APIs. Also, in case a new, backwards-compatible
> version of re-linq is released, they’d have to rebuild NH in order to use it
> (for a separate assembly, binding redirects would do).
>
> OTOH, it’s quite unlikely that anyone would be using two libraries that
> bring the re-linq assembly with them.
>
>
>
> Cheers,
> Stefan
>
>
>
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Fabio Maulo
> Sent: Tuesday, January 18, 2011 5:14 PM
> To: [email protected]
> Subject: Re: [nhibernate-development] NuGet Package
>
>
>
> 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
