精华内容
下载资源
问答
  • Maven和Gradle的区别

    2018-01-31 16:13:00
    转自:http://www.infoq.com/cn/news/2011/04/xxb-maven-6-gradle Maven面临挑战 ...虽然目前它基本上是Java构建事实标准,但我们也能看到新兴工具在涌现,比如基于Goovy的Gradle,而去年Hi...

    转自:http://www.infoq.com/cn/news/2011/04/xxb-maven-6-gradle

    Maven面临的挑战

    软件行业新旧交替的速度之快往往令人咂舌,不用多少时间,你就会发现曾经大红大紫的技术已经成为了昨日黄花,当然,Maven也不会例外。虽然目前它基本上是Java构建的事实标准,但我们也能看到新兴的工具在涌现,比如基于Goovy的Gradle,而去年Hibernate宣布从Maven迁移至Gradle这一事件更是吸引了不少眼球。在此之前,我也听到了不少对Maven的抱怨,包括XML的繁冗,不够灵活,学习曲线陡峭等等。那Gradle是否能够在继承 Maven优点的基础上,克服这些缺点呢?带着这个疑问,我开始阅读Gradle的文档并尝试着将一个基于Maven的项目转成用Gradle构建,本文所要讲述大概就是这样的一个体验。需要注意的是,本文完全是基于Maven的角度来看Gradle的,因此对于Ant用户来说,视角肯定会大有不同。

    Gradle初体验

    Gradle的安装非常方便,下载ZIP包,解压到本地目录,设置 GRADLE_HOME 环境变量并将 GRADLE_HOME/bin 加到 PATH 环境变量中,安装就完成了。用户可以运行gradle -v命令验证安装,这些初始的步骤和Maven没什么两样。Gradle目前的版本是1.0-milestone-1,根据其Wiki上的Roadmap,在1.0正式版发布之前,还至少会有3个里程碑版本,而1.0的发布日期最快也不会早于6月份。而正是这样一个看起来似乎还不怎么成熟的项目,却有着让很多成熟项目都汗颜的文档,其包括了安装指南、基本教程、以及一份近300页的全面用户指南。这对于用户来说是非常友好的,同时也说明了Gradle的开发者对这个项目非常有信心,要知道编写并维护文档可不是件轻松的工作,对于Gradle这样未来仍可能发生很大变动的项目来说尤为如此。

    类似于Maven的pom.xml文件,每个Gradle项目都需要有一个对应的build.gradle文件,该文件定义一些任务(task)来完成构建工作,当然,每个任务是可配置的,任务之间也可以依赖,用户亦能配置缺省任务,就像这样:

    defaultTasks 'taskB'
    
    task taskA << {
        println "i'm task A"
    }
    
    task taskB << {
        println "i'm task B, and I depend on " + taskA.name
    }
    
    taskB.dependsOn taskA
    

    运行命令$ gradle -q之后(参数q让Gradle不要打印错误之外的日志),就能看到如下的预期输出:

    i'm task A
    i'm task B, and I depend on taskA
    

    这不是和Ant如出一辙么?的确是这样,这种“任务”的概念与用法与Ant及其相似。Ant任务是Gradle世界的第一公民,Gradle对Ant做了很好的集成。除此之外,由于Gradle使用的Grovvy脚本较XML更为灵活,因此,即使我自己不是Ant用户,我也仍然觉得Ant用户会喜欢上Gradle。

    依赖管理和集成Maven仓库

    我们知道依赖管理、仓库、约定优于配置等概念是Maven的核心内容,抛开其实现是否最优不谈,概念本身没什么问题,并且已经被广泛学习和接受。那Gradle实现了这些优秀概念了么?答案是肯定的。

    先看依赖管理,我有一个简单的项目依赖于一些第三方类库包括SpringFramework、JUnit、Kaptcha等等。原来的Maven POM配置大概是这样的(篇幅关系,省略了部分父POM配置):

        <properties>
            <kaptcha.version>2.3</kaptcha.version>
        </properties>
    
        <dependencies>
            <dependency>
                <groupId>com.google.code.kaptcha</groupId>
                <artifactId>kaptcha</artifactId>
                <version>${kaptcha.version}</version>
                <classifier>jdk15</classifier>
            </dependency>
            <dependency>
                <groupId>org.springframework</groupId>
                <artifactId>spring-core</artifactId>
            </dependency>
            <dependency>
                <groupId>org.springframework</groupId>
                <artifactId>spring-beans</artifactId>
            </dependency>
            <dependency>
                <groupId>org.springframework</groupId>
                <artifactId>spring-context</artifactId>
            </dependency>
            <dependency>
                <groupId>junit</groupId>
                <artifactId>junit</artifactId>
            </dependency>
        </dependencies>

    然后我将其转换成Gradle脚本,结果是惊人的:

    dependencies {
        compile('org.springframework:spring-core:2.5.6')
        compile('org.springframework:spring-beans:2.5.6')
        compile('org.springframework:spring-context:2.5.6')
        compile('com.google.code.kaptcha:kaptcha:2.3:jdk15')
        testCompile('junit:junit:4.7')
    }

    注意配置从原来的28行缩减至7行!这还不算我省略的一些父POM配置。依赖的groupId、artifactId、 version,scope甚至是classfier,一点都不少。较之于Maven或者Ant的XML配置脚本,Gradle使用的Grovvy脚本杀伤力太大了,爱美之心,人皆有之,相比于七旬老妇松松垮垮的皱纹,大家肯定都喜欢少女紧致的脸蛋,XML就是那老妇的皱纹。

    关于Gradle的依赖管理起初我有一点担心,就是它是否有传递性依赖的机制呢?经过文档阅读和实际试验后,这个疑虑打消了,Gradle能够解析现有的Maven POM或者Ivy的XML配置,从而得到传递性依赖的信息,并且引入到当前项目中,这实在是一个聪明的做法。在此基础上,它也支持排除传递性依赖或者干脆关闭传递性依赖,其中第二点是Maven所不具备的特性。

    自动化依赖管理的基石是仓库,Maven中央仓库已经成为了Java开发者不可或缺的资源,Gradle既然有依赖管理,那必然也得用到仓库,这当然也包括了Maven中央仓库,就像这样:

    repositories {
        mavenLocal()
        mavenCentral()
        mavenRepo urls: "http://repository.sonatype.org/content/groups/forge/"
    }

    这段代码几乎不用解释,就是在Gradle中配置使用Maven本地仓库、中央仓库、以及自定义地址仓库。在我实际构建项目的时候,能看到终端打印的下载信息,下载后的文件被存储在USER_HOME/.gradle/cache/ 目录下供项目使用,这种实现的方法与Maven又是及其类似了,可以说Gradle不仅最大限度的继承Maven的很多理念,仓库资源也是直接拿来用。

    Gradle项目使用Maven项目生成的资源已经不是个问题了,接着需要反过来考虑,Maven用户是否能够使用 Gradle生成的资源呢?或者更简单点问,Gradle项目生成的构件是否可以发布到Maven仓库中供人使用呢?这一点非常重要,因为如果做不到这一点,你可能就会丢失大量的用户。幸运的是Gradle再次给出了令人满意的答案。使用Gradle的Maven Plugin,用户就可以轻松地将项目构件上传到Maven仓库中:

    apply plugin: 'maven'
    ...
    uploadArchives {
        repositories.mavenDeployer {
            repository(url: "http://localhost:8088/nexus/content/repositories/snapshots/") {
                authentication(userName: "admin", password: "admin123")
                pom.groupId = "com.juvenxu"
                pom.artifactId = "account-captcha"
            }
        }
    }

    在上传的过程中,Gradle能够基于build.gradle生成对应的Maven POM文件,用户可以自行配置POM信息,比如这里的groupId和artifactId,而诸如依赖配置这样的内容,Gradle是会自动帮你进行转换的。由于Maven项目之间依赖交互的直接途径就是仓库,而Gradle既能够使用Maven仓库,也能以Maven的格式将自己的内容发布到仓库中,因此从技术角度来说,即使在一个基于Maven的大环境中,局部使用Gradle也几乎不会是一个问题。

    约定优于配置

    如同Ant一般,Gradle给了用户足够的自由去定义自己的任务,不过同时Gradle也提供了类似Maven的约定由于配置方式,这是通过Gradle的Java Plugin实现的,从文档上看,Gradle是推荐这种方式的。Java Plugin定义了与Maven完全一致的项目布局:

    • src/main/java

    • src/main/resources

    • src/test/java

    • src/test/resources

    区别在于,使用Groovy自定义项目布局更加的方便:

    sourceSets {
        main {
            java {
                srcDir 'src/java'
            }
            resources {
                srcDir 'src/resources'
            }
        }
    }

    Gradle Java Plugin也定义了构建生命周期,包括编译主代码、处理资源、编译测试代码、执行测试、上传归档等等任务:

    Figure 1. Gradle的构建生命周期

    相对于Maven完全线性的生命周期,Gradle的构建生命周期略微复杂,不过也更为灵活,例如jar这个任务是用来打包的,它不像Maven那样依赖于执行测试的test任务,类似的,从图中可以看到,一个最终的build任务也没有依赖于uploadArchives任务。这个生命周期并没有将用户限制得很死,举个例子,我希望每次build都发布 SNAPSHOT版本到Maven仓库中,而且我只想使用最简单的$ gradle clean build命令,那只需要添加一行任务依赖配置即可:

    build.dependsOn 'uploadArchives'

    由于Gradle完全是基于灵活的任务模型,因此很多事情包括覆盖现有任务,跳过任务都非常易于实现。而这些事情,在Maven的世界中,实现起来就比较的麻烦,或者说Maven压根就不希望用户这么做。

    小结

    一番体验下来,Gradle给我最大的感觉是两点。其一是简洁,基于Groovy的紧凑脚本实在让人爱不释手,在表述意图方面也没有什么不清晰的地方。其二是灵活,各种在Maven中难以下手的事情,在Gradle就是小菜一碟,比如修改现有的构建生命周期,几行配置就完成了,同样的事情,在Maven中你必须编写一个插件,那对于一个刚入门的用户来说,没个一两天几乎是不可能完成的任务。

    不过即使如此,Gradle在未来能否取代Maven,在我看来也还是个未知数。它的一大障碍就是Grovvy,几乎所有 Java开发者都熟悉XML,可又有几个人了解Groovy呢?学习成本这道坎是很难跨越的,很多人抵制Maven就是因为学起来不容易,你现在让因为一个构建工具学习一门新语言(即使这门语言和Java非常接近),那得到冷淡的回复几乎是必然的事情。Gradle的另外一个问题就是它太灵活了,虽然它支持约定优于配置,不过从本文你也看到了,破坏约定是多么容易的事情。人都喜欢自由,爱自定义,觉得自己的需求是多么的特别,可事实上,从Maven的流行来看,几乎95%以上的情况你不需要自行扩展,如果你这么做了,只会让构建变得难以理解。从这个角度来看,自由是把双刃剑,Gradle给了你足够的自由,约定优于配置只是它的一个选项而已,这初看起来很诱人,却也可能使其重蹈Ant的覆辙。Maven在Ant的基础上引入了依赖管理、仓库以及约定优于配置等概念,是一个很大的进步,不过在我现在看来,Gradle并没有引入新的概念,给我感觉它是一个结合Ant和Maven理念的优秀实现。

    如果你了解Groovy,也理解Maven的约定优于配置,那试试Gradle倒也不错,尤其是它几乎能和现有的Maven系统无缝集成,而且你也能享受到简洁带来的极大乐趣。其实说到简洁,也许在不久的将来Maven用户也能直接享受到,Polyglot Maven在这方面已经做了不少工作。本文完全基于Maven的视角介绍Gradle这一构建工具的新秀,不过限于篇幅原因,无法深入Gradle的方方面面,例如Gradle也支持多模块构建,它提供了GUI操作界面,支持Grovvy(理所当然)和Scala项目等等。有兴趣的读者可以自行进一步了解。

     

    约定优于配置:

    约定优于配置convention over configuration),也称作按约定编程,是一种软件的设计规范,旨在减少软件开发人员需做决定的数量,获得简单的好处,而又不失灵活性。本质是说,开发人员仅需规定应用中不符约定的部分。例如,如果模型中有个名为Sale的类,那么数据库中对应的表就会默认命名为sales。只有在偏离这一约定时,例如将该表命名为"products_sold",才需写有关这个名字的配置。如果您所用工具的约定与你的期待相符,便可省去配置;反之,你可以配置来达到你所期待的方式

    转载于:https://www.cnblogs.com/mrzha/p/8392847.html

    展开全文
  • SBT :是非常简单并且专注在Scala语言使用,SBT依赖于Ivy 来管理.Maven : Maven是一个很好构建工具,它可以通过XML文件控制整个软件生命周期,使用项目对象模型,你可以拦截从编译到测试,打包部署软件生命周期...

    SBT :是非常简单的并且专注在Scala语言使用,SBT依赖于Ivy 来管理.

    Maven : Maven是一个很好的构建工具,它可以通过XML文件控制整个软件生命周期,使用项目对象模型,你可以拦截从编译到测试,打包和部署的软件生命周期的所有点。可以用groupId、artifactId、version组成的Coordination(坐标)唯一标识一个依赖。任何基于Maven构建的项目自身也必须定义这三项属性,生成的包可以是Jar包,也可以是war包或者ear包。

    Gradle : Gradle建立在Maven,Ant和Ivy之上的,使用maven仓库,不用xml文件,它将Ant API与Groovy语言结合在一起,使开发人员能够使用直观的DSL编写构建脚本。 通过几行代码,您可以编写一个Gradle构建脚本,它可以完成Maven可以完成的任务.借助gradle你可以用gradle语言定义你自己的任务并可以用编程方式拦截你的构建执行。如果多个依赖项指向同一个依赖项的不同版本时就会引起依赖冲突,这个时候gradle解决这种问题就表现的比maven好。

    231397ad26eb77288c7970e7951a7c59.png
    展开全文
  • MavenGradle的区别

    千次阅读 2020-04-27 20:28:10
    Java世界中主要有三大构建工具:Ant、Maven和Gradle。经过几年的发展,Ant几乎销声匿迹、Maven也日薄西山,而Gradle的发展则如日中天。笔者有幸见证了Maven的没落和Gradle的兴起。Maven的主要功能主要分为5点,分别...

    前言

    Java世界中主要有三大构建工具:Ant、Maven和Gradle。经过几年的发展,Ant几乎销声匿迹、Maven也日薄西山,而Gradle的发展则如日中天。笔者有幸见证了Maven的没落和Gradle的兴起。Maven的主要功能主要分为5点,分别是依赖管理系统、多模块构建、一致的项目结构、一致的构建模型和插件机制。Maven与Gradle在使用中各有千秋,根据使用场景择优用之。

    1. Maven 与 Gradle 对比

    maven要引入依赖 pom.xml

    <!-- https://mvnrepository.com/artifact/org.springframework.boot/spring-boot-starter-web -->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
        <version>2.1.5.RELEASE</version>
    </dependency>

    而Gradle引入 build.gradle

    implementation 'org.springframework.boot:spring-boot-starter-web'

    优点: Gradle 相当于 Maven 与 Ant 的合体 
    缺点: 对于微服务多项目的子类引用,不如 Maven

    Maven

    • 项目结构/依赖由pom.xml定义

    • 生产代码存放在src/main/java下

    • 测试代码存放在src/test/java下

    Gradle

    • 项目结构/依赖由build.gradle定义

    • 生产代码存放在src/main/java下

    • 测试代码存放在src/test/java下

     

    2. 构建流程和生命周期

    • Maven

      • 三个标准的生命周期(lifecycle)
      • 最小的运行单元是目标(goal)
      • 插件可以把自己的目标绑定在生命周期的某个阶段(phase)上
    • Gradle

      • 没有显示的生命周期
      • 最小的运行单元是任务(task),任务之间可以相互依赖
      • 可以动态地创建任务



    3. 包管理和传递性依赖

    • Maven

      • 一个包由groupId/artifactId/version确定唯一坐标
      • 包来源于中央仓库
      • 传递性依赖
        • 当某个包的的使用依赖于其他包时,Maven会自动导入所有的依赖包
    • Gradle

      • 使用Ivy的构件系统,是Maven的构件系统的超集

        Ant ivy是一个比Maven仓库更加广阔的仓库

      • 与Maven仓库兼容

    • 当出现依赖冲突时

      • Maven依赖解调遵循两个原则,路径最近原则以及定义顺序原则

      Mavenc依赖冲突.png

    • Gradle的冲突解析则是选用新的版本(新的版本一般都会向下兼容)

    总结:

    Maven

    • 稳定可靠,插件众多。(这么多年版本一直维持在3.XX,而且很久才发布一次小更新,说明他稳定且bug较少)

    • 略显啰嗦,自定义逻辑较麻烦(Maven使用xml的方式进行配置,xml的劣势繁琐就会体现在Maven上)

    • 大型项目会逐渐遇到性能问题

      • 使用Maven构建的项目都会经过几个生命流程,内部没有缓存机制,项目越来越大重新构建所花费的时间也就越长。
    • 由于Maven的开发基本靠社区支持,没有更多的资金用于继续开发维护Maven,导致开发基本停泻。

    • Gradle

      • Gradle采用代码逻辑的方式进行构建,使得它能更加的灵活。
    • Gradle内部存在缓存机制(当文件输入和输出都没改变的情况下,认为这就是没变的代码,直接进行输出。但当你改变的依赖包版本,它有时并没更新,也是缓存机制的问题),相比会快些。

    • 开发活跃,版本太多

     

     

    关注公众号:nick_coding1024
    同名原创公众号:程序大视界

     

    展开全文
  • Maven和Gradle区别

    2019-11-08 10:59:37
    Java中主要有三大构建工具:Ant、Maven和Gradle。Ant用的比较少、Maven用的相对普遍,而Gradle的发展则将是未来的一种趋势。使用Maven需要有pom.xml文件,使用Gradle需要有一个对应的build.gradle文件。 依赖管理...

    分享知识 传递快乐


    Java中主要有三大构建工具:Ant、Maven和Gradle。Ant用的比较少、Maven用的相对普遍,而Gradle的发展则将是未来的一种趋势。使用Maven需要有pom.xml文件,使用Gradle需要有一个对应的build.gradle文件。


    依赖管理系统

    Maven中用groupId、artifactId、version组成的Coordination(坐标)唯一标识一个依赖。任何基于Maven构建的项目自身也必须定义这三项属性,生成的包可以是Jar包,也可以是war包。一个典型的依赖引用如下所示:

    <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <version>4.12</version>
        <scope>test</scope>
    </dependency>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-test</artifactId>
    </dependency>

    从上面可以看出当引用一个依赖时,version可以省略掉,这样在获取依赖时会选择最新的版本。而存储这些组件的仓库有远程仓库和本地仓库之分。远程仓库可以使用世界公用的central仓库,也可以使用Apache Nexus自建私有仓库;本地仓库则在本地计算机上。通过Maven安装目录下的settings.xml文件可以配置本地仓库的路径,以及采用的远程仓库的地址。

    Gradle在设计的时候基本沿用了Maven的这套依赖管理体系。然后我将其转换成Gradle脚本,结果是惊人,在引用依赖方面变得非常简洁。

    dependencies {
        compile 'org.hibernate:hibernate-core:3.6.7.Final'
        testCompile ‘junit: junit: 4. + '
    }

    Maven和Gradle对依赖项的scope有所不同。在Maven世界中,一个依赖项有6种scope,分别是complie(默认)、provided、runtime、test、system、import。而grade将其简化为了4种,compile、runtime、testCompile、testRuntime。

    Gradle支持动态的版本依赖。在版本号后面使用+号的方式可以实现动态的版本管理。

    Maven中央仓库已经成为了Java开发者不可或缺的资源,Gradle既然有依赖管理,那必然也得用到仓库,这当然也包括了Maven中央仓库,就像这样:

    repositories {
        mavenLocal()
        mavenCentral()
        mavenRepo urls: "http://repository.sonatype.org/content/groups/forge/"
    }

    多模块构建

    Maven将一个项目分解为多个模块已经是很通用的一种方式,在Maven中需要定义个parent POM作为一组module的聚合POM。在该POM中可以使用<modules>标签来定义一组子模块。parent POM不会有什么实际构建产出。而parent POM中的build配置以及依赖配置都会自动继承给子module。

    maven创建多模块

    maven父工程pom.xml

    <?xml version="1.0" encoding="UTF-8"?>
    <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    	<modelVersion>4.0.0</modelVersion>
    	<groupId>com.xh</groupId>
    	<artifactId>ssm</artifactId>
    	<version>0.0.1-SNAPSHOT</version>
    	<packaging>pom</packaging>
    	<name>ssm</name>
    
    
    	<modules>
    		<module>ssm-mapper</module>
    		<module>ssm-service</module>
    		<module>ssm-web</module>
    	</modules>
    
    	<properties>
    		<module.name>${project.artifactId}</module.name>
    		<project.build.sourceEncoding>utf-8</project.build.sourceEncoding>
    		<spring.version>4.3.13.RELEASE</spring.version>
    	</properties>
    
    	<dependencies>
    		<!-- spring -->
    		<dependency>
    			<groupId>org.springframework</groupId>
    			<artifactId>spring-aop</artifactId>
    			<version>${spring.version}</version>
    		</dependency>
    		<dependency>
    			<groupId>org.springframework</groupId>
    			<artifactId>spring-aspects</artifactId>
    			<version>${spring.version}</version>
    		</dependency>
    		
    		.......
    	</dependencies>
    </project>

    maven子工程pom.xml

    <?xml version="1.0"?>
    <project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"
    	xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    	<modelVersion>4.0.0</modelVersion>
    	<parent>
    		<groupId>com.xh</groupId>
    		<artifactId>ssm</artifactId>
    		<version>0.0.1-SNAPSHOT</version>
    	</parent>
    	<groupId>com.xh.ssm.web</groupId>
    	<artifactId>ssm-web</artifactId>
    	<version>0.0.1-SNAPSHOT</version>
    	<packaging>war</packaging>
    	<name>ssm-web Maven Webapp</name>
    	<url>http://maven.apache.org</url>
    
    	<dependencies>
    		<!-- 引入ssm-service项目,这样项目ssm-web就可以调用ssm-service里边的类了 -->
    		<dependency>
    			<groupId>com.xh.ssm.service</groupId>
    			<artifactId>ssm-service</artifactId>
    			<version>0.0.1-SNAPSHOT</version>
    		</dependency>
    	</dependencies>
    
    	<!-- 打包时把需要的xml文件一块打进去 -->
    	<!-- 不配置以下内容,项目在tomcat下会报找不文件等错误 -->
    	<build>
    		<finalName>${project.name}</finalName>
    		<resources>
    			<resource>
    				<directory>src/main/java</directory>
    				<includes>
    					<include>**/*.properties</include>
    					<include>**/*.xml</include>
    				</includes>
    				<filtering>true</filtering>
    			</resource>
    			<resource>
    				<directory>src/main/resources</directory>
    				<includes>
    					<include>**</include>
    				</includes>
    				<filtering>true</filtering>
    			</resource>
    		</resources>
    		<pluginManagement>
    			<plugins>
    				<!-- 编译Java源码,一般只需设置编译的jdk版本 -->
    				<plugin>
    					<groupId>org.apache.maven.plugins</groupId>
    					<artifactId>maven-compiler-plugin</artifactId>
    					<version>3.6.0</version>
    					<configuration>
    						<source>1.8</source>
    						<target>1.8</target>
    						<encoding>UTF-8</encoding>
    						<testIncludes>
    							<testInclude>none</testInclude>
    						</testIncludes>
    					</configuration>
    				</plugin>
    			</plugins>
    		</pluginManagement>
    	</build>
    </project>
    

    而Gradle也支持多模块构建。而在parent的build.gradle中可以使用allprojects和subprojects代码块来分别定义里面的配置是应用于所有项目还是子项目。对于子模块的定义是放置在setttings.gradle文件中的。在gradle的设计当中,每个模块都是Project的对象实例。而在parent build.gradle中通过allprojects或subprojects可以对这些对象进行各种操作。这无疑比Maven要灵活的多。

    gradle创建多模块

    第一种:

    1、创建多个独立gradle项目

    2、编辑模块gradle-api的settings.gradle文件:

    rootProject.name = 'gradle-api'
    
    include ':gradle-core'
    project(':gradle-core').projectDir = new File(settingsDir, '../gradle-core')

    3、编辑模块gradle-api的build.gradle文件:

    apply plugin: "java" //Java的JDK
    apply plugin: "eclipse" //eclipse项目插件
    apply plugin: "war" //项目构建输出war
    
    repositories {
        // Use jcenter for resolving your dependencies.
        // You can declare any Maven/Ivy/file repository here.
        jcenter()
    }
    
    dependencies {
       compile project(':gradle-core')
    }
    

    4、完成后,执行 Gradle  -> Refresh Gradle Project

    5、结果

     

    第二种:

    1.新建Java项目

    2.添加build.gradle、settings.gradle文件

    build.gradle

    subprojects {
    	apply plugin: "java" //Java的JDK
    
    }
    

    settings.gradle
     

    rootProject.name = 'gradle-parent'
    
    include 'gradle-core'

    3、新建空文件夹

    4、将项目转换成Gradle项目

    5、复制项目路径,右击gradle-parent,导入Gradle项目

     

    总的来说,gradle相比于maven有很大的灵活性,目前gradle的使用者越来越多。而由于maven之前处于主流,并且在某些方面maven较gradle还有一些优点,所以maven和gradle并存。在github上大多数优秀的开源项目会同时提供maven和gradle两种添加依赖的方式。

     

     

     

     

     

     

     

     

     

     

    ———————————
    相互学习,共同进步
    如有不足请留言指正

    展开全文
  • dependency引入东西 作用:代码编译/运行时所需要东西 打包:项目打包后这些东西基本都在(一般都在)。 ... ...plugin引入东西 ...作用:插件,作为开发/编译/打包时一种辅助工具 ...例如:使用 maven-sou...
  • 1.你需要精通面向对象分析与设计(OOA/OOD)、涉及模式(GOF,J2EEDP)以及综合...2.你需要学习JAVA语言基础知识以及它核心类库(collections,serialization,streams,networking,multithreading,reflection,e...
  • 给你一个学习java25个目标,这个写不错!1.你需要精通面向对象分析与设计(OOA/OOD)、涉及模式(GOF,J2EEDP)以及综合模式。你应该了解UML,尤其是class,object,interaction以及statediagrams。2.你需要学习JAVA...
  • ``` <groupId>xerces <artifactId>xercesImpl <version>2.9.1 ``` ... <groupId>org.apache.maven.plugins</groupId> ...我一直搞不清楚这俩有啥区别,尤其是plugin,谁给我讲讲,谢谢了
  • Gradle是可用于Java几种构建工具之一, 但它不是唯一要考虑构建自动化工具。...Gradle是一个开源构建自动化工具, 它基于Apache Maven和Apache Ant概念进行构建。它能够构建几乎所有类型软件。它是为多项目
  • 经过这么多年发展,终于Ant几乎快销声匿迹了,Maven和Gradle在项目开发中用得比较多,其中以Gradle发展得最好。Maven主要功能是多模块构建、依赖管理系统、一致项目结构、一致项目构建模型和插件机制。在此...
  • Java世界中主要有三大构建工具:Ant、Maven和Gradle。Maven主要功能是:依赖管理系统、多模块构建、一致项目结构、一致构建模型和插件机制。maven使用groupId、artifactId、version组成Coordination(坐标)...
  • Java世界中主要有三大构建工具:Ant、Maven和Gradle。Maven主要功能是:依赖管理系统、多模块构建、一致项目结构、一致构建模型和插件机制。maven使用groupId、artifactId、version组成Coordination(坐标)...
  • gradle和maven区别

    万次阅读 2018-01-25 17:36:53
    ----------------------...Gradle和Maven都是项目自动构建工具,编译源代码只是整个过程一个方面,更重要是,你要把你软件发布到生产环境中来产生商业价值,所以,你要运行测试,构建分布、分析代码质量、甚至为
  • Gradle和Maven的区别

    2021-03-12 11:13:20
    Gradle和Maven都是项目自动构建工具,编译源代码只是整个过程一个方面,更重要是,你要把你软件发布到生产环境中来产生商业价值,所以,你要运行测试,构建分布、分析代码质量、甚至为不同目标环境提供不同...
  • Gradle和Maven区别

    千次阅读 2019-05-11 00:27:21
    Gradle和Maven都是项目自动构建工具,编译源代码只是整个过程一个方面,更重要是,你要把你软件发布到生产环境中来产生商业价值,所以,你要运行测试,构建分布、分析代码质量、甚至为不同目标环境提供不同...
  • 深入了解gradle和maven的区别

    千次阅读 2021-02-10 12:10:01
    gradle和maven都可以用来构建java程序,甚至在某些情况下,两者还可以互相转换,那么他们两个共同点不同点是什么?我们如何在项目中选择使用哪种技术呢?一起来看看吧。
  • 经过这么多年发展,终于Ant几乎快销声匿迹了,Maven和Gradle在项目开发中用得比较多,其中以Gradle发展得最好。Maven主要功能是多模块构建、依赖管理系统、一致项目结构、一致项目构建模型和插件机制。在此...
  • 目录深入了解gradle和maven的区别gradle和maven的比较可扩展性性能比较依赖的区别maven迁移到gradle自动转换转换依赖转换repositories仓库控制依赖的版本多模块项目profile属性资源处理 深入了解gradle和maven的...
  • GradleMaven的区别

    千次阅读 2020-09-27 14:44:22
    Java生态体系中有三大构建工具:Ant、Maven和Gradle。其中,Ant是由Apache软件基金会维护;Maven这个单词来自于意第绪语(犹太语),意为知识积累,最初在Jakata Turbine项目中用来简化构建过程;Gradle是一个基于...
  • Java生态体系中有三大构建工具:Ant、Maven和Gradle。其中,Ant是由Apache软件基金会维护;Maven这个单词来自于意第绪语(犹太语),意为知识积累,最初在Jakata Turbine项目中用来简化构建过程;Gradle是一个基于...
  • 首先来介绍一下这两款构建工具,Gradle是一个基于Apache AntApache Maven概念项目自动化构建开源工具。它使用一种基于Groovy特定领域语言(DSL)来声明项目设置,目前也增加了基于Kotlin语言kotlin-based DSL...
  • GradleGradle Wrapper区别和联系

    千次阅读 2019-03-08 17:50:15
    首先用一段通俗易懂但是不是非常专业话描述一下三者概念、区别和联系。 Gradle是个构建系统,能够简化你编译、打包、测试过程。熟悉Java同学,可以把Gradle类比成MavenGradle Wrapper作用是...
  • 首先用一段通俗易懂但是不是非常专业话描述一下三者概念、区别和联系。 Gradle是个构建系统,能够简化你编译、打包、测试过程。熟悉Java同学,可以把Gradle类比成MavenGradle Wrapper作用是简化...
  • 原文链接:... 总结: Gradle:是一个项目构建系统,类似于MavenGradle并不是只能用于Android,而是Android引用里Gradle。https://docs.gradle.org/current/userguide/userguide_single.html Gradle ...

空空如也

空空如也

1 2 3 4 5 ... 9
收藏数 170
精华内容 68
关键字:

maven和gradle的区别