今天过去写的testcase在ant执行时failed,但是在源文件中直接以application方式运行却没有错。
原因在于下面两句话:
public static Set<Class<? extends XXX>> getPluginsInSameDir(Class<?> clazz) { String dirPath = clazz.getPackage().getName().replace(".", "/"); System.out.println(dirPath); URL path = clazz.getClassLoader().getResource(dirPath); System.out.println(path.toExternalForm()); ..... }
第一句是要得到那个类所在的包路径,第二句是要得到那个包所在的具体路径。
以application方式运行得到的结果是:
aa/bb/cc
file:/D:/works/project/bin/aa/bb/cc
以ant方式执行Junit testcase得到的结果是:
aa/bb/cc
file:/D:/works/project/build/classes/aa/bb/cc
这两个结果差别还是蛮大的。关键问题是classLoader()那个家伙的查找资源的方式。这里解决问题的最简单方式:
就是那个testcase中传入的Class<?>clazz的包路径不要在testcase代码中出现(可以在src代码路径中出现),那么ant执行testcase时,就又会找到原来的/bin目录。
例如工程结果是:
src/java | aa | bb | cc |YourClass.java src/test | aa | bb | cc | TestYourClass.java
你这里就不应该将YourClass.class作为参数传入进刚才的函数中。不应该像这样
getPluginsInSameDir(YourClass.class);
最简单的做法是:
src/java | aa | bb | cc |YourClass.java src/test | aa | bb | ccs | TestYourClass.java
这是非常的土的方法。
你当然可以尝试修改一下getClassLoader().getResource()这句话。
这个问题产生的原因是:
ant执行JUnit时,执行TestYourClass, 这时加载的classLoader()是junit的classLoader(), 这个会首先在自己的包路径中查找是否有该路径,如果存在就返回了。
另外一种解决方法是:
ProtectionDomain pd = clazz.getProtectionDomain(); CodeSource cs = pd.getCodeSource(); String location = cs.getLocation().getFile();
这样就能真正的通过那个类找到那个类 编译为class文件所在的目录。