It should work - but there are some things that can mess it up.
If the project changed names of their groupId or artifactId in
maven, you could have a dependency using an old transient dependency somewhere - maven will think this is a completely different dependency, but if classes and packages are named the same, there will be collisions when the classloader tries to load it.
Usually you don't see this in maven-ized dependencies, but if you may have system dependencies declared... There are some cases where someone did something stupid like unpacked another jar into their project and then packaged up their project + dependencies into a jar. I've seen this problem in one old version of Sun's J2EE.jar where they had packaged the classes of an apache xml parser in with their code. My project had dependencies on the j2ee.jar (system dependency) and a newer version of the apache xml parser as a regular dependency - and suddenly classloader problems.
It could also be something on the system classpath or in a global library directory of the app servers.
To troubleshoot this - you can try to use the
-verbose option with the
java command launching your app server - this will show where each class is actually loaded from. You'll need to redirect output to a log file too - so much output will be printed, you'll have to open it later as a text file and search for the specific classes you're interested in.
