maven开发过程管理之实践一（开发环境与代码隔离 generatesources）

          在上一篇博客使用maven进行开发过程管理之准备篇中提到了maven的基本概念。IT男罗书全觉得概念我是懂了，但是那些东西似乎离我很远啊。先开发再说吧，

   于是IT男罗书全就在svn上取了源代码，并开始导入到本地开发环境中去。三下五除二，点击import,出现熟悉的导入界面。

      导入失败，这是怎么回事？问了同事才知道，公司使用的是idea开发环境，而自己用的是eclipse.怎么办呢？放弃自己心爱的eclipse,真痛苦，而且不熟悉会导致开发效率较低。有没有两全其美的办法呢？有的。

       想想大家做数据访问层时，hibernate是怎么实现兼容不同数据库的呢？创立中间的一种语言，比如hql,在配置里得知连接的数据库具体类型时，调用其适配功能实现hql-->相应数据库sql的转换。Maven的原理也是类似，提供了pom描述文件来对项目的组成要素做了说明，如src,target,lib等的位置，在命令中得知需要适配哪个开发环境中时，就可以转换过去。这样就给具体开发提供了一定的灵活性。在maven中提供了转换到主流环境eclipse的插件maven-eclipse-plugin，相应转换命令是eclipse:eclipse.对于IDEA也提供了转换到IDEA的插件maven-idea-plugin，转换到相应开发环境的命令是idea:idea.

      IT男罗书全在命令行中进入项目所在根目录下，运行maven eclipse:eclipse，然后导入，成功了。IT男罗书全欣喜万分，在欣喜万分的同时，又疑惑了，maven是怎么做的转换的呢？

       

其实任何开发环境都是要识别项目特性，才能顺利进行开发的。比如在eclipse项目里面，可以看到有几个基本要素，如像src/main/java文件夹上有个包的，就是源代码目录，源代码目录就是放置用户编写源代码的位置。像target目录，就是生成目标文件的地方，如class文件等。Referenced Libraries就是放置项目依赖的jar包的地方等。

这些项目描述都是在.classpath和.project中说明的。例如.classpath文件：

显然的，可以得出以下几个结论:

1.   kind="src"，path=src/main/java,里面说明了src的位置；    
2.   kind="output”,path=target/classes,说明了target目录的位置；
3.   kind=“var”,说明的是一个lib的位置。

.project文件中说明了此项目需要的插件，以及使用的builder.

  那么maven又是怎么做的呢？其实他也是分析了所有开发环境的共性，而对其概念作了抽象。在下面的代码中说明：

org.apache.maven.plugin.ide.AbstractIdeSupportMojo.java

          boolean processProject = setup();
        if ( !processProject )
        {
            return;
        }
        // 解析得到所有的依赖，形成lib引用
        IdeDependency[] deps = doDependencyResolution();
        //绑定source代码和javadoc
        resolveSourceAndJavadocArtifacts( deps );
        //生成特定开发环境的配置文件
        writeConfiguration( deps );
        reportMissingArtifacts();

这是个template模式的实现，具体的开发环境只要继承AbstractIdeSupportMojo来override其中的writeConfiguration(deps)来生成具体的配置文件。

    因此,maven 对开发环境与源代码的隔离提供了强有力的插件支持，兼顾了不同程序员的爱好，从而提高了整体的开发效率。

推荐书籍：

1.maven书籍：Maven实战--徐晓斌

2.21届JOLT大奖--开发过程方法论：持续交付:发布可靠软件的系统方法

参考资料：

Apache Maven2 简介