九.多项目构建

一.项目模块化
  在企业项目中,包层次和类关系比较复杂,把代码拆分成模块通常时最佳实践,这需要清晰的划分功能的边界,比如把业务逻辑和数据持久化拆分开来。项目符合高内聚低耦合时,模块化就变得很容易,这是一条分厂好的软件开发实践

二.TODO模块化,分出:
1.Model
2.Repository
3.Web
依赖关系
Web依赖Repository,Repository依赖Model,因此Web也依赖于Model

三.实践
1.todo跟项目(总项目):
  build.gradle:
  

//group 'com.tiglle.WepApp'
//version '1.0-SNAPSHOT'

apply plugin: 'java'//gradle的插件,添加会增加相应的gradle命令
apply plugin: 'war'//gradle的插件,添加会增加相应的gradle命令

//所有项目都会继承的配置
allprojects{
    //所有项目都引入java插件,但是子项目配置后,会覆盖此配置
    apply plugin:'java'
    //所有项目都引入的依赖
    dependencies{
        //logback的依赖
    compile ('ch.qos.logback:logback-classic:1.2.1')
    }
}

repositories {
    mavenCentral()
}

////添加依赖
//dependencies {
//    //junit的依赖
//    testCompile group: 'junit', name: 'junit', version: '4.11'
//    //bibernate的依赖
//    compile 'org.hibernate:hibernate-core:3.6.3.Final'
//    //logback的依赖
//    compile 'ch.qos.logback:logback-classic:1.2.1'
//}

//排除传递性依赖
//添加依赖
dependencies {
    //junit的依赖
    testCompile group: 'junit', name: 'junit', version: '4.11'
    //hbernate的依赖
    compile ('org.hibernate:hibernate-core:3.6.3.Final'){
        //排斥hibernate对slf4j的依赖
        exclude group:'org.slf4j',module:'slf4j-api'
    }
    //logback的依赖
    compile ('ch.qos.logback:logback-classic:1.2.1')
}

////取消gradle默认统一使用高版本依赖的策略(gradle默认依赖冲突解决策略)
//configurations.all{
//    resolutionStrategy{
//        failOnVersionConflict()
//    }
//}

//强制gradle默认统一使用某个版本依赖的策略(修改gradle默认依赖冲突解决策略)
configurations.all{
    resolutionStrategy{
        failOnVersionConflict()
        force 'org.slf4j:slf4j-api:1.7.22'
    }
}

//闭包,必须声明在调用前面......
def createDir = {
    path ->
        //如果文件夹不存在,创建
        File dir = new File(path);
        if(!dir.exists()){
            dir.mkdirs();
        }
}

//自定义任务(创建项目文件夹)
task makeJavaDir(){
    //声明文件夹(字符串数组)
    def paths = ['src/main/java','src/main/resources','src/test/java','src/test/resource']
    //在动作列表的最前面添加动作
    doFirst {
        //循环path,调用闭包
        paths.forEach(createDir);
    }
}


//创建依赖于其他任务的任务
task makeWebDir(){
    //makeJavaDir任务会执行
    dependsOn 'makeJavaDir'
    //声明文件夹的数组(字符串类型)
    def paths = ['src/main/webapp','src/main/webapp/WEB-INF']
    doLast {
        //循环调用闭包,创建文件夹
        paths.forEach(createDir)
    }
}

gradle.properties:

# 项目的通用属性,所有项目会继承
group = 'com.tiglle.WepApp'
version = '1.0-SNAPSHOT'

settings.gradle:

//根项目
rootProject.name = 'todo-web'
//子项目
include 'model'
include 'repository'
include 'web'
//一个项目有一个跟项目,n个子项目

2.model子项目
build.gradle:

//group 'com.tiglle.WepApp'
//version '1.0-SNAPSHOT'

apply plugin: 'java'

sourceCompatibility = 1.5

repositories {
    mavenCentral()
}

