可能真的是懒导致的？
打算试试beankeeper，但是没有提供binary下载，只能下载source，还得使用maven编译，结果下载maven，mvn package后就看到maven开始下载一对莫名其妙的东西，按照文档说的，应该只依赖不超过5个jar包啊，现在这起码下载了30+的东西了吧，用时4分45秒，最后还失败了：
mail-1.4.jar; error in opening zip file
想不通啊，不过对这个开源项目的印象也不好了，再试试好了，谁让我对它的感觉比其他的好呢。
更新：
mail的错误是下载到的包是1k，可能是服务器上的东西有问题，像这样的问题应该不是第一次，手动下载了一个覆盖了，可以继续走了，但是又开始下载另外的N多的东西，耗时1分24秒，不错总算是编译成功了。
项目中要使用到Pluto，今天研究了一下，但是经历着实痛苦。
我们的tomcat使用的是古老的jboss带的版本，我就用我自己安装的tomcat5.0.28做了下试验，结果不成功，后来下载了一个bundle版本，其实就是已经包含了tomcat的版本，但是它带的版本是5.5.20，我就对照了下，把我能看出来的不同都对应的在tomcat5.0.28下做了修改，应用是可以跑起来了，但是登录进首页的时候出了一个NullPointerException，原因不明也没有那么多时间去研究，后来就下载了老版本的1.0.1试验，结果应用都不能起来。没有办法，只能从原代码编译试试，又去下载maven，结果使用JDK1.4无法编译，它的代码中使用了一个JDK1.5才有的方法，手工修改源代码，编译通过了，但是在安装的时候又出了问题，报告pluto的一个plugin不存在。然后又下载pluto的1.0.1版本的原代码，又下载maven1.0.2版本编译，依然不成功，原因是不能解析project.xml文件，彻底无语了。
更新：
回家后又弄了一下，终于在tomcat5.0.28下成功手工发布了pluto1.1，问题是我依然要使用JDK1.5才能看到结果运行正常，使用JDK1.4时会出现编译pluto1.1时遇到的那个问题的运行期版本。步骤为将bundle版本下的文件拷贝到tomcat5.0.28的对应目录：
要解决JDK版本问题，可能的办法就是修改源代码（pluto-1.1.0-src\pluto-container\src\main\java\org\apache\pluto\core\ContainerInvocation.java，把64行注释掉就行）后在JDK1.4下编译，然后把那个有问题的类替换掉，当然可能会有其他的问题。
© 2024 解惑
本主题由Anders Noren提供 — 向上 ↑