Modularizing Jersey

Jakub (who is now taking a well-deserved holiday) converted the Jersey project over to maven and modularized code. Converting from ant to maven is not easy, the barrier to understanding maven and its idiosyncrasies is rather high in my opinion. Once things are in place and stable i can see the benefit in terms of the build process and what it brings to developers in terms of a network-based dependency system.

We have modularize Jersey functionality into the following modules:

  • jersey-core: common code shared between client and server.
  • jersey-client: client-side support.
  • jersey-server: server-side support.
  • jersey-atom: Atom de/serialization using Rome.
  • jersey-json: JSON de/serialization using Jettison and JAXB.
  • jersey-bundle: contains all the above as one jar (the maven plugin has some bugs that stop the source jar and pom being correctly generated).

Further more the contributions module provides the following sub-modules:

  • jersey-spring: spring support for Jersey. In your WebApp use the SpringServlet provided by this module.
  • maven-wadl-plugin: improved WADL support, including recognition of JAXB and embedding JavaDoc into WADL to have full documentation associated with the code and provided by the service.

In addition the tests are available and we are converting the examples over to maven projects. There is still more modularization work to do, and as a result the boundaries between modules (mainly between jersey-core and jersey-client/server need to be improved).

Some developers may now be confused as there are two unstable versions of 0.9. The old unstable unmodularized 0.9 is available on java.net as a zip file and also from the maven repo. We have kept this around for developers that do not wish to be affected by maven issues with the new unstable modularized 0.9. The old 0.9 will be removed once we are satisfied with the functionality and stability of the new 0.9.

We have set up Hudson to continuously push 0.9 SNAPSHOT modules to the java.net maven repo when source-code changes occur. However, i have been informed that this is backed by a subversion repository so a history will be kept of all the binary files. So we probably need to switch to the Glassfish maven repo for SNAPSHOT builds as this is not subversion controlled, while using the java.net repo for stable releases.

Comments:

Post a Comment:
  • HTML Syntax: NOT allowed
About

sandoz

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today