[hibernate-dev] hibernate-extras

Steve Ebersole steve at hibernate.org
Mon Nov 12 17:34:19 EST 2007


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 at hibernate.org> 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 at hibernate.org>:
> > > > > 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 at lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > > >
> > > > _______________________________________________
> > > > hibernate-dev mailing list
> > > > hibernate-dev at 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 at 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




More information about the hibernate-dev mailing list