The Hibernate team is proud to announce the release of 3.6.0.Final. Lot of stuff has been going on.
This is the first release from our new digs on GitHub.
We've been helping out Stale Pedersen with his work to get JBoss Application Server running on the SPECjEnterprise2010 benchmark (and their interesting interpretations of the JPA spec). Likewise, Scott Marlow and Shelley McGowan have been putting a lot of effort into testing JavaEE compatibility of JBoss Application Server running Hibernate as the JPA provider. JBoss Application Server with Hibernate 3.6 as its persistence provider is is passing all persistence related tests in both of those efforts! Great work by everyone involved.
The highlights for 3.6 include:
- Dropping support for JDK 1.4
- Merging of hibernate-jmx and hibernate-annotations modules into hibernate-core. For those of you using Maven, that means hibernate-core-3.6.0.Final.jar contains annotation and jmx support.
- Improved Type support (HHH-5138 and related issues)
- Change in DTD hosting (HHH-5485)
- Slew of documentation changes, including introducing a new Getting Started Guide
- Several improvements to annotations support for discriminators, column-level read/write expressions, and timestamp versions.
- New Envers feature (ValidityAuditStrategy) as an alternative way to write history entries. See Adam's blog entries here and here for more information.
See http://hibernate.org/issuetracker for details on reporting issues. See http://hibernate.org/community for details on getting community help on usage questions.
Be sure to keep an eye on 4.0 development. No dates yet, but in 2 weeks as things settle down we will discuss the 4.0 time lines. I think we will keep the 2 week time-boxes for the Alphas and Betas as that seems like its been productive.
Oh boy. Just realized I inadvertently bundled the whole git repo into the SourceForge release bundles. Sorry. I guess the Maven assembly plugin does not exclude them by default like it does the other SCM meta files/directories. I will get the script updated.
good
Didn't you use the '-e <exportDir>' option of the tagRelease.sh script? This should have 'exported' your tag without the whole .git directory into a clean directory.
The changelog file doesn't contain the changes between CR2 and final release.
Congrats!
When will the Maven artifacts be avail on https://repository.jboss.org/nexus ? Tnx
They already are: https://repository.jboss.org/nexus/content/repositories/public/org/hibernate/hibernate-parent/3.6.0.Final/
Tnx... sorry, just asking because I couldnt find it searching the Nexus repository (indexing is delayed?)
BTW shouldnt be 3.6.0-Final instead?
Any chance of getting this release uploaded to Maven Central repository? For projects like AppFuse (that generate other projects), I'd rather not have to specify the JBoss repository in POMs. If I do, Maven will check JBoss for all artifacts instead of Central.
No,
is the correct format.Well the solution is to synchronize them between. But well JBoss/Red Hat and Sonatype have been arguing about, err, I mean , that for almost 2 years now. For my part I will not publish them to Central.
You can set up the order in which you want repositories searched I am pretty sure.
Well, maybe this is the correct format according to the JBoss conventions, but it isn't for Maven. The Maven format is
and not following it breaks Maven's version comparison algorithm (in particular version ranges resolution).Anyway, congratulations for this release and all the new stuff!
This is great, but are there any plans to release official OSGi bundles for Hibernate?
We are looking at that for 4. Bundles themselves are not the issue, though; the issue is classloading, which we do a lot of. I think I accounted for this in 4 with the notion of classloading as a service for which the environment can plug in different behavior. If its important to you perhaps you can take a peek?
I thought Maven were moving to support osgi-style versioning (?) which the follows...
Anyway, I understand frustration over a particular something not working, but considering the Maven developers themselves repeatedly tell us to not use version ranges for defining dependencies I have to say that interop with OSGI is more important here, IMO.
For those who might be interested, here is a set of working Maven pom.xml Entries to get Hibernate 3.6.0.Final into your project.
Under <repositories>
<repository> <id>JBoss</id> <name>JBoss repository</name> <url>https://repository.jboss.org/nexus/content/groups/public-jboss</url> </repository>Under <dependencies>
<dependency> <groupId>org.hibernate</groupId> <artifactId>hibernate-core</artifactId> <version>3.6.0.Final</version> </dependency>The path suggested earlier does NOT work. The repository is fine, but the artifact is hibernate-core, NOT hibernate-parent. I went around in circles with errors before realizing this.
_Steve Ebersole wrote on Oct 13, 2010 22:05:_<br/>
Oh boy. Just realized I inadvertently bundled the whole git repo into the SourceForge release bundles. Sorry. I guess the Maven assembly plugin does not exclude them by default like it does the other SCM meta files/directories. I will get the script updated.
</blockquote>
Click HELP for text formatting instructions. Then edit this text and check the preview.
I get that there is a change to the type system because I've read the issues you link to about 3 times now.
What I don't get is what the benefits to me as a Hibernate user are from the changes to the type sytem.
Can someone please throw some light for Building Hibernate From Src 3.6 and Importing it into IDE in the wiki?
I am able to build the new source using Gradle, which I checked out from Git. But eclipse project import is not working for me. I ran the gradle :eclipse command, and the entire hibernate-core was successfully imported in Eclipse too, but as a folder, with subfolders for each of them (c3p0, cache, etc..) with no build path set, instead of standard Java Project.(Is this the way it normally happens or I have messed up?) In fact, no .project and .classpath files were generated I guess I am missing something...
Only the master branch is using Gradle for builds...
Steve, sorry if I am ignorant. Are you saying that I should build using maven? If that is the case, then I cannot find the pom.xml for hibernate-core.The pom.xml that are present include the hibernate-tutorials, cache, reference manual, etc. Should I download the source from SourceForge and then try?
property
<hibernate-jpa-2.0-api-version>1.0.0.Final</hibernate-jpa-2.0-api-version>
dependency
<dependency>
<groupId>org.hibernate.javax.persistence</groupId>
<artifactId>hibernate-jpa-2.0-api</artifactId>
<version>${hibernate-jpa-2.0-api-version}</version>
</dependency>
repository
<repository>
<id>JBoss maven2</id>
<name>JBoss maven2</name>
<url>http://repository.jboss.org/maven2</url>
</repository>
If you want to build the 3.5 or 3.6 branches, use Maven. If you want to build master, use Gradle. Not sure how much more clear I can make it :)
You must name the JBoss repository in the first place to get the Hibernate artifacts; so not understanding why you needed to do this again...
please tell me how to download the Hibernate Core 3.6.0.Final Release jars or send it to my email loveluomeng@yahoo.com.cn, it is hard to find the download links.
Click HELP for text formatting instructions. Then edit this text and check the preview.
Excelent !!!. . . . Downloading. . .
please tell me how to download the Hibernate Core 3.6.0.Final Release jars or send it to my email zhiquanliu@foxmail.com, it is hard to find the download links.
thank you!
I need get it!
Click HELP for text formatting instructions. Then edit this text and check the preview.
I need a annotation API.
I need to get it.Thank you!
Maven2 still has severe problems with anything other than 2 part or 3 part versions (with or without the -qualifier), especially when specifying version ranges (OSGI typically does this for dependencies). Maven3 (released Oct 2010) for the most part fixes this problem. See http://docs.codehaus.org/display/MAVEN/Versioning. However many of us are still on maven2 because the API changes or the site documentation changes require a full project migration.