Re: Weird Spring compilation (and sometimes test) errors
On Aug 7, 12:48 pm, magloca <magl...@mailinater.com> wrote:
magloca wrote:
I have an Appfuse Light-based web application that has suddenly
stopped working -- on one particular machine. On my development
computer, compilation fails:
/home/magloca/Proj/appfuse-light/src/main/java/com/example/myapp/Custom=
erCo ntroller.java
[23,21] cannot find symbol
symbol : method
addAttribute(java.util.List<com.example.myapp.model.Customer>)
location: class org.springframework.ui.ModelMap
Since there are no takers yet, I thought I'd expand a bit on this. It
appears that the problem is somehow related to the classpath, but I
don't understand how since the two machines are, as far as I can tell,
configured exactly the same way:
[...]
* Same Maven, 2.0.8. Maven configurations in /etc/maven2 are identical.
What about ~/.m2/settings.xml?
* .classpath in project directory identical. Neither system has a
defined CLASSPATH environment variable.
.classpath is not used by maven, only Eclipse.
* Maven downloads the same Spring JARs -- spring-2.5.4.jar,
spring-beans-2.0-m2.jar, spring-context-2.0-m2.jar,
spring-core-2.0-m2.jar, spring-dao-2.0-m2.jar, spring-jdbc-2.0-m2.jar,
spring-remoting-2.0-m2.jar, spring-webmvc-2.5.4.jar. This mixture of
2.0-m2 and 2.5.4 seems fishy to me, but I haven't messed with the
pom.xml that came with Appfuse Light.
This is *extremely* fishy and is probably the root cause of the
problem. I would capture the output of 'mvn dependency:tree' and file
a bug pointing out the mixed dependency versions to the appfuse guys.
Sometimes (!), the compile works but several tests fail, saying:
java.lang.NoSuchMethodError:
org.springframework.util.ObjectUtils.nullSafeToString(Ljava/lang/Object;)=
Lj ava/lang/String;
I'm thinking that the problem can't be related to my project, or to
anything in my home directory. Checking out the project as a different
user on the same machine yields the same problems. It must be something
system-wide, but I can't figure out what it is. Any suggestions at all
would be very much appreciated.
Prior to 2.0.9, Maven builds classpaths in hashcode order using
objects whose hashCode() implementations are the default. This
behaviour has changed in maven 2.0.9 for exactly the reason you
discovered: it aggravates the unreliability of flaky builds by
allowing different JARs to be loaded first on different runs. This is
not the root problem, but it's certainly making it worse.
=46rom the 2.0.9 release notes:
MNG-1412 / MNG-3111 introduced deterministic ordering of dependencies
on the classpath. In the past, natural set ordering was used and this
lead to odd results. The ordering is now preserved from your pom, with
dependencies added by inheritence added last. In builds that had
conflicting or duplicate dependencies, this may introduce a change to
the output. In short, if you have weird issues with 2.0.9, take a look
at the dependencies to see if you have conflicts somewhere.
-o