Then it means that either you have more than one version of that jar library, or there are another jar library which contains a class with that problematic method with exactly same signature.
The first case usually happens when you copy your jars into your lib folders with their keeping version suffixes. Stripping of version suffixes before copying them into the destination folder is a good habit, and ivy dependency management tool, for example, does it automatically for you. Otherwise your lib folder may contain older versions of a library if you are not very careful, and if the dependent class is loaded from wrong jar then you will get NoSuchMethodError.
The second case is much worse. Having two different libraries which contain methods with exactly same signature might sometimes be difficult to diagnose. One easy way to identify which jars contain related class might be to use your IDE’s type searching facility. For example, in Eclipse you can “Open Type” dialog and search your class within it. It will list matching classes coming from available dependencies in your classpath. You are able to see containing jars the resulting list.
Here, I must say that I am having difficulty in understanding why some libraries place classes into their jar files which actually don’t belong to them. For example, apacheds-main-0.9.jar, for example, contains classes from several different projects, such as commons io, logging, collections, oro, aspectjrt and so on. What is worse is that there is no version information about some of those dependencies packed in that jar file. In any case, you can easily come up with two incompatible class versions you will depend on.