Using Gradle

Tool version: Gradle: 2.2.1 Groovy: 2.3.6 JVM: 1.6.0_43
maven has become the standard for java web development, the following is a common java web project:

maven project directory
usercenter contains two projects, app is a web project , common is a public module, but in addition to java, resources, and webapp, there is another resource directory of native2ascii in the main directory of the app. Strictly speaking, this does not conform to the maven convention, but it does not matter. In addition to supporting the maven convention, gradle also allows Customize the java or resources directory

The following is the gradle main configuration file (deleted most of the irrelevant dependencies, can explain the problem)

// gradle plugin
buildscript {
    repositories {
        jcenter { url "http://jcenter.bintray.com/ " }
    }
    dependencies {
        // Remote deployment plugin
        classpath 'org.hidetake:gradle-ssh-plugin:1.0.1'
        // web container, supports jetty and tomcat
        classpath 'org.akhikhl.gretty:gretty:1.2.0'
    }
}
// Global configuration, valid for all projects
allprojects {
  apply plugin: "java"
  apply plugin: "idea"
  apply plugin: "eclipse"
  apply plugin: "maven"

  group = "com.test"
  version = "1.0"

  // global property settings
  ext {
    junitVersion = "4.11"
    springVersion = "3.0.5.RELEASE"
    // java file encoding is set to utf-8
    compileJava.options.encoding = 'UTF-8'
    compileTestJava.options.encoding = 'UTF-8'
  }
}

// common to all subprojects config
subprojects {
  // Configure multiple maven source
  repositories {
      mavenLocal()
      mavenCentral()
      maven { url " http://mirrors.ibiblio.org/pub/mirrors/maven2" }
  }
  // By default, gradle will choose the dependency with the highest version, which sometimes causes problems.
  configurations.all {
    // Force the specified version to be used when there is a version conflict, which is also valid for related dependencies
    resolutionStrategy.force(
      "org .springframework:spring-core:${springVersion}",
    )
  }
  // public dependency configuration
  dependencies {
      compile(
        "org.springframework:spring-core:${springVersion}",
      )
      testCompile(
        "junit:junit:${junitVersion }",
      )
  }
}
// app project configuration
project(':app'){
  apply plugin: 'war'
  apply from: 'gretty'
  // use the gretty plugin to run the web project
  gretty {
    httpPort = 8080
    debugPort = httpPort + 1
    servicePort = httpPort + 2
    statusPort = httpPort + 3
    httpsPort = httpPort + 4
    httpsEnabled = true
    contextPath = '/'
    jvmArgs = ['-Xmx1024M', '-XX:PermSize=128M', '-XX:MaxPermSize=256M']
    servletContainer = 'jetty7'
    scanInterval = 0
    inplaceMode = 'hard'
    debugSuspend = false
  }
  // 自定义resource文件夹
  sourceSets {
    main {
      resources.srcDirs = ['src/main/resources', 'src/main/native2ascii']       // Depends on common project     compile(   dependencies {   }
    }




      project(":common"),
      "javax.servlet.jsp:jsp-api:2.1",
      "javax.servlet:servlet-api:2.5",
    )
  }
}
// common project configuration
project(':common'){
  // Set the resource file directory and import the xml file in the java folder
  sourceSets {
    main {
      resources.srcDirs = ['src/main/resources', 'src/main/java']
      resources.includes = ['src/main/ java/**.xml']
    }
  }
  dependencies {
    compile(
      "org.mongodb:mongo-java-driver:2.10.1",
      fileTree(dir: 'lib' , include: '*.jar' )
    )
  }
}


settings . Record sub-projects in gradle, the content is only one line
Include 'app', 'common'


can write the gradle configuration to multiple folders, and create a new build.gradle under each sub-project. If the project is relatively simple, you can also write the configuration of all sub-projects as above. In the

build.gradle you only need to execute a command in the directory of the main project
> gradle app:jettyRun


