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
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.