%BOOK_ENTITIES; ]>

To be able to build and run jUDDI you will need to have the following installed: 1.5.X JDK Maven 2.0.8

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: uddi-ws: JAXWS stubs built from the WSDLs uddi-tck: Test kit developed by jUDDI for testing UDDI v3 functionality. The TCK is not jUDDI specific and could be used to verify and validate other UDDI v3 implementations juddi-core: the jUDDI jar containing the model, API, and core jUDDI functionality juddiv3-war: a WAR module agnostic as to JAX-WS provider juddi-cxf: a WAR module that uses CXF as the web service framework, chosen by default juddi-tomcat: a module which builds a Tomcat bundle with juddi-cxf installed and Derby as a backend data base juddi-console: a module which builds upon the juddi-tomcat module and adds a GWT-based administration console uddi-client: a generic client library for communicating with a UDDI server juddi-dist: a module used to produce shippable binary distributions 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: “Enable Depency Management” Then, “Enable Nested Modules” Then, “Update Project Configuration”

Enable m2eclipse

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

Running unittests from within Eclipse

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

Specifying the javaagent needed by OpenJPA during the enhancement phase

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

jUDDI Service List

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:

A jUDDI sample SOAP request

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).