Friday Apr 03, 2009
Wednesday Aug 06, 2008
By sandoz on Aug 06, 2008
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.
Wednesday Oct 31, 2007
By sandoz on Oct 31, 2007
As Sud points out the examples distributed with Jersey are a bit NetBeans focused and that can make it tricky to understand how to use Jersey in other build environments. IMHO for the most part this problem is independent of NetBeans and is due to lack of documentation, a pre-compile step used in some examples to obtain the list of root resources (classes annotated with @UriTemplate), and a required initialization parameter in the web.xml for the Jersey servlet.
Frank has started work on a branch of Jersey that will remove the need for a pre-compile step and initialization parameters and thus as a result reduce required documentation for default behavior to just one line, "use this servlet class <insert class here>", and no longer require modification of the project build.xml. This simplicity should hopefully translate into an easier understanding of how Jersey can work in other build environments.
The required jars of a project using Jersey can depend on what Java types are used for entities, see here for a list of required and optional jars.
No bookmarks in folder