1. Introduction
The source code construction tool of java has roughly gone through the process of ant -> maven -> gradle. Every progress is to solve the problems caused by the previous tools. In short:
1. Although the ant function is also very powerful, it is too flexible and lacks normative. There is no default agreement on the directory structure and build.xml. 10 programmers do the same project, and there may be 10 final projects, directory structure and build.xml. The xml's are all different and there is no unified dependency management.
2. The emergence of maven solves the problem of specification, and also solves the problem of unified management of dependencies, but the specification is too strong. Basically, it can be regarded as a strong specification. After a long time, it feels more flexible. Slightly insufficient, and pom.xml adopts the xml structure, the project is large, the xml is a bit verbose.
3. gradle integrates the advantages of ant and maven, absorbs the idea of task in ant, and then integrates maven's directory specification and warehouse idea, but allows users to freely modify the default specification (for example: the source code directory can be Specify it yourself), and the configuration file is written in groovy language (the format looks a bit similar to json at first glance, which is more streamlined). Note: groovy is a real [programmable] language, not tags like css and html. In this sense, the configuration file build.gradle itself is a source code, and this source code is finally handed over to gradle for processing and execution to complete the construction of the code.
The rapid development of gradle is unmatched by ant and maven. You can feel it by looking at the documentation on the official website of gradle. The documentation of an emerging tool is so complete, we can see how well everyone recognizes it.
2. Installation:
The installation is very simple, go to the lawsuit to download the latest version (it is a compressed package), decompress a certain directory, then add GRADLE_HOME to the environment variable, and then add the variable to the path path to ensure that the gradle command can be found, refer to the following Environment variable settings:
1. Windows environment
Set system environment variables
GRADLE_HOME
D:\Work\04_Plug-in unit\gradle-2.10
add to PATH
%GRADLE_HOME%\bin;
Note: If it is a win10 system, there is no need to configure GRADLE_HOME, because the variable is not recognized in the path, and the full path is used directly in the PATH
D:\Work\04_Plug-in unit\gradle-2.10\bin
2. Linux system
export GRADLE_HOME=/opt/module/gradle-2.10
export PATH="...bin:${GRADLE_HOME}/bin"
verify:
gradle -version
or
gradle -v
3. Use in IDEA
1.idea import gradle settings
#View all available tasks gradle task #Compile (unit tests will be performed during compilation) gradle build #unit test gradle test #Skip unit tests when compiling gradle build - x test #Run the project directly gradle run #Clear all compiled and packaged files (ie: clear the build directory) gradle clean #Generate the model, mapper, and xml mapping files of mybatis. Note: Before generating, modify the relevant parameters in the src /main/resources/generatorConfig.xml file , such as: mysql connection string, target file generation path, etc. gradle mybatisGenerate #Generate a runnable jar package, the generated file is under build /install/ hello-gradle, where the subdirectory bin is the startup script, and the subdirectory lib is the generated jar package gradle installApp #Package the source code, the packaged source code, in the build / libs directory gradle sourcesJar #Install to the local maven repository, this command has the same effect as maven install gradle install #Generate the pom.xml file, the pom.xml file will be generated in the build root directory, copy it to the project root directory, you can easily convert gradle into a maven project gradle createPom