JAE构建系统用户手册

JAE构建系统用户手册Maven构建方式
作者：桃谷
更新时间：2013-10-21
版本：0.2
一、预热知识 (3)
二、术语解释 (3)
三、实现限制 (3)
1. 不支持goal：install deploy (3)
2. 不提供官方的Maven仓库镜像 (4)
3. 不提供全局（通用）Maven settings.xml文件 (4)
4. Maven构建脚本文件（pom.xml）限制 (4)
四、可能的问题 (4)
1. 不支持二方依赖 (4)
2.无法获取三方依赖 (5)
3. 非Maven依赖 (5)
五、解决方法 (5)
1. 解决二方依赖 (5)
2. 解决三方依赖 (7)
3. 解决特殊依赖 (10)
一、预热知识
如果您是第一次使用Maven，请首先学习以下资源：
/view/80e4c3136edb6f1aff001fdd.html
如果您已经学习或者已熟悉Maven的工作原理以及使用方法，请忽略。

二、术语解释
二方依赖：是指独立于当前应用，由同一ISV开发的依赖资源
三方依赖：有第三方开发的依赖资源，例如Apache Commons Language 三方类库（commons-lang:commons-lang:2.3:jar）
Maven构建脚本文件：pom.xml文件
三、实现限制
JUAE平台支持Maven构建方式，支持最新Maven 3.0.5版本，由于特殊原因，做了以下限制：
1. 不支持goal：install deploy
由于Maven构建在JUAE平台内部构建，多个应用可能在相同机器上面构建，为了防止多个应用工程相互冲突（多个应用groupId、artifactId、version重复），同时
也防止非法源码泄漏的问题（利用groupId、artifactId、version获取源码）。

未来很有可能支持ISV独立Maven独立仓库时，可以解除当前限制
2. 不提供官方的Maven仓库镜像
目前官方无法提供Maven仓库镜像
未来很有可能支持ISV独立Maven独立仓库时，可以解除当前限制
3. 不提供全局（通用）Maven settings.xml文件
目前实现不支持他全局（通用）Maven settings.xml，尽管如此，应用开发者很有可能自行添加私有Maven仓库镜像配置到settings.xml文件中，这样，线下和线上的配置不一致，可能导致应用工程源码线上构建时，无法获取第三方依赖。

4. Maven构建脚本文件（pom.xml）限制
Maven构建脚本文件（pom.xml）必须存放在应用工程的根目录下，并且文件名称必须为”pom.xml”
四、可能的问题
1. 不支持二方依赖
由于不支持install和deploy无法将二方应用依赖部署仓库中去，同时没有官方Maven仓库镜像，因此也无法下载相应的依赖
2.无法获取三方依赖
由于官方无法提供Maven仓库镜像或者配置了私有Maven仓库地址，当应用工程源码线上构建时，无法获取第三方依赖
3. 非Maven依赖
由于应用需要依赖无法从Maven仓库获取，或者压根就不存在
五、解决方法
1. 解决二方依赖
在上章中提到，构建系统不支持二方依赖。

因此，可以通过将二方应用工程源码作为当前应用工程。

例如：当前应用工程project-test
其Maven原信息为：
<groupId>com.acem</groupId>
<artifactId>project-test</artifactId>
<version>1.0.0</version>
所依赖二方jar包：common-service-2.0.0.jar,对应的Maven原信息为：
<groupId>mon</groupId>
<artifactId>common-service</artifactId>
<version>2.0.0</version>
可common-service为二方应用工程，那么，如果要解决二方依赖的问题，解决的办法是：将common-service工程作为project-test的子模块。

具体操作步骤如下：
首先，将common-service工程目录复制到project-test工程目录（请注意清理svn 或者git元信息目录，防治版本控制混乱）
然后，将common-service工程配置成project-test工程的子模块，在project-test 工程pom.xml文件添加配置：
...
<modules>
<module>common-service</module>
<!--其他子模块信息-->
...
</modules>
...
最终，添加依赖管理配置：
<dependencyManagement>
<dependencies>
<dependency>
<groupId>mon</groupId>
<artifactId>common-service</artifactId>
<version>2.0.0</version>
</dependency>
<!-- 其他依赖-->
...
</dependencies>
</dependencyManagement>
2. 解决三方依赖
由于非官方公用Maven仓库稳定性无法保证，因此构建系统Maven settings.xml 文件仅支持官方公共仓库，即默认仓库配置（/）。

强烈推荐应用开发人员尽可能地使用官方仓库中的三方依赖配置。

