-----Original Message-----
From: [email protected] [mailto:nhibernate-
[email protected]] On Behalf Of Fabio Maulo
Sent: Monday, January 11, 2010 8:33 PM
To: [email protected]
Subject: Re: [nhibernate-development] Re: Problem with Remotion
Ok Stefan and thanks for re-linq.
The time constrain does not exists in NH so take it easy.
As you can imagine to have a lot of external dependency is not a good
thing for a low level FX as NH.
NH2.1.0 core was released with two dependency : log4net and Iesi.
As you know Iesi is maintained by ourself so it is something hard to
define it an external dependency but NH's users was asking to remove
not only log4net but even Iesi.
NH2.1.2 core has 3 dependency: Iesi, log4net, Antlr3
The actual trunk has : Iesi, log4net, Antlr3, Remotion,
Relinq, Remotion.Interfaces, Castle.Core, Castle.DynamicProxy...
I think we (we= we and you) need to do something, no?
2010/1/11 Wenig, Stefan<[email protected]>
Hi Fabio
We're currently working to separate re-linq from the rest of re-motion,
this will also remove the Castle dependencies (they are used for
Mixins, not for LINQ support).
http://www.re-motion.org/blogs/team/archive/2009/11/10/67.aspx
If you have any specific time constraints for NH3 alpha, let us know,
but we're almost there. In the meantime, you could also make your own
build using ilmerge.
If Remotion is really needed [...]
Sorry for the whining, but that sounds a bit as if re-linq were just a
nuisance to NH.
Here's a bit of history: Following Ayende's request for help with Linq
2 NH, we started to remove dependencies between re-motion's ORM, called
re-store, and it's LINQ engine, now called re-linq. The major part of
it was taking SQL generation out of it, so HQL or anything else could
be used as a back-end. Up to now, that effort alone was almost 100 days
of coding. re-linq consists of 30K lines of C# code (compared to ~ 300K
for NH). Built on top of re-linq, Linq 2 NH now has 3700 LoC. Without
re-linq, that would probably have taken _much_ more code and time.
At this point, some acknowledgement from the NH community would really
be nice. By its nature, re-linq is not a project that too many people
would use directly. We're on our way to transform re-linq and the rest
of re-motion into a community project, so we need to get some attention
at least. (That said, there has been no shortage of credits from Steve
himself!)
Next time you need something, here's our mailing list:
http://groups.google.com/group/re-motion-users
Cheers,
Stefan
http://relinq.codeplex.com
-----Original Message-----
From: [email protected] [mailto:nhibernate-
[email protected]] On Behalf Of Fabio Maulo
Sent: Monday, January 11, 2010 6:50 AM
To: [email protected]
Subject: [nhibernate-development] Re: Problem with Remotion
The most easy way, for Remotion, is deliver its dll with Castle
embedded using IL-Merge.
P.S. Steve, we need to talk.
2010/1/11 Fabio Maulo<[email protected]>
Hi.
I don't understand something...
We have worked to remove the very ugly cross reference between
NHibernate and Castle.
For example you can use NH2.1 with the new Castle.DynamicProxy2.2
only
by recompiling its bytecode.
This feature is even used in Castle where the new coming soon
ActiveRecord release will be release based on NH2.1 and its own
Bytecode with the coming soon DP2.2; the same happen in Spring.
What we have thrown out from the door now was reintroduced from the
window.
I don't know, and I don't want know, why Remotion is needing
Castle.DynamicProxy but, IMO, we can't release NH3.0 with this new
strongly reference to Remotion if it mean strongly reference to
anything else than .NET and, as very most, log4net (NOTE: we are
going
to remove even the reference to log4net).
If Remotion is really needed there is no problem but we need to talk
with them to find a way to remove the dependency to Castle before
release the first Alpha of NH3.0.
--
Fabio Maulo
--
Fabio Maulo
--
Fabio Maulo
