maven的烦恼

maven的苦恼
maven对于java项目的开发代码组织无疑是很power的，简单清晰的pom配置，不用像ant那样关注复杂细节，灵活的组合编译打包等等，带来很多的便利。但也有让人很窝火的时候，尤其是你对它不是很了解情况下，非常容易出问题。今天就遇到一个版本变量问题。

通常组织一个比较大型的项目代码，目录数量还有层次深度是很多且复杂的，拆分为子项目，子项目下面又有子子项目，比如现在我们的项目

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专家做后盾，否则就只有自个儿啃骨头。

查看更多 下一篇