通常组织一个比较大型的项目代码,目录数量还有层次深度是很多且复杂的,拆分为子项目,子项目下面又有子子项目,比如现在我们的项目
project-main
|
--client
|
--server
|_serv-project1
|
--serv-project2
|
|-serv-project2-sub1
|
|-serv-project2-sub2
...
项目结构分了四级,现在有这样个需求,就是由project-main这一层来定义整个项目的版本号,子项目都需遵循project-main定义的版本号。那么就可以有两种方式来实现:1)子(子)项目中hard code版本号,这个方式当版本升级时非常麻烦,届时替换不可避免,当pom文件数巨大的时候很头疼。2)在project-main中,声明属性变量,例如:
<properties> <main.version>1.0</main.version> </properties>
这么做的话,在子(子)项目中可以通过变量${main.version}引用。方式2似乎问题很好解决了,但是,但是的是,在开发当中,尤其是配合ide开发的时候,有个问题就此浮现了。比如,想单独对serv-project2-sub2进行maven build,这种要求很合理吧,遗憾的是,这时候maven找不到变量${maven.version}了,它会去repository找一些依赖,比如serv-project2-sub2依赖xx,它会去这么找xx-${maven.version},当然了,它是找不到的,因为${maven.version}无法识别。这个问题让人非常困惑,为什么maven不去做变量替换呢?这个我没搞懂,不过,在编译maven的时候,如果你的version是赋给变量,那么maven提示这是不鼓励的,可能有它的理由,但是这点不得而知。而且最古怪的是,当无法解析变量的时候,ide+maven提示的错误是很让人摸不着头脑,比如报slf4j的错误,往slf4这条路解决把你引入死胡同,让你一通抓狂。
这个问题很纠结,目前没有找到好的方法,所以只能暂时把版本号hardcode,即方式1。有好办法再写出来。
通常项目对代码模块化要求不是那么高的时候,我建议不需要用maven,只需要一个项目工程,利用IDE中的ant进行build就好,省不少事。要玩maven,根据项目情况定,并且你要有一个maven专家做后盾,否则就只有自个儿啃骨头。