Don't worry Steve, I don't want to remove re-linq;
my preoccupation was another... now I know that re-linq does not need
DP and this fact make me fell more comfortable about the module, its
responsibilities and its implications.
2010/1/11 Steve Strong <[email protected] <mailto:[email protected]>>
Hi All,
I've been travelling most of today, so only just catching up with
things. Firstly, I agree that the current dependency on Castle
etc is a pain, and was (in the absence of any re-linq changes)
planning on doing some ILMerge stuff at some point. However,
Fabian's timely update is perfect - I've got an upgrade to the
latest re-linq code on my todo list (there are a few fixes in
there as well that I need) so when I get around to that (probably
next week), we'll be able to loose those other references :)
I'll also re-iterate to the list the value of re-linq - it's a
whole bunch of code that I've not had to write, and the bulk of
what it is doing is stuff that I'd have had to have done anyway.
Without re-linq, there's no doubt that the effort involved in the
current provider would have been substantially more - being fair,
probably not the amount of work that re-linq itself has been, but
then I wouldn't have been building something that was reusable
outside of NH, so would have had an easier problem to solve. If I
were to put a finger in the air, I'd say that removing re-linq
would add around 2 man-months to the project (which, at my current
rate of work, would equate to something like 4 elapsed months).
I'll let you know when I've got the upgrade done...
Cheers,
Steve
On 11/01/2010 21:28, Wenig, Stefan wrote:
Hi Fabio
You're welcome! And BTW, while we were chatting here Fabian
posted an update on our blog - I didn't know we're already there:
http://www.re-motion.org/blogs/team/archive/2010/01/11/74.aspx
The bad news is we're still referencing mscorlib, System,
System.Core and System.Data ;-)
Get the build at
http://www.re-motion.org/builds/RemotionRelinq_1.13.41.0.zip
(OK, we're not that fast, we always knew we'd eventually have
to do that.)
Good luck with NH 3.0!
Cheers
Stefan
-----Original Message-----
From: [email protected]
<mailto:[email protected]>
[mailto:nhibernate- <mailto:nhibernate->
[email protected]
<mailto:[email protected]>] On Behalf Of Fabio
Maulo
Sent: Monday, January 11, 2010 8:33 PM
To: [email protected]
<mailto:[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]
<mailto:[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:[email protected]>
[mailto:nhibernate- <mailto:nhibernate->
[email protected]
<mailto:[email protected]>] On Behalf Of
Fabio Maulo
Sent: Monday, January 11, 2010 6:50 AM
To: [email protected]
<mailto:[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]
<mailto:[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
--
Fabio Maulo
