在上一篇博客使用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男罗书全在命令行中进入项目所在根目录下，运行mvn eclipse:eclipse，然后导入，成功了。IT男罗书全欣喜万分，在欣喜万分的同时，又疑惑了，maven是怎么做的转换的呢？
其实任何开发环境都是要识别项目特性，才能顺利进行开发的。比如在eclipse项目里面，可以看到有几个基本要素，如像src/main/java文件夹上有个包的，就是源代码目录，源代码目录就是放置用户编写源代码的位置。像target目录，就是生成目标文件的地方，如class文件等。Referenced Libraries就是放置项目依赖的jar包的地方等。
这些项目描述都是在.classpath和.project中说明的。例如.classpath文件：
显然的，可以得出以下几个结论:
- kind="src"，path=src/main/java,里面说明了src的位置；
- kind="output”,path=target/classes,说明了target目录的位置；
- kind=“var”,说明的是一个lib的位置。
.project文件中说明了此项目需要的插件，以及使用的builder.
那么maven又是怎么做的呢？其实他也是分析了所有开发环境的共性，而对其概念作了抽象。在下面的代码中说明：
org.apache.maven.plugin.ide.AbstractIdeSupportMojo.java
1: boolean processProject = setup();
2: if ( !processProject )
3: {
4: return;
5: }
6: // 解析得到所有的依赖，形成lib引用
7: IdeDependency[] deps = doDependencyResolution();
8: //绑定source代码和javadoc
9: resolveSourceAndJavadocArtifacts( deps );
10: //生成特定开发环境的配置文件
11: writeConfiguration( deps );
12: reportMissingArtifacts();
这是个template模式的实现，具体的开发环境只要继承AbstractIdeSupportMojo来override其中的writeConfiguration(deps)来生成具体的配置文件。
因此,maven 对开发环境与源代码的隔离提供了强有力的插件支持，兼顾了不同程序员的爱好，从而提高了整体的开发效率。