Handling Java Enterprise Dependency (javaee) with Maven

Almost all software development today is made with some building tool and the major one out there is Maven. But Sun and now Oracle have not made life simple for programmers that wish to use Java Enterprise Dependency to Maven. And the reason for that is the Java Enterprise API that is submitted to Maven Central Repository is good for compiling but not for execution and one example of execution is testing! And I believe that most programmers out there today want to develop there code in a more or less test driven way. And that is then hinder.

So for Java EE 5 there is the following Maven Dependency:

<dependency>     
    <groupid>javaee</groupid> 
    <artifactid>javaee-api</artifactid>
    <version>5</version>
    <scope>provided</scope> 
</dependency>

And for Java EE 6:

<dependency>     
    <groupid>javax</groupid>
    <artifactid>javaee-api</artifactid>
    <version>6.0</version>
    <scope>provided</scope>
</dependency>

NOTE that the groupId has also changed, which also is not good. Since the new Maven Dependency will be harder to locate when browser a Maven Repository, but also harder for a programmer that wish to upgrade and only wish to increase the version field and nothing else.

So when using the javaee dependency you will typically end up with a following error:

java.lang.ClassFormatError: Absent Code attribute in method that is not native or abstract in class file

So what is you option? There is two solution

1. Keep the standard dependency and add the container specific dependency with test scope.
2. Leave the path with compiling against the standard API and directly using the concrete container dependency.

The first option is not very compelling because it makes the Maven pom.xml file even longer with a lot of testing dependency.

The second one is also not very compelling since you want to develop generic code and the easiest way to uphold that, especially if you have less experienced programmers in your team, is not to have the concrete container classes at all in the class path when compiling your code.

Conclusion: I have giving up for a long time ago, trying to keep your code generic and in my next blog I will show you how to best use the JBoss EE dependency.
http://magnus-k-karlsson.blogspot.se/2012/04/managing-java-enterprise-dependency.html