After trying geronimo artifacts the whole morning with no result, I came over this thread [1] which states that the jars containing the implementations have to be placed before the javaee api jar in the pom. This solved the problem, it works with either geronimo.javamail or javax.mail:mail (Ant probably did it this way).
I've also tried the suggested artifacts in the above thread. The embedded glassfish gave me a whole new exception but the interesting thing happened with the jersey-server artifact which seems to contain a javaee 6 implementation. It was already present in my pom indirectly by the fact that it is a dependency for the atmosphere framework which was defined before javaee-api but it didn't count. It seems like either maven doesn't allow directly using a dependency of an artifact (which i doubt) or order is not taken into consideration for dependencies of dependencies... Meanwhile I was searching for an artifact which contains only servlets 3.0 without anything else in order to get rid of the javaee api jar and the best I could find was the javax.servlet:servlet-api:3.0-alpha-1 artifact from the glassfish repo. Everything works fine with it just that I don't know how reliable it is considering it is an alpha version. In conclusion, we've got 3 possibilities: 1. javaee-web-api + javax.mail 2. javaee-web-api + geronimo.javamail 3. servlet-api:3.0-alpha-1 Let me know which option seems best for you. I'd go for the servlet-api due to it's conciseness but I don't know how stable it is... Sorry for the long post but I find it a good lesson about maven and javaee 6. Florian [1] http://stackoverflow.com/questions/3424207/testing-against-java-ee-6-api On Fri, Aug 27, 2010 at 10:38 AM, ant elder <[email protected]> wrote: > That sounds likely to me, the dependency javaee-web-api does include > the javax.mail interfaces so its duplicating whats in mail-1.4.jar so > its just chance that in my environment it uses the classes from the > mail jar and works whereas in your environment it uses the classes > from javaee-web-api and so doesn't work. > > ...ant > > On Thu, Aug 26, 2010 at 8:30 PM, Simon Nash <[email protected]> wrote: > > Thread [1] below might be relevant. Apparently Sun is in the habit of > > releasing a "borked" JavaEE API jar that can only be used for compiling > > and not for running testcases. The suggested solution is not to use the > > Sun JavaEE API jar but instead to use the equivalent Geronimo API jars, > > which aren't "borked". > > > > You would need to select the specific Geronimo API jars that you need > > (e.g., the javamail API), as it seems that Geronimo doesn't have a > > single combined JavaEE API jar. > > > > Simon > > > > [1] > > > http://maven.40175.n5.nabble.com/JUnit-tests-requiring-j2ee-jar-fail-when-running-mvn-surefire-test-td100379.html > > > > Florian MOGA wrote: > >> > >> Hi, > >> > >> I've noticed a strange error in the logs when running /mvn test /on > >> binding-comet-runtime. > >> > >> java.lang.ClassFormatError: Absent Code attribute in method that is > >> not native or abstract in class file > javax/mail/internet/ParseException > >> > >> > >> Full logs can be found here [0]. I've searched the internet and it seems > >> to be caused by the fact that javaee-web-api:6.0 only contains the API > and > >> not the actual implementations. At Ant's suggestion, I've added > >> javax.mail:mail:1.4 as dependency which solved the problem in his > >> environment. However, it didn't do it for me, I can still see the error > in > >> the logs. I've checked this on two environments: Ubuntu 9.04/Sun JRE 6.0 > and > >> Ubuntu 10.04/OpenJDK and I'm getting the same behavior. > >> > >> Could someone else please check if the error is appearing on their > >> environment and if the javax.mail dependency solves the issue? All > that's > >> required is to run a /mvn install /on binding-comet and /mvn test/ on > >> binding-comet-runtime which can be found in the contrib/modules folder. > >> > >> Thanks, > >> > >> Florian > >> > >> > >> [0] http://pastebin.com/g3fuR5bw > > > > >
