Gradle + Groovy improve articles

Create a custom task

Open the build.gradlefile and add the following to the end:

println "1" 
   
task howdy {  
    println "2" 
    doLast {  
        println "Howdy" 
    }  
}  
   
println "3"

This will show you some information about how Gradle script work. Run it with the following command:

./gradlew howdy

You will see (omit some extra lines):

> Configure project :
1
2
3
 
> Task :howdy
Howdy

Here, Configure projectthe task will be to build and run the generated script. In Gradle to perform Configure projecta task, it performs the following actions:

It hit first printlnand Printing "1"
it is found to perform howdythe task definition block, a closure, and displays "2." Note that it does not perform doLastclose operation, and therefore have not been printed "Howdy".
It continues executing the script until the fourth println, then print "3."
So far, the build script itself is used to configure the build environment. The next step is to perform all the tasks specified in the command line, in this case howdythe task.

This is the task.doLast{}place to perform the block, so you'll see the words "Howdy" in the output.

doLastIt is another name for the block; it really means is similar to the "task operation", while the external block is the task configuration.

task howdy {  
    // 始终在初始构建脚本配置期间执行
    doLast {  
        // 仅在任务本身被调用时执行 
    }
    // 始终在初始构建脚本配置期间执行
} 

Use Graovy DSL according to various methods Gradle document defines the tasks are as follows:

task taskName
task taskName { configure closure }
task taskName(type: SomeType)
task taskName(type: SomeType) { configure closure }

Just to temper, "Configuring closure" when running the build script immediately, and in the doLastimplementation of the closure defined in the configuration when the closure specialized tasks.

Add a second custom task to build.gradlefile:

task partner {  
    println "4" 
    doLast {  
        println "Partner" 
    }  
}  
println "5"

If you ./gradlew partnersee:

> Configure project :
1
2
3
4
5
 
> Task :partner
Partner

If you want a custom task depend on another task how to do? This is simple. build.gradleAfter defining the two custom task, add the following line somewhere in the file.

partner.dependsOn howdy

And run:./gradlew partner

...
> Task :howdy
Howdy
 
> Task :partner
Partner

You can also use the task properties express similar relationship finalizedBy. If dependsOn line replaced with:

howdy.finalizedBy partner

And /gradlew howdyrun: .

...
> Task :howdy
Howdy
 
> Task :partner
Partner

You get the same output. Of course, they express different relationships.

About the task last point: In practice, you rarely write custom tasks for things such as "Howdy Partner" and the like (I find it hard to believe, I know). In fact, you'll usually cover the type of task you have defined. For example, Gradle defines a Copy to copy files from one location to another task.

This is a copy of the document to the sample build targets:

task copyDocs(type: Copy) {
    from 'src/main/doc'
    into 'build/target/doc'
}

When you realize that build.gradlewhen the file is actually a Groovy script, you can use Groovy and Gradle real function, if desired, you can execute arbitrary code to filter and convert these files.

The following task to convert each copy of the file and exclude .DS_Storefiles. DSL is very flexible. You can use fromand a plurality of blocks excludes, such as may be performed exclusively or rename the file contains the file operation or the like. Check the "copy" Document task again to get a more complete idea.

task copyDocs(type: Copy) {
    from 'src/main/doc'
    into 'build/target/doc'
    eachFile { file ->
        doSomething(file);
    }
    exclude '**/.DS_Store'
}

I am most attention in the Gradle Jar War or mission is responsible for packing .jarand .warfiles for final distribution of tasks. Like Copytasks, they have the ability to customize a very open process, which may be of great help for the need to customize the final product of the project. In fact, you can use Gradle DSL complete control over all aspects of the packaging process.

Spring Boot plug bootJarand bootWartasks inherited from Jarand Warmission, they include all the configuration options, including the ability to filter and modify files and the ability to customize the list of replication.

Rise piece is over, if we are interested are welcome to view the official website Gradle API documentation, very helpful.


Technology Featured articles

Non-technical Selected Articles

Guess you like

Origin www.cnblogs.com/FunTester/p/12033537.html