Hibernate 4 (master branch on GitHub) has been switched to use Gradle for its builds. Mainly I just liked the alliteration of Git and Gradle... :)
The Gradle User Guide is a good reference obviously. Most of what we use gets introduced by the JavaPlugin
gradle -t is a handy thing to know. It will tell you all the main
tasks available in a project. Note however that it does not reach into subprojects. For example, assuming you are at the root of the Hibernate project checkout if you run gradle -t you would see nothing about tasks related to compiling, which is obviously essential :) In Gradle when you run a task against a project, that task request is passed along to any subprojects also. So I'd suggest cd'ing around a bit and doing gradle -t to get a feel for the tasks available. An alternative is to run gradle -t --all which shows all tasks for that project; just beware that that can get extremely verbose.
That being said, the here is a list of the most common tasks you will use:
- clean - Deletes the build directory.
- build - Assembles (jars) and tests this project.
- buildDependents - Assembles and tests this project and all projects that depend on it. So think of running this in hibernnate-entitymanager.. Gradle would assemble and test hibernate-entitymanager as well as hibernate-envers because envers depends on entitymanager. See below.
- classes - compiles the main classes
- testClasses - compiles the test classes.
- test - Runs the tests for this project
- jar - Generates a jar archive with all the compiled classes.
- uploadArchives - think Maven deploy
- install - I have also enabled the MavenPlugin throughout the projects, which adds this task. install installs the project jar into the local maven repository cache (usually ~/.m2/repository), which is important to inter-operate between projects using Maven to build and those using Gradle to build (otherwise you'd have to push your artifacts to Nexus to
share
)
A note about build and buildDependents. Gradle, unlike Maven, acts better in the face of inter-module dependences. In Gradle, if I cd into hibernate-entitymanager and perform a build, Gradle will automatically try to build hibernate-core for me if it needs to. For build it stops there. If you also want it to recompile things that depend on your changes, you would instead use buildDependents. So from hibernate-entitymanager again, if I this time run buildDependents it will first build hibernate-core, then hibernate-entitymanager and then hibernate-envers.
What's the reason for switching from maven?
I perfectly understand and accept that there are advantages from Gradle of Maven.
Just want to mention that using a different (aka ) build management raises the barrier for contributing.
Hope you guys sorted that out...
cheers,
Jan
I'm sad to see an project like Hibernate switching from Maven to a confidential build system (especially because Hibernate is not a groovy project).
What about integration with Eclipse (resource filtering, workspace resolution, ...)? Are you using Sonar?
I don't think build.gradle is more understandable than pom.xml. But I'm biased as I know Maven very well but not Groovy.
I really hope you will revert to Maven once the Gradle fashion will be over.
Not a real surprise given earlier posts, but as julien stated, I hope this is not a fashion-driven choice. As long as it doesn't interfere with my Hibernate usage, it's not really a big deal for me.
Like others, I consider this as an important regression (yeah, back to Ant non standard tasks...). And I don't see how given that everything shown in this post is also available in Maven. This is very sad, especially given the recent release of Maven 3, it's IDE support, tools like Maven Shell.
What is supposed to mean exactly?
Well we'll just agree to disagree. IMO you just made my point that Gradle is simpler here.
gradle eclipse
Why do you care if Hibernate uses Sonar? You don't I assume. You care about your project using Sonar, which Hibernate using Gradle to build has no effect on.
Yeah but you fail to notice the overall simpler structure of the 2 builds, like the fact that Maven forces use to split the main testsuite out of the module its testing because of its stupid enforcement that all projects produce only a single artifact. Or the insane difficulty in making release bundles. Or doing releases in general.
I've already outlined all the reasons I decided on switch to use Gradle in previous blog entries here as well as http://community.jboss.org/wiki/Gradlewhy
Well we shall see I guess
Hibernate was the first JBoss project to switch to Maven, and I heard all these same exact arguments back then when I made that decision. I personally find it completely hilarious, especially how may of those same people now are the ones arguing Hibernate should not move away from Maven.
Um, as posted in my earlier comment go back and look at my frustrations dealing with maven forces on us. Those blogs go back years. Hardly a choice thank you very much.
Ignore the nay sayer. You need to do what keeps you happy working with this project. It's a bold move - I for one welcome it.
Convention over Configuration, yes, but do not patronize the user. This will drive people away in the end.
I'm not saying it is. Frankly, I couldn't care less if you used Maven, Gradle, Buildr or any other build tool. As long as Hibernate releases keep showing up in Maven repositories without requiring changes, I'm a happy camper. Just being curious: have you ever contacted Jason Van Zyl or anyone else from Sonatype in regards to your problems with Maven?
I've spoken with Jason and other Maven developers numerous times, yes.