dependencies {
    testCompile group: 'junit', name: 'junit', version: '4.11'
}
//闭包,必须声明在调用前面......
def createDir = {
    path ->
        //如果文件夹不存在,创建
        File dir = new File(path);
        if(!dir.exists()){
            dir.mkdirs();
        }
}

//自定义任务(创建项目文件夹)
task makeJavaDir(){
    //声明文件夹(字符串数组)
    def paths = ['src/main/java','src/main/resources','src/test/java','src/test/resource']
    //在动作列表的最前面添加动作
    doFirst {
        //循环path,调用闭包
        paths.forEach(createDir);
    }
}

3.repository子项目
build.gradle:

//group 'com.tiglle.WepApp'
//version '1.0-SNAPSHOT'

apply plugin: 'java'

sourceCompatibility = 1.5

repositories {
    mavenCentral()
}

dependencies {
    testCompile group: 'junit', name: 'junit', version: '4.11'
    //对子项目依赖的特殊写法
    compile project(':model')
}
//闭包,必须声明在调用前面......
def createDir = {
    path ->
        //如果文件夹不存在,创建
        File dir = new File(path);
        if(!dir.exists()){
            dir.mkdirs();
        }
}

//自定义任务(创建项目文件夹)
task makeJavaDir(){
    //声明文件夹(字符串数组)
    def paths = ['src/main/java','src/main/resources','src/test/java','src/test/resource']
    //在动作列表的最前面添加动作
    doFirst {
        //循环path,调用闭包
        paths.forEach(createDir);
    }
}

4.web子项目
build.gradle:

//group 'com.tiglle.WepApp'
//version '1.0-SNAPSHOT'

apply plugin: 'war'

repositories {
    mavenCentral()
}

dependencies {
    testCompile group: 'junit', name: 'junit', version: '4.11'
    //对子项目依赖的特殊写法
    compile project(':repository')
}

四.idea显示的项目关系
这里写图片描述

此时执行跟项目的clean等操作,会执行所有子项目的操作

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
The PCRE library is a set of functions that implement regular expression pattern matching using the same syntax and semantics as Perl, with just a few differences. Certain features that appeared in Python and PCRE before they appeared in Perl are also available using the Python syntax. There is also some support for certain .NET and Oniguruma syntax items, and there is an option for requesting some minor changes that give better JavaScript compatibility. The current implementation of PCRE (release 7.x) corresponds approximately with Perl 5.10, including support for UTF-8 encoded strings and Unicode general category properties. However, UTF-8 and Unicode support has to be explicitly enabled; it is not the default. The Unicode tables correspond to Unicode release 5.0.0. In addition to the Perl-compatible matching function, PCRE contains an alternative matching function that matches the same compiled patterns in a different way. In certain circumstances, the alternative function has some advantages. For a discussion of the two matching algorithms, see the pcrematching page. PCRE is written in C and released as a C library. A number of people have written wrappers and interfaces of various kinds. In particular, Google Inc. have provided a comprehensive C++ wrapper. This is now included as part of the PCRE distribution. The pcrecpp page has details of this interface. Other people's contributions can be found in the Contrib directory at the primary FTP site, which is: ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre Details of exactly which Perl regular expression features are and are not supported by PCRE are given in separate documents. See the pcrepattern and pcrecompat pages. There is a syntax summary in the pcresyntax page. Some features of PCRE can be included, excluded, or changed when the library is built. The pcre_config() function makes it possible for a client to discover which features are available. The features themselves are described in the pcrebuild page. Documentation about building PCRE for various operating systems can be found in the README file in the source distribution. The library contains a number of undocumented internal functions and data tables that are used by more than one of the exported external functions, but which are not intended for use by external callers. Their names all begin with "_pcre_", which hopefully will not provoke any name clashes. In some environments, it is possible to control which external symbols are exported when a shared library is built, and in these cases the undocumented symbols are not exported.

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值