公司私有的maven仓库在访问时是需要用户名密码的。访问这种仓库的时候需要在build.gradle中配置repository用户权限，如下面这样： 但是如果每个项目都要配置一次的话，多少会让人有些觉得不耐烦。所以可以这个配置也可以在init中完成。打开gradle安装目录->init.d目录，创建init配置文件“init.gradle”，配置详情如下： 这样配置以后，就可以去掉在build.gradle中的repository相关的配置了，算是简化了build.gradle的配置了。
[阅读更多...]-
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———————-
[阅读更多...] -
理解AOP
说下我对AOP的理解：AOP是给程序添加统一功能的一种技术。在代码层面上来说，AOP就是在必要的业务代码中织入业务无关的、统一的代码的一种技术。在实现AOP的时候，通常努力争取的目标是对业务代码无侵入或是低侵入。 平时用得比较多的是Spring中的AOP实现，还有一些比如Spring中的shiro权限验证，@Cachable注解等在某种程度上也可以认为是AOP。在Spring AOP之外还有很多其他的实现方式。 在了解AOP实现方案之前有必要看一下java类编译加载的过程。 java类编译的过程如下： .java文件 –> 编译 –> .class文件 –> 载入虚拟机 在虚拟机中加载使用类的过程如下： 装载 –> 验证 –> 准备 –> 解析 –> 初始化 –> 使用 –>卸载 上面所述的过程中，通常可以在编译和装载这两个环节向原始代码中织入AOP代码。 编译环节织入代码往往需要定制的编译器，如使用AspectJ的时候，就可以通过AspectJ的编译器ajc来完成AOP代码的织入。这个环节织入的代码class文件中就有体现。 装载环节实现代码织入的方式比较多，大致有这么几种： 基于JVMTI Agent方式； 替换默认的系统类加载器； 使用自定义类加载器； 使用动态代理。 jvmtgi方式是一种侵入度很低的形式，只需要在启动时添加一些特定的启动参数，如javaagent。我曾经写过一个java方法运行时间统计程序：jspy-agent，就是用这种方式在在java方法中织入计时代码。这种方式需要对字节码文件进行操作，目前的字节码操作框架有asm、bcel、javassist等。 使用自定义类加载器替换默认系统类加载器也只需要添加一个启动参数：-Djava.system.class.loader=com.your.CustomClassLoader。前提是需要自定义一个类加载器。当然自定义类加载器也不只是有这一种使用方式。 关于动态代理，目前用的比较多的就是JDK动态代理和CGlib了，相关的资料一抓一大把，不说了。 大体上就是这些了。不过还有一个问题，想和大家一起想想：java设计模式中的代理模式、装饰模式是不是也算是AOP的一种实现呢？ 参考文档： SpringAOP织入：https://blog.csdn.net/wuliusir/article/details/32916419 JVMTI Agent：https://www.ibm.com/developerworks/cn/java/j-lo-jpda2/ #############
[阅读更多...]