Apache jUDDICommunity Documentation
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 v3_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”
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
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
).