IMO NHPG is and will be very useful prj for who are working with NH+Castle in medium-trust. The name "ProxyFactories" or "ProxyGenerators" or "ByteCodeProviders" is not so fundamental. What is really important for me is have a choice.
In various projects I'm using Castle but I know that there are a lot of people using Spring with NH others that prefer Ninject and so on. When I work in NH I don't think about what I like or what I'm using for my customers; my mind is concentrated to understand what is good for NH and NH-users. If you want I can change the name of the namespace from "ProxyGenerators" to "ProxyFactories" and maintain all prjs in trunk since, as Jon said, is important to deploy it with the Core. Ok... open vote: a) ProxyGenerators b) ProxyFactories c) ByteCodeProviders 2008/11/7 Bill Pierce <[EMAIL PROTECTED]> > > I want to clear up some confusion that appears to be my doing when I > added the NHibernate.ProxyGenerators project to NH Contrib. I didn't > pick up on it fully until now so I apologize for writing this so > late. The Contrib project is a .Net Console application. The purpose > of this Console app is to generate an assembly that contains all > INHibernateProxy classes needed by NHibernate to achieve lazy loading, > etc. The Console application is extensible enough to use any > framework for generating this assembly. Currently the only > implementation is Castle.DynamicProxy. The Contrib project is not > currently meant to house different runtime implementations. It is > meant for housing different compile time assembly generators. This > was the purpose for the naming distinction of "Generator". > > I believe now that Fabio envisioned the Contrib project to house > various proxy "Factory" implementations. Breaking out the > Castle.DynamicProxy implementation from the core project, adding a > LinFu implementation, and adding others in the future. I believe > there should be another Contrib project called > NHibernate.ProxyFactories where these items could live. We could then > revisit whether or not the existing ProxyGenerators project is still a > valid Contrib project. > > On Nov 6, 7:56 pm, "Fabio Maulo" <[EMAIL PROTECTED]> wrote: > > Hi friends. > > I'm thinking to remove the optionality of proxyfactory.factory_class > > property in the configuration, making it mandatory as the dialect. > > > > This change is because we will have some more ProxyGenerators, so far > hosted > > in NH-Core, and I would like that the user choose which one he want use. > > When SourceForge give me permission (arg!) I will commit the > > new NHibernate.ProxyGenerators.LinFuDynamicProxy and, hopefully, a new > one > > next week. > > > > The last release of LinFu.DynamicProxy pass all existing tests and I'm > > thinking to use it for our tests (mean our default ProxyGenerator for > > NH-Tests). > > > > In the future I don't know which will be the location of the > > others ProxyGenerators, may be NH-Contrib after the official release > > of NHibernate.ProxyGenerators project. > > > > Bye. > > Fabio Maulo > -- Fabio Maulo
