Re: Disasterous problem with 2 spec jars

2005-12-13 Thread Brett Porter
For the record... Maven does not use the eclipse compiler without it being configured. However, by default it is -source 1.3 and -target 1.1 (maximum JVM compatibility). It's the -target 1.1 that adds these signatures. Adding 1.4 and 1.4 fixed the issue. - Brett On 12/13/05, Kevan Miller <[EMAI

Re: Disasterous problem with 2 spec jars

2005-12-13 Thread Kevan Miller
I don't fully understand the issue, but Eclipse may not be doing the wrong thing... Sun JDK 1.5 will, in fact, behave in the same manner (I haven't tested to see how 1.5 will compile the same class). Just to be clear, the "near-term" options seem to be: 1) switch spec build to maven 1 2) configur

Re: Disasterous problem with 2 spec jars

2005-12-13 Thread Rick McGuire
I just took a look at the Sun version of the BodyPart class, and it is similarly truncated (although it supports a setParent() method in addition to getParent()). It appears that the eclipse compiler is adding this incorrectly. It makes sense that it shouldn't, since the BodyPart class is abs

Re: Disasterous problem with 2 spec jars

2005-12-13 Thread David Jencks
Sachin says that maven 2 uses the eclipse compiler rather than javac and that judging by its behavior when looking at binary classes in eclipse it may well be producing these bad class files. It appears that all the methods in the "implements" interfaces have been added to the class. Pre

Disasterous problem with 2 spec jars

2005-12-13 Thread David Jencks
Something is dreadfully wrong with two of the spec jars build by maven 2. The javamail BodyPart class source looks like this: package javax.mail; /** * @version $Rev: 54266 $ $Date: 2004-10-10 14:02:50 -0700 (Sun, 10 Oct 2004) $ */ public abstract class BodyPart implements Part { p