More on Splitting Hibernate Jars from Spring
Colin Sampaleanu sheds some more light on why the Hibernate classes were split into their own Jars from the Spring library:
> It's not about splitting it out just to split it out. The problem is
that having both the Hibernate 2 and Hibernate 3 code together leads to
a lot of confusion. People end up importing the wrong classes all the
time. The actual class names are identical, and the packages as
identical except for one extra char, so it's easy to import the wrong
one when you do an auto import in Eclipse. I see this over and over
during trainings, among other places. So back in the summer I suggested
we split things out to separate jars and have people just include
whichever one they wanted, but it didn't make sense (for drop in
compatibility reasons) to do this in a 1.2 point release, but rather
only now with 2.0...
> It's not about splitting it out just to split it out. The problem is
that having both the Hibernate 2 and Hibernate 3 code together leads to
a lot of confusion. People end up importing the wrong classes all the
time. The actual class names are identical, and the packages as
identical except for one extra char, so it's easy to import the wrong
one when you do an auto import in Eclipse. I see this over and over
during trainings, among other places. So back in the summer I suggested
we split things out to separate jars and have people just include
whichever one they wanted, but it didn't make sense (for drop in
compatibility reasons) to do this in a 1.2 point release, but rather
only now with 2.0...