JCP/JavaEE Artifacts in Maven Central Blog
JCP/JavaEE Artifacts in Maven Central
As mentioned in the Editor’s Blog, java.net artifacts are finally available in Maven Central. This includes the official JCP/JavaEE artifacts, being published by the official steward of Java technology. This blog entry brings to your attention a few points about using these artifacts, as well as introducing a simple archetype that the Mojarra team uses to facilitate the creation of automated regression tests.
I am not at all in the position to comment on maven best practices, but one problem I’ve run into is the effect of bitrot on a maven build. This can sometimes result in a complicated assortment of repository entries leading to the lack of a clear understanding of how your dependencies are being satisfied. Now that the official JavaEE artifacts are all in maven central, you can omit the repository declaration entirely from your projects, relying on a mirror declaration in your settings.xml file, if necessary. If you are developing a Java EE 6 application, all of the compile time dependencies can be satisfied from a single artifact, in maven central.
- <dependencies>
- <dependency>
- <groupId>javax</groupId>
- <artifactId>javaee-api</artifactId>
- <version>6.0</version>
- <scope>provided</scope>
- </dependency>
- </dependencies>
It is important to note that this dependency was declared with <scope>provided</scope>
This is the only
way you can use this dependency because the jar has been stripped of
all java code and contains only signatures. The actual implementation of
JavaEE 6 comes, naturally, from your Java EE 6 compliant container.
If you would rather go à la carte, the individual artifacts for all of the JavaEE technologies are also available, as listed in these tables. The first table lists artifacts that conform to the naming scheme Oracle Architect, and JavaEE Titan, Bill Shannon. The scheme is documented at <http://wikis.sun.com/display/GlassFish/Maven+Versioning+Rules>.
The remaining jars do not conform to the naming scheme, but are useful for compilation nonetheless.
Provider Interface for Containers
If you want to use JSF 2.1, which was released after JavaEE 6, it is necessary to explicitly place a compile time dependency on that artifact before the javaee-api 6.0 dependency.
- <dependencies>
- <dependency>
- <groupId>javax.faces</groupId>
- <artifactId>javax.faces-api</artifactId>
- <version>2.1</version>
- <scope>provided</scope>
- </dependency>
- <dependency>
- <groupId>javax</groupId>
- <artifactId>javaee-api</artifactId>
- <version>6.0</version>
- <scope>provided</scope>
- </dependency>
- </dependencies>
Oracle GlassFish Server 3.1.1 <http://glassfish.org/> contains an implementation of JSF 2.1.
Archetypes That Use The Artifacts
Because we now have these artifacts in maven central, it is possible for us to finally add archetypes that use them. This first archetype creates a simple war project that depends on JSF 2.1 and JavaEE 6.
mvn archetype:generate -DarchetypeGroupId=javax.faces -DarchetypeArtifactId=javax.faces-war-archetype -DarchetypeVersion=2.1
A subsequent post will document the use of another artifact, for the very latest JSF version, 2.2-SNAPSHOT.
This blog entry signifies the culmination of the effort of many individuals from many disciplines over the ears. I would like to thank them all for finally allowing official Java jars to flow into Maven Central.
Technorati Tags: edburns
4 Comments
-
-
Nice, but I noticed that JPA 2 is missing.
//
I've found that having the java code stripped from these jars makes them quite useless in a real project because any unit tests that reference associated code cannot be executed.
//