PS: Nachricht ist kurz, wurde von meinem iPhone gesendet.
Am 12.11.2007 um 23:14 schrieb Steve Ebersole <[EMAIL PROTECTED]>:
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 <[EMAIL PROTECTED]>:
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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
