3:41 p.m.
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
4:04 p.m.
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
Cheers,
Mike
Am 12.11.2007 um 22:41 schrieb Steve Ebersole <steve(a)hibernate.org>:
4:14 p.m.
On Monday 12 November 2007 04:04:22 pm Michael Plöd wrote:
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.
--
Steve Ebersole
Hibernate Project Lead
http://hibernate.org
Principal Software Engineer
http://redhat.com
http://jboss.org
4:28 p.m.
Sorry for the last message I need to get used to my iPhone :-(
I totally see your point but judging from my experience the WS
customer is an extremely conservative one that wants everything to be
"supported" within the "1st class" Jar file. I know this is hillarious
but that's the way I saw some WS customers act.
I know about one of my customers that will really discuss this.
Am 12.11.2007 um 23:14 schrieb Steve Ebersole <steve(a)hibernate.org>:
6:19 a.m.
I stand with Michael about introduction of a hibernate-extra jar-file.
I use the DB2400 and 390 dialect a lot and we have had a hard time getting our mainframe
sysadmins to allow Hibernate on their precious mainframe. Physically removing these
crucial parts to another jar file labelled as "unmaintained and untested" will
not help gain their trust.
Is there no other way to get this messages out there without creating another jar-file?
Perhaps a list on the Hibernate website? This will also be more flexible in ways of
changing the status of "unmaintained and untested" parts.
Just my two cents as do understand the difficulties you are facing in maintaining these
parts.
Kind regards,
Peter
-----Oorspronkelijk bericht-----
Van: hibernate-dev-bounces(a)lists.jboss.org [mailto:hibernate-dev-bounces@lists.jboss.org]
Namens Michael Plöd
Verzonden: maandag 12 november 2007 23:29
CC: hibernate-dev(a)lists.jboss.org
Onderwerp: Re: [hibernate-dev] hibernate-extras
Sorry for the last message I need to get used to my iPhone :-(
I totally see your point but judging from my experience the WS
customer is an extremely conservative one that wants everything to be
"supported" within the "1st class" Jar file. I know this is hillarious
but that's the way I saw some WS customers act.
I know about one of my customers that will really discuss this.
Am 12.11.2007 um 23:14 schrieb Steve Ebersole <steve(a)hibernate.org>:
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
9:26 a.m.
On Tuesday 13 November 2007 06:19:46 am Schuler, Peter wrote:
Simply listing them on a website page does not have nearly the effect moving
them to another jar has. In terms of dialects, this is already the case and
in fact has been for over 2 years. And yet, it takes the mere suggestion of
removal to a seperate jar to get any type of reponse.
Honestly, what I really want is some ownership. Trust me, I'd rather not
separate these; I'd much rather have individuals take responsiblity for
maintaining each of these pieces.
--
Steve Ebersole
Hibernate Project Lead
http://hibernate.org
Principal Software Engineer
http://redhat.com
http://jboss.org
6344
days inactive
6345
days old
6 comments
3 participants
participants (3)
-
Michael Plöd -
Schuler, Peter -
Steve Ebersole