is similar to maven, gradle also extends the function in the form of plug-ins, add a new plug-in apply plugin: ' jetty' , the configuration of each plugin is provided in the form of a code block. The gretty configuration used in the above configuration configures the web container. The gretty configuration block is:
  gretty { httpPort
    = 8080
    debugPort = httpPort + 1
    servicePort = httpPort + 2
    statusPort = httpPort + 3
    httpsPort = httpPort + 4
    httpsEnabled = true
    contextPath = '/'
    jvmArgs = ['-Xmx1024M', '-XX:PermSize=128M', '-XX:MaxPermSize=256M']
    servletContainer = 'jetty7'
    scanInterval = 0
    inplaceMode = 'hard'
    debugSuspend = false
  }


The configuration is simple and easy to understand, no need to say more.

Here gretty configures jetty7 as the web container, and gradle comes with jetty plugin (does not support hot deployment of java code, only jsp can be updated), the configuration is as follows:
// jetty startup Configure
jettyRun { httpPort
    = 8080
    contextPath = ""
    reload = "automatic"
    scanIntervalSeconds = 1
}


The above is a simple alternative to maven. Obviously, gradle can do more than this. Thanks to the lightness of groovy, gradle provides great flexibility. Let's look at an application scenario.

Using the org.hidetake.ssh plugin, a local war package can be published to a remote server. Add the following configuration to the head of build.gradle
// Works before gradle script build
buildscript {
    repositories {
        jcenter()
    }
    dependencies {
        classpath 'org.hidetake:gradle-ssh-plugin:1.0.1'
    }
}


The buildscript is used to configure plugins that are not in the maven repository, it is executed before the gradle script runs.

Configure the server in the ext block:
// remote server address
tomcatPath = '/opt/tomcat'
// remote server address
remotes {
    server {
        host = '192.168.1.1'
        user = 'root'
        password = 'root'
    }
}


usually local The development environment is inconsistent with the server environment. For example, the port number used for local development is 8080, and the domain name and port used by the remote server are different (requests are forwarded by nginx). If you want to replace the configuration file when publishing to the remote server Domain name, that's it.

First configure the domain name correspondence in the ext block
replaceUrl = [
    'myapp:8080' : 'myapp:7654',
    'mypartner:9090' : 'mypartner:7655',
]


and then configure and execute in the project(':common') block Replace *.



    project.gradle.startParameter.taskNames.each{ command ->
        if(command.contains('deploy')){
            replace = true
        }
    }

    if(replace){
        filesMatching('**/*.properties') {
            filter{
                / / the it variable is the default name in the filter iterator, here represents each row
                def result = it
                replaceUrl.each{ key,value ->
                    if(it.contains(key)){
                        result = result.replaceAll key, value
                    }
                }
                result
            }
        }
    }
}


This code is native groovy code, and the flexibility of gradle is reflected here. Regarding the groovy language, you can make up your own mind.

project.gradle.startParameter.taskNames is the gradle command line parameter, such as gradle clean app:deploy, then the command line parameter is ['clean', 'app:deploy']

filesMatching('**/*.properties') is to filter all The files ending with properties, ** are searched recursively. Next is the deployment code:
// Deploy to the remote server, the uploaded war name is app.war
task deploy(dependsOn: war) << {
  ssh.run {
    session(remotes.server) {
        put "$war. archivePath.path", "$tomcatPath/webapps/app.war"
        execute "$tomcatPath/bin/shutdown.sh"
        execute "rm -rf $tomcatPath/webapps/ROOT/*"
        execute "unzip -oq $tomcatPath/webapps/ app.war -d $tomcatPath/webapps/ROOT"
        execute "
        execute "$tomcatPath/bin/startup.sh"
    }
  }
}


deploy simply executes the shell command, uploads the war package, closes the tomcat, decompresses the war, deletes the war, and starts the tomcat.
Deployment command: gradle clean app:deploy