IIRC, a serializable class which does not define its serialVersionUID gets a new one every time it is compiled, regardless of what compiler is being used.
What I had read as the correct solution is for the class to explicitly define serialVersionUID. Of course, doing that means that you lose the protection that the class hasn't been changed. The only other solution is to ensure that the unit tests run from Eclipse use the same class files that were sent to the application server. -----Original Message----- From: Peschier J. (Jeroen) [mailto:[EMAIL PROTECTED] Sent: Thursday, December 01, 2005 09:37 To: [email protected] Subject: [M2] SerialVersionUID solution / Maven compiler settings My use-case: I build an EAR using Maven 2 and the Sun SDK 1.4.2. For testing I tend to run a few JUnit tests from Eclipse. These tests typically invoke some remote beans on the application server. This gives me the dreaded InvalidClassException because the local serialVersionUID differs from the remote serialVersionUID. Evalution: I think most of us dealing with RMI have encountered this problem before. It is known that different compilers generate different serialVersionUIDs for the same class. In my case the remote classes are generated with the Sun JavaC while the local classes are generated by Eclipse JDT. Plan: Although this problem is not actually a Maven 2 issue, I was thinking Maven 2 could assist in the solution to the problem. The maven-compiler-plugin has a compilerId setting which seems to indicate it can be reconfigured to use another compiler. Would it be possible for M2 to use the Eclipse compiler so that the artifacts will have the same serialVersionUID as in Eclipse? If so, how would I go about this? P.S. I know I can manually add serialVersionUIDs to serializable classes, but this is not an option as most of my serializable classes are value objects generated by XDoclet. XDoclet does not have a way of specifying serialVersionUID for generated value objects. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
