Andy Clement schrieb: > A similar situation is reported in > https://bugs.eclipse.org/bugs/show_bug.cgi?id=251151 There it turned out to > be a problem with two versions of a type being around in the VM - one had > been woven and one had not. > > But i guess you are going to tell me the classpath is completely unchanged, > all you have done is a recompile? We could compare the weaveinfo output > between the two builds and check it is identical.
Hi Andy, indeed, everything else on this build is completely unaltered. I just changed the maven property in the parent POM, which defines the AspectJ version we use in the dependencies of the aspectj-maven-plugin (to define the compiler version) and in aspecjrt and aspectjtools-jar. I'm now at home, and at my way home with the bike I've mulled the problem over. "Incompatible change" for me indicates that there must be 2 changes, or 2 types as in the example you quote -- and yes, we too had that other situation at times, causing JBoss-Remoting to fail mysteriously on deserialisation ;-) - could load time weaving interfere somehow? Doesn't spring-aspects or the transactional support of Spring use loadtime weaving? I vaguely recall that some colleague told me he had to add aspectweaver.jar to some POM in that project. I'll check that tomorrow. - of course, besides that the other question is why the older aspectj doesn't complain. Where there any changes in the name mangling of private ITD fields between 1.6.6 and 1.6.8 Anyway, now I'll have enough to double check tomorrow. Meanwhile thanks for your quick response, I'll report back. Hermann _______________________________________________ aspectj-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/aspectj-users
