Yep, I missed the SybaseAnywhereDialect I actually use the H2 one myself for local testing, and I will be having that one set up on CI later. On Monday 12 November 2007 04:30:33 pm Diego Pires Plentz wrote: > > IMO, the thing that is being missed here is the ideal of open-source, > > which is that someone with a stake in these WS TM lookups steps up and > > maintains it. > > Agree. > > Btw, i think that H2Dialect and SybaseAnywhereDialect could be moved too. > > > On Nov 12, 2007 7:14 PM, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > > > On Monday 12 November 2007 04:04:22 pm Michael Plöd wrote: > > > > Honestly I think that the WebSphere TransactionManager Lookups should > > > > remain in the "core" bundle. I know that it is a pain to test and > > > > maintain but I think that Hibernate is Quote popular in WS > > > > environments > > > > > > Funny, the WS TM lookups are, to me, the epitome of what should get > > > moved ;) And the point is not that "it is a pain to test and maintain"; > > > the point is that it is not tested and is not maintained on a > > > consistent basis, or at all. > > > > > > Do you really think having the classes in one jar or another will make > > > them any less popular or usable? > > > > > > IMO, the thing that is being missed here is the ideal of open-source, > > > which is that someone with a stake in these WS TM lookups steps up and > > > maintains it. > > > > > > > Cheers, > > > > Mike > > > > > > > > Am 12.11.2007 um 22:41 schrieb Steve Ebersole <steve(a)hibernate.org&gt;: > > > > > Starting with 3.3 I plan on introducing hibernate-extras, which > > > > > will be a > > > > > separate jar which will include code which is un-tested and un- > > > > > maintained by > > > > > committers. The impetus for this move is simply to make it clear > > > > > to users > > > > > what pieces of functionality are tested in an ongoing fashion and > > > > > are maintained by the Hibernate committers, versus those which are > > > > > not. > > > > > > > > > > Users should have certain expectations in regards to those which > > > > > are not > > > > > (the "extras"). One such expectation is the fact that the quality > > > > > may or may > > > > > not be on par with the rest of the codebase; the important point > > > > > being that > > > > > we cannot guarentee the quality. Another expectation would be in > > > > > regards to > > > > > support for that functionality, and the fact that for whatever > > > > > reason noone > > > > > with expertise on those components owns its maintenance; thus > > > > > improvements > > > > > and bug-fixes would be expected to be patches from the community > > > > > (or that > > > > > someone with a stake in that functionality would stand up and take > > > > > on its > > > > > maintenance). > > > > > > > > > > The code I currently see being moved there is quite a few of the > > > > > TransactionManagerLookup impls and some of the Dialects (non- > > > > > exhaustive): > > > > > org.hibernate.dialect.DB2390Dialect > > > > > org.hibernate.dialect.DB2400Dialect > > > > > org.hibernate.dialect.FirebirdDialect > > > > > org.hibernate.dialect.FrontBaseDialect > > > > > org.hibernate.dialect.InformixDialect > > > > > org.hibernate.dialect.JDataStoreDialect > > > > > org.hibernate.dialect.MckoiDialect > > > > > org.hibernate.dialect.MimerSQLDialect > > > > > org.hibernate.dialect.PointbaseDialect > > > > > org.hibernate.dialect.ProgressDialect > > > > > org.hibernate.dialect.RDMSOS2200Dialect > > > > > org.hibernate.dialect.SAPDBDialect > > > > > org.hibernate.transaction.BESTransactionManagerLookup > > > > > org.hibernate.transaction.JOnASTransactionManagerLookup > > > > > org.hibernate.transaction.JOTMTransactionManagerLookup > > > > > org.hibernate.transaction.JRun4TransactionManagerLookup > > > > > org.hibernate.transaction.OC4JTransactionManagerLookup > > > > > org.hibernate.transaction.OrionTransactionManagerLookup > > > > > org.hibernate.transaction.WebSphereExtendedJTATransactionLookup > > > > > org.hibernate.transaction.WebSphereTransactionManagerLookup > > > > > > > > > > (this is in addition to the already done splits on trunk) > > > > > > > > > > Anyone feel any of the above should remain in the core bundle? > > > > > Anything else > > > > > we should move? > > > > > > > > > > > > > > > -- > > > > > Steve Ebersole > > > > > > > > > > Hibernate Project Lead > > > > > http://hibernate.org > > > > > > > > > > Principal Software Engineer > > > > > http://redhat.com > > > > > http://jboss.org > > > > > _______________________________________________ > > > > > hibernate-dev mailing list > > > > > hibernate-dev(a)lists.jboss.org > > > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > > > > _______________________________________________ > > > > hibernate-dev mailing list > > > > hibernate-dev(a)lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > > -- > > > Steve Ebersole > > > > > > Hibernate Project Lead > > > http://hibernate.org > > > > > > Principal Software Engineer > > > http://redhat.com > > > http://jboss.org > > > > > > _______________________________________________ > > > hibernate-dev mailing list > > > hibernate-dev(a)lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > -- > > http://plentz.org/ > > "Provide options, don't make lame excuses." -- Steve Ebersole Hibernate Project Lead http://hibernate.org Principal Software Engineer http://redhat.com http://jboss.org

Also, how do we jive this with Max's need to build a SessionFactory which does not have access to the underlying database for tools usage? Max, this would depend on how you use these SessionFactories, and the Dialect associated with it.