因此，在应用Maven工程构建（或迁移）时，尽可能地在中央Maven仓库中搜索
（/）。

例如，应用工程依赖struts 2，因此，搜索关键字”struts”，其结果页为：/#search%7Cga%7C1%7Cstruts
查找版本等于2的结果记录：
点击"2"的连接，进入配置详情页面：
/#artifactdetails%7Corg.apache.struts%7Cstruts-parent %7C2%7Cpom
复制红色区域的内容到应用工程的Maven依赖配置区。

如果第三方依赖无法在中央仓库获取的话，允许在应用工程pom.xml文件中，添加合理的仓库配置信息，例如：
<repositories>
<repository>
<id>ibiblio</id>
<name>Ibiblio Maven Repository</name>
<url>/maven2</url>
<layout>default</layout>
</repository>
<repository>
<id></id>
<name>Slowly office site</name>
<url>/maven/2/</url>
</repository>
</repositories>
3. 解决特殊依赖
本节中的特殊依赖是指当无法从Maven仓库下载的依赖资源。

幸运地是，Maven 提供了自定义本地仓库方式处理特殊依赖问题。

接下来，将详细介绍操作方法。

Maven的仓库配置比较灵活，可以定义远程仓库，一般通过HTTP协议获取。

同时，还可以配置本地仓库，利用的是file协议。

实际上，自定义本地仓库与Maven本地仓库的目录结构。

以Google guava工程为例，其依赖配置信息为：
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>14.0.1</version>
</dependency>
笔者本地Maven仓库路径为：D:\software\dev\java\maven_repository\，Maven依赖目录结构规则如下：
1. groupId目录结构
以上述Google guava工程为例，groupId与Java package规则类似，本例中的groupId为”com.google.guava“，因此，groupId目录结构如下：
-com
-google
-guava
2. artifactId目录结构
相对于groupId而言，artifactId目录结构相对简单，artifactId即为目录名称。

因此，本例artifactId目录名称为guava，并且在groupId目录下，其目录结构为：-com
-google
-guava
-guava
3. version目录结构
与artifactId目录结构规则一样，version即为目录名称。

version目录存放在artifactId目录下。

因此，本例中的version目录结构为：
-com
-google
-guava
-guava
-14.0.1
4. 资源文件名
具体依赖资源文件就存放在version目录下，并且其名称模式
为:${artifactId}-${version}.${packaging}
其中，packaging为pom.xml中的打包类型配置，例如：pom,jar,war,ear等。

故此规则，本例中的资源文件名为：guava-14.0.1.jar
了解此规则之后，最终展示笔者本地maven仓库中guava-14.0.1.jar路径：
第一步：配置本地仓库
在应用工程pom.xml追加本地仓库配置，请参考下面红色字体部分：<repositories>
<repository>
<id></id>
<name>Slowly office site</name>
<url>/maven/2/</url>
</repository>
<!-- 本地Maven仓库-->
<repository>
<id>Project Repository</id>
<name>My Project Repository</name>
<url>file://${project.basedir}/project-repos</url>
</repository>
</repositories>
在id为”Project Repository”的仓库配置中，其url为：
file://${project.basedir}/project-repos，其中，${project.basedir}表示当前工程文件路径，url配置说明本地仓库将会以当前工程的子目录project-repos为跟路径。

实际上，url可以是任意目录路径，之所以要使用占位符${project.basedir}，目的在于确保依赖的资源存放在当前工程目录下，线上构建时能够正确的定位。

第二步：创建目录结构
回顾project-test工程例子，其依赖版本2.0.0的common-service jar包，其依赖配置为：
<groupId>mon</groupId>
<artifactId>common-service</artifactId>
<version>2.0.0</version>
假设project-test工程目录路径为D:\project-test的话，根据自定义仓库url 配置file://${project.basedir}/project-repos，即project-test自定义仓库目录为D:\project-test\project-repos。

套用Maven依赖目录规则，创建依赖目录：com\acem\common\common-service\2.0.0，故完整的目录路径为
D:\project-test\project-repos\com\acem\common\common-service\2.0.0，注意该路径为依赖资源父目录路径，并非资源路径。

第三步：资源重命名
当依赖目录创建完毕之后，将依赖资源jar包重名成：
common-service-2.0.0.jar。

如果资源文件名称已如此，无需执行本步骤。

第四步：移动资源
将common-service-2.0.0.jar文件复制到自定义本地仓库依赖目录下：D:\project-test\project-repos\com\acem\common\common-service\2.0.0
完成上述四步骤，应用工程即可获取特殊依赖。