本文转载自：http://blog.csdn.net/qqhjqs/article/details/51491516
使用maven管理web项目中jar包之间的依赖，非常的方便好用，但是有时也会出现问题
项目里用net.sf.json
使用maven配置了以下jar包
jakarta commons-lang 2.5
jakarta commons-beanutils 1.8.0
jakarta commons-collections 3.2.1
jakarta commons-logging 1.1.1
ezmorph 1.0.6
如果将以上的jar包放在非maven管理的项目里的lib下，不会出现任何问题
但是在maven下，当代码跑到
JSONObject.from(str)的时候，控制台报错，错误内容如下：
java.lang.NoClassDefFoundError: org/apache/commons/lang/exception/NestableRuntimeException
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at org.apache.catalina.loader.WebappClassLoaderBase.findClassInternal(WebappClassLoaderBase.java:2496)
at org.apache.catalina.loader.WebappClassLoaderBase.findClass(WebappClassLoaderBase.java:860)
at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1302)
at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1167)
at com.iquant.simulated.messaging.StrategyManageTopicListener.processMessage(StrategyManageTopicListener.java:13)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
刚开始我以为是包没有下载成功，或者是版本不对，当时按着这个思路，搞了大半天，确定jar包都下载了，版本也都对。
突然想到，将字符串抽出来，在main方法里跑一下，看是否成功，结果和我想的一样，是成功的，那也就是说在web运行的过程中
"找不到相关的包"
按照这个思路走了下去各种百度各种查。
然后我去tomcate发布目录下将项目的web-inf里的lib打开
查看里面有没有包含找不到的包---没有
然后看了看pom.xml配置文件commons-lang的配置语句
<dependency> <groupId>commons-lang</groupId> <artifactId>commons-lang</artifactId> <version>2.6</version> <scope>provided</scope> </dependency></span>
<scope>provided</scope> 去掉之后成功！
总结了以下，关于maven下的项目，如果出现jar包的问题，应该这样查
是否下载完整---可以将该jar包坐在的文件，删除重新下载
是否版本一致---可以全局定义一个version，下载相关使用version
是否被打包---查看tomcat文件下对应项目中的webinf-lib下有没有对应的jar包，然后在看看pom.xml中是怎样配置的
maven对jar包使用的范围有一些规定
即在jar包配置的后面添加<scope>[compile ,provided,runtime,test,system ]</scope>
| 名称 | 解释 |
| compile （编译范围） | compile是默认的范围；如果没有提供一个范围，那该依赖的范围就是编译范围。 编译范围依赖在所有的classpath 中可用，同时它们也会被打包。 |
| provided （已提供范围） | provided 依赖只有在当JDK 或者一个容器已提供该依赖之后才使用。 例如， 如果你开发了一个web 应用，你可能在编译classpath 中需要 可用的Servlet API 来编译一个servlet，但是你不会想要在打包好的WAR 中包含这个Servlet API；这个Servlet API JAR 由你的应用服务器或者servlet 容器提供。已提供范围的依赖在编译classpath （不是运行时）可用。 它们不是传递性的，也不会被打包。 |
| runtime （运行时范围） | runtime 依赖在运行和测试系统的时候需要，但在编译的时候不需要。 比如，你可能在编译的时候只需要JDBC API JAR，而只有在运行的时候才需要JDBC驱动实现 |
| test （测试范围） | test范围依赖 在一般的编译和运行时都不需要，它们只有在测试编译和测试运行阶段可用。 |
| system （系统范围） | system范围依赖与provided 类似，但是你必须显式的提供一个对于本地系统中 JAR 文件的路径。这么做是为了允许基于本地对象编译，而这些对象是系统类库 的一部分。这样的构件应该是一直可用的，Maven 也不会在仓库中去寻找它。 如果你将一个依赖范围设置成系统范围，你必须同时提供一个 systemPath 元素。注意该范围是不推荐使用的（你应该一直尽量去从公共或定制的 Maven 仓库中引用依赖）。 |