`

最近遇到几个maven问题

阅读更多
对依赖的管理是maven的一个重要的功能. 依赖又分为间接依赖和直接依赖. 比如项目a, 依赖jar包b, b又依赖c, 在加入jar包b的依赖的时候, maven会自动加入对jar包c的依赖. 这个就是所谓的传递性依赖, 而不用我们自己去指定. 这个为我们构造开发环境带来了不少便利.

目前我碰到了两个依赖的问题:一个是关于aspectj的依赖, 一个是关于仓库中pom.xml文件未设置依赖关系导致依赖失败.

关于aspectj依赖的问题, 这里(http://guoyong.org/2009/04/24/365)有一个解决方案, 原来跟maven-eclipse-plugin的版本有关.在2.6版本里面, 这个版本要求eclipse安装aspectj的相关插件(貌似是这样, 我没有试验^_^), 这样就不需要在eclipse java工程的.classpath中添加aspectj的一些依赖了.

还有一次碰到一个很奇怪的问题, 在我的一个eclipse java工程里面有些jar包maven死活没有帮我建立传递性依赖(具体表现是在.classpath文件中没有加入传递依赖的classpathentity, 导致运行时出现NoClassDefFoundError异常). 而有些jar则没有这个问题, 经过分析之后, 终于发现问题所在, 原来maven建立依赖关系是根据仓库里面与jar包所在的同级文件夹下的pom.xml文件来建立依赖的, 最初以为是根据jar里面的META-INF里面的pom.xml文件建立依赖关系, 后来发现我错了:(.因此我们在将jar提交到maven仓库的时候, pom.xml文件的依赖正确设置是非常重要的.

另一个问题跟maven-eclipse-plugin升级之后对java工程文件的位置强制约束有关, 在maven-eclipse-plugin 2.6版本中, maven强制要求src/main/java目录下只能放置java文件, 而所有的配置文件必须放在src/main/resources目录下,
因为通过maven构建的eclipse java工程的.classpath文件中会是这样:
<classpathentry kind="src" path="src/main/java" including="**/*.java"/>

而前一个版本中则没有including的要求, 生成的.classpath文件会是这样:
<classpathentry kind="src" path="src/main/java"/>

这样导致编译输出的classes目录下只有java, 而没有非java文件.解决办法是指定一下maven-eclipse-plugin版本:
<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-eclipse-plugin</artifactId>
	<version>2.5.1</version>
</plugin>

这个只是一个权宜之计, 问题不是很严重(主要是测试的时候会出现找到指定的文件), 按照maven的要求来放置文件才是最合理的做法.
分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics