• Gradle访问需要用户名密码的仓库

    公司私有的maven仓库在访问时是需要用户名密码的。访问这种仓库的时候需要在build.gradle中配置repository用户权限,如下面这样: 但是如果每个项目都要配置一次的话,多少会让人有些觉得不耐烦。所以可以这个配置也可以在init中完成。打开gradle安装目录->init.d目录,创建init配置文件“init.gradle”,配置详情如下: 这样配置以后,就可以去掉在build.gradle中的repository相关的配置了,算是简化了build.gradle的配置了。

    [阅读更多...]
  • 使用Gradle构建scala多模块工程

    前段时间终于无法忍受sbt慢如龟速的编译打包速度了。稍稍调研了一下,就果断切换到了gradle。由于调研得比较匆忙,在使用过程中遇到了各种问题。好在最后都能解决了。 我这里使用scala主要是用来编写spark job。由于我自己的一些需要,这些job中有几个是多模块的。在这里简单解释一下如何使用gradle构建scala多模块项目。 这里用我最近开发的项目来做说明。项目名称是consumer-portrait-job,有两个子模块:common和compute。 首先在项目根目录下创建一个settings.gradle文件,这个文件主要用来描述项目名称及子模块信息: 然后再创建一个build.gradle文件。这个文件描述了主项目及子项目的一些通用配置。配置如下: 在这个配置文件中包含两个大的模块:allprojects和subprojects。 allprojects中的配置是所有项目共享的(包含根项目)。在这里,我定义了项目的groupId和version等信息,并应用了gradle的idea插件。 subprojects的配置是所有子项目通用的。 在subprojects中的第一行声明了使用gradle的scala插件。 接下来的配置项“sourceCompatibility”声明了编译时使用的jdk版本;“targetCompatibility”确保了编译生成的class与指定版本的jdk兼容。 在ext中声明了子项目中可以使用的一些变量。我这里是声明了scala和spark的版本。 repositories项配置了当前项目可以使用的仓库。这里使用的第一个仓库是本机的maven库,第二库是ali提供的repository服务,第三个库是maven中央库。(曾经研究过如何让gradle和maven公用同一个本地仓库,不过最后也是不了了之)。 dependencies中声明了所有子模块都需要使用的依赖项。这里用到了scala库和spark库,这两个库只会在编译期用到,所以声明使用的依赖类型是compileOnly(这种依赖类型是gradle Java插件独有的,gradle scala插件继承自java插件,所以也可以使用)。 task mkdirs是一个自定义任务。在根项目配置完settings.gradle和build.gradle后,执行“gradle mkdirs”命令完成子模块目录的创建工作。 在两个子模块common和compute下创建build.gradle文件并做配置。 common模块的build.gradle配置详情: 这里只是声明了一下commons模块独有的依赖项。 compute模块是启动模块,在该模块中有spark任务的驱动类。该模块的build.gradle配置详情: 配置中的第一行dependencies仍然是配置compute模块的依赖项。其中略需注意的是对common模块的依赖。 接下来的jar声明指明了将该模块打成的jar包的名称。脚本中需要根据包名来调用模块生成的包,默认生成的包名会带上版本信息,不太合适。 最后是一个自定义任务。该任务的目标是将一些必要的jar和其他文件打成一个zip包,以便于上传任务到执行服务器。任务中的第一个部分是将一些运行时依赖打入zip包中的lib目录,使用include关键字提示包含运行时依赖中指定名称的包,也可以使用exclude关键字排除一些包。第二部分是将生成的jar和本地doc目录中的文件打入zip包的根目录。 就这样。有空再写个示例项目留着参考。 ——————–END———————-

    [阅读更多...]
  • Gradle中的“provided”

    maven中值为provided的scope,可以让我们声明一个只在编译时使用的非传递性的依赖。在gradle中我们可以声明compileOnly依赖来实现类似的效果(需要java插件)。示例如下: compileOnly声明的使用场景可以一言蔽之:声明的依赖只在compile阶段使用,但是不会在runtime阶段用到,并且这种依赖也是非传递性的。 ######

    [阅读更多...]
  • Gradle依赖排除

    在引用依赖时经常会有这样的问题:某些间接引用的依赖项是不需要的;产生了依赖冲突。此时需要排除一些依赖。 下面的内容介绍了几种在gradle中排除依赖的方式。 在dependency中排除 这种方式是粒度最细的,也是最为繁琐的。此时可以考虑全局设置。 在全局配置中排除 全局配置是在configuration中完成的。 禁用传递依赖 禁用传递依赖需要将属性transitive设置为false。可以在dependency中禁用传递依赖,也可以在configuration中全局禁用: 还可以在单个依赖项中使用@jar标识符忽略传递依赖: 强制使用某个版本 如果某个依赖项是必需的,而又存在依赖冲突时,此时没必要逐个进行排除,可以使用force属性标识需要进行依赖统一。当然这也是可以全局配置的: 在打包时排除依赖 先看一个示例: 代码表示在打zip包的时候会过滤掉名称中包含“unwanted”和“log”的jar包。这里调用的exclude方法的参数和前面的例子不太一样,前面的参数多是map结构,这里则是一个正则表达式字符串。 也可以使用在打包时调用include方法选择只打包某些需要的依赖项: 始终选择最新的依赖的项 最后这个特性和排除依赖没有什么关系,只是顺带说一下。 在依赖项中使用加号+,可以在构建时检查远程仓库是否存在该依赖的新版本,如果存在新版本则下载选用最新版本。更有用的是可以指定依赖某个大版本下的最新子版本,如1.+表示始终采用依赖的1.x序列的最新版本。 示例如下: 就这样。 #####

    [阅读更多...]