在上面搭建环境的过程中，我们发现，Library的管理存在着一定问题。这个问题主要表现为：
1. 不容易做Library的版本管理。如果Library的版本需要升级，那么我们不得不重新copy一份新的jar包，并且借助IDE重新指定项目的classpath。这种劳动，对于一个项目还可以接受，如果你有10多个项目，那么jar包的复制工作会让你很头疼。
2. 每个项目都会有Library的副本。这一点让人非常恼火。实际上，对于一个公司或者一个项目组而言，使用的技术体系基本不变。然而，每个项目的Library却是分开的。不仅如此，每个项目都要从svn中下载大量的相同的Library文件，给我们的硬盘造成极大的空间浪费。对于那些频繁使用Branch的项目来说，这些Library的下载简直就是噩梦。
所以，我们需要一个集中式的Library管理方式。而这一点曾经在Javaeye的海阔天空版激烈得讨论过使用maven来进行管理还是自行管理。
Readonly 写道
共享类库可以用IDE reference project解决，公司内部项目给常用的lib建立一个project，从CVS上check out，其他工程项目都依赖这个project就可以了，ant build也直接引用这个项目的jar就可以，项目体积照样只有几百K。
——一个讨厌ant，更加讨厌maven的人
我比较赞同Readonly老大的说法而倾向于自行管理。maven这样的高级货，偶实在是用不来啊。那么我们就来看看如何使用共享类库来进行Library管理。
1. 首先建立一个共享类库
建立一个共享类库，将项目中需要共享的Library进行恰当的分类。同时，为每个加入到Library中的jar包进行统一的格式化的命名方式。例如：spring/spring-2.5.5.jar等等。这样的好处在于，一旦jar包的版本有更新，可以加入新的jar包而保留原来的。在项目中，就可以通过引用不同版本的jar包来对Library进行版本管理。
以下就是我个人建立的一个共享类库，大家可以参考：
svn://www.demo2do.com/library
2. checkout共享类库，并将其导入到IDE中作为一个Library工程
3. 为你的项目指定classpath，引用的jar包存在于Library工程中
在这里，我们可以看到，原来项目中的lib目录被删除，jar包也被删除。在项目中所引用的jar包是Library项目中的jar包。
【小结】
完成了上述所有的步骤之后，Library就被集中管理起来，而每个项目也不会再变得那么庞大。当然，开发环境的搭建完全取决于个人的习惯，所以使用各自喜欢的方式吧，不要让环境问题束缚你们的手脚。