It happens all the time. You download an example application from the web but it does not run without exactly the correct versions of jars to execute against. The best solution to this problem is to release a working demo of the application that has the bare minimum of jars required for it to execute.
When developers use lazy names for jars, future users have no idea what versions were used in a project. For example, some of the jars for a real project were listed below.
46,725 commons-codec.jar
71,442 commons-discovery.jar
279,781 commons-httpclient.jar
39,443 commons-logging.jar
313,898 dom4j.jar
47,531 ehcache.jar
421,601 quartz.jar
The file names give no indication of the versions of .jars used – only the file size and occasionally the manifest can be used to tell them apart.
46,725 commons-codec-1.3.jar
71,442 commons-discovery-0.2.jar
279,781 commons-httpclient-3.0.1.jar
38,015 commons-logging-1.0.4.jar
313,898 dom4j-1.6.1.jar
47,531 ehcache-1.1.jar
421,601 quartz-1.6.0.jar
In the second example, only exactly what was needed is defined in the lib directory. There are no overlapping namespaces of package names within the jars so they can't interfere with each other.
Tip: Maven allows specific management of JAR versions but can also burn a lot of time on projects if you do not have Maven expertise and slow builds to a crawl if you don't manage a local repository. It's not worth the pain for simple JAR version management.
