gradle和maven有什么用?分别有什么区别
3个回答
展开全部
Gradle和Maven都是项目自动构建工具,编译源代码只是整个过程的一个方面,更重要的是,你要把你的软件发布到生产环境中来产生商业价值,所以,你要运行测试,构建分布、分析代码质量、甚至为不同目标环境提供不同版本,然后部署。整个过程进行自动化操作是很有必要的。
整个过程可以分成以下几个步骤:
编译源代码
运行单元测试和集成测试
执行静态代码分析、生成分析报告
创建发布版本
部署到目标环境
部署传递过程
执行冒烟测试和自动功能测试
如果你手工去执行每一个步骤无疑效率比较低而且容易出错,有了自动化构建你只需要自定义你的构建逻辑,剩下的事情交给工具去完成。
虽然两者都是项目工具,但是maven现在已经是行业标准,Gradle是后起之秀,很多人对他的了解都是从android studio中得到的,Gradle抛弃了Maven的基于XML的繁琐配置,众所周知XML的阅读体验比较差,对于机器来说虽然容易识别,但毕竟是由人去维护的。取而代之的是Gradle采用了领域特定语言Groovy的配置,大大简化了构建代码的行数,比如在Maven中你要引入一个依赖:
<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给我最大的有点是两点。其一是简洁,基于Groovy的紧凑脚本实在让人爱不释手,在表述意图方面也没有什么不清晰的地方。其二是灵活,各种在Maven中难以下手的事情,在Gradle就是小菜一碟,比如修改现有的构建生命周期,几行配置就完成了,同样的事情,在Maven中你必须编写一个插件,那对于一个刚入门的用户来说,没个一两天几乎是不可能完成的任务
整个过程可以分成以下几个步骤:
编译源代码
运行单元测试和集成测试
执行静态代码分析、生成分析报告
创建发布版本
部署到目标环境
部署传递过程
执行冒烟测试和自动功能测试
如果你手工去执行每一个步骤无疑效率比较低而且容易出错,有了自动化构建你只需要自定义你的构建逻辑,剩下的事情交给工具去完成。
虽然两者都是项目工具,但是maven现在已经是行业标准,Gradle是后起之秀,很多人对他的了解都是从android studio中得到的,Gradle抛弃了Maven的基于XML的繁琐配置,众所周知XML的阅读体验比较差,对于机器来说虽然容易识别,但毕竟是由人去维护的。取而代之的是Gradle采用了领域特定语言Groovy的配置,大大简化了构建代码的行数,比如在Maven中你要引入一个依赖:
<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给我最大的有点是两点。其一是简洁,基于Groovy的紧凑脚本实在让人爱不释手,在表述意图方面也没有什么不清晰的地方。其二是灵活,各种在Maven中难以下手的事情,在Gradle就是小菜一碟,比如修改现有的构建生命周期,几行配置就完成了,同样的事情,在Maven中你必须编写一个插件,那对于一个刚入门的用户来说,没个一两天几乎是不可能完成的任务
2016-04-12 · 做真实的自己 用良心做教育
千锋教育
千锋教育专注HTML5大前端、JavaEE、Python、人工智能、UI&UE、云计算、全栈软件测试、大数据、物联网+嵌入式、Unity游戏开发、网络安全、互联网营销、Go语言等培训教育。
向TA提问
关注
展开全部
都是自动构建工具,但是完全是两个产品。Maven应该目前在Java企业级开发中占的比重比较大,Gradle是后起之秀,Google的Android Studio主推的就是Gradle。
Gralde吸收了Maven与Ant的优点,可以列举出很多。然而大量的实践与思考发现Maven相比于Gradle的不灵活,正是它的优点,避免了大量聪明的Build Engineer的出现。
Gralde吸收了Maven与Ant的优点,可以列举出很多。然而大量的实践与思考发现Maven相比于Gradle的不灵活,正是它的优点,避免了大量聪明的Build Engineer的出现。
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
2016-03-23 · 百度知道合伙人官方认证企业
育知同创教育
1【专注:Python+人工智能|Java大数据|HTML5培训】 2【免费提供名师直播课堂、公开课及视频教程】 3【地址:北京市昌平区三旗百汇物美大卖场2层,微信公众号:yuzhitc】
向TA提问
关注
展开全部
1.面向未来,就目前的趋势而言,gradle或者maven正逐渐演化为一种标准。尤其是国际上。比如你去spring官网看demo,它们一般提供基于这两种的源码,还有android开发,很多流行的库,demo演示都是通过gradle搭建的,你不懂gradle就很难跟它们接轨。这显然是固步自封的表现。
2.极细的粒度,给你更大的发挥空间。你用eclipse的run的时候,你并不知道eclipse是怎么执行的,即便你知道,但是不可能轻易结合自己的代码逻辑。举个例子:我需要在run java项目的时候,把flex项目先编译好,放到web目录下。类似于这样,大部分情况下,光靠IDE自己的功能就力不从心了。 但是gradle给了你两个维度的机会,让你能干的更多。 第一 task的dependsOn、finalizedBy 让你可以把各种工作串行连接;第二 绝大多数插件是开源的,也就是用的不爽,你自己可以改,那样就更灵活了。当然这只是冰山一角。
3.协作,一个个build文件,描述项目依赖,插件,显然更具有一致性。再也不需要把那些讨厌的jar包提交到git了,要知道git里面存放二进制简直就是灾难。还有,甚至可以通过gradle跟,非程序员交流,比如你想让美工可以自己测试修改并在项目里面看最终效果。这时候你让她装个idea,估计她会很不情愿。但是,你可以通过gradle,告诉她,把素材覆盖到某某文件之后,只要在控制台来个gradle run,刷新页面就能看到效果了。(仅是个例子,可能不严谨)
4.布道groovy,gradle所使用的语言,也许groovy并不能算是jvm里的屠龙刀,但是也绝对可以算是一把锋利的匕首。相信我,作为一个java程序员,试着在代码中融入groovy,一定乐趣无限。尤其是还能用在android项目。
2.极细的粒度,给你更大的发挥空间。你用eclipse的run的时候,你并不知道eclipse是怎么执行的,即便你知道,但是不可能轻易结合自己的代码逻辑。举个例子:我需要在run java项目的时候,把flex项目先编译好,放到web目录下。类似于这样,大部分情况下,光靠IDE自己的功能就力不从心了。 但是gradle给了你两个维度的机会,让你能干的更多。 第一 task的dependsOn、finalizedBy 让你可以把各种工作串行连接;第二 绝大多数插件是开源的,也就是用的不爽,你自己可以改,那样就更灵活了。当然这只是冰山一角。
3.协作,一个个build文件,描述项目依赖,插件,显然更具有一致性。再也不需要把那些讨厌的jar包提交到git了,要知道git里面存放二进制简直就是灾难。还有,甚至可以通过gradle跟,非程序员交流,比如你想让美工可以自己测试修改并在项目里面看最终效果。这时候你让她装个idea,估计她会很不情愿。但是,你可以通过gradle,告诉她,把素材覆盖到某某文件之后,只要在控制台来个gradle run,刷新页面就能看到效果了。(仅是个例子,可能不严谨)
4.布道groovy,gradle所使用的语言,也许groovy并不能算是jvm里的屠龙刀,但是也绝对可以算是一把锋利的匕首。相信我,作为一个java程序员,试着在代码中融入groovy,一定乐趣无限。尤其是还能用在android项目。
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
推荐律师服务:
若未解决您的问题,请您详细描述您的问题,通过百度律临进行免费专业咨询