Apache jUDDICommunity Documentation

Chapter 2. Development Environment Setup

2.1. Prerequisites
2.2. Building the Project
2.3. Source Modules Overview
2.4. Setting up Eclipse
2.5. Running a unittest from within Eclipse
2.6. Building the JAR
2.7. Building the WAR
2.8. Building the Tomcat Bundle
2.9. Running and Developing Tests

To be able to build and run jUDDI you will need to have the following installed:

First, check out the jUDDI sources:

% svn co http://svn.apache.org/repos/asf/webservices/juddi/trunk

Then build the entire project using OpenJPA for persistance use:

% cd trunk
% mvn clean install -Dpersistence=openjpa

To use Hibernate change the persistence flag to hibernate. Optionally you can use a settings.xml to set your persistence choice on a permanent basis, so you don't have to provide the persistence variable every time you build. The default location of the settings.xml is in your .m2 directory. An example file is checked into our source tree at etc/.m2/settings.xml.

Within jUDDI source, there are the following modules:

jUDDI v3 is set up to produce a number of different deliverables – a JAR, a WAR, and a Tomcat bundle. Depending on the scope of your application, or your interest in the project, you might want to use the Tomcat server bundle packaged with the Derby database and jUDDI, or you may just want to use the jUDDI JAR and make your own database and Web Service choices. jUDDI is set up so that it can support a range of environments.

The easiest way to setup jUDDI in eclipse is to use the m2eclipse plugin which can be found at http://m2eclipse.codehaus.org/update/. In order to run and debug the project unit tests, it is required that you install this plugin. After installing the plugin you should select:


If you wish to change your persistence.xml for the purposes of testing, either change it and then build, or change juddi-core/target/classes/META-INF/persistence.xml. If you choose not to use the m2eclipse plugin you can setup your classpath by following these directions, but there are no guarantees that the unit tests will be debuggable within Eclipse. Choose “Eclipse” -> “Preferences” In the preference dialog, select “Java” -> “Build Path” -> “Classpath Variables” Add a new classpath variable :

Name: M2_REPO

Path : /[path-to-.m2]/.m2 (example : /home/tcunning/.m2)

% cd v3_trunk

% mvn eclipse:eclipse -Declipse.workspace=/[path-to-workspace]/workspace

Then within Eclipse, “Create New Project” and choose “Create from existing source” and choose the source folder that you just checked out from SVN.

To run one unittest from within eclipse simply right-click the unittest and select Debug As > Junit Test


If you are using OpenJPA you have to make sure that the openjpa-1.2.jar is on the classpath and that for each unittest you specify the javaagent needed for the enhancement phase

-javaagent:/Users/kstam/.m2/repository/org/apache/openjpa/openjpa/1.2.0/openjpa-1.2.0.jar


The juddi-core module produces a JAR which contains the jUDDI source and a jUDDI persistence.xml configuration. jUDDI is currently setup so that you can choose between using either OpenJPA or Hibernate as your persistence framework. The juddi-core pom.xml contains two profiles, triggered on the "persistence" property.

OpenJPA

% cd juddi-core
% mvn clean install -Dpersistence=openjpa 

Hibernate

% cd juddi-core
% mvn clean install -Dpersistence=hibernate 

For juddi 3.0.0 and 3.0.1, the project built with Hibernate by default, but as of 3.0.2 the project now builds with openjpa as the default persistence layer. Two flavors of juddi-core are available as maven artifacts - juddi-core for hibernate usage and juddi-core-openjpa for use with OpenJPA.

As with the JAR, you need to make a decision on what framework you would like to use when building the WAR. The project contains twoWAR modules – juddiv3-war, which produces a JAX-WS agnostic WAR, and juddi-cxf – which produces a WAR with CXF descriptors. The project would welcome any contribution of docs or descriptors for alternative JAX-WS providers.

Tomcat bundle packages up one of the jUDDI WAR files, Apache Derby, and a few necessary configuration files and provides the user with a pre-configured jUDDI instance. By default, the WAR produced by the juddi-cxf module is used – the example below shown uses URLs and endpoints using the jUDDI CXF configuration. If you use the Axis 2 configuration, URLs and endpoints may differ.

To get started using the Tomcat bundle, unzip the juddi-tomcat-bundle.zip, and start Tomcat :

% cd apache-tomcat-6.0.20/bin
% ./startup.sh  

Browse to http://localhost:8080/juddiv3/services


The services page shows you the available endpoints and methods available. Using any SOAP client, you should be able to send some sample requests to jUDDI to test:


Currently the only unit tests are in juddi-core. We plan to add a suite of web service tests automated against the juddi-cargo module.

Running the tests:

% cd juddi-core
% mvn -Dpersistence=hibernate test

The tests are run through a maven-surefire-plugin within the juddi-core pom.xml :



      
maven-surefire-plugin 2.4.2 src/test/resources/suite-init.xml,src/test/resources/suite-subscribe.xml,src/test/resources/suite-clean.xml

The NUnit suite files listed here determine what tests are run with what data, and what order they are run in. suite-init.xml initializes the jUDDI database with data, suite-subscribe.xml runs a subscription test, and suite-clean.xml cleans the database and removes the test data.

To develop your own tests, please add another maven-surefire-plugin segment and the same ordering of XML files (suite-init.xml, your custom suite, and then suite-clean.xml).