JBoss.orgCommunity Documentation

Chapter 11. Contributing to jUDDI

Table of Contents

11.1. License guidance
11.2. SVN access
11.3. Project structure
11.4. Building and testing jUDDI
11.4.1. All Java Components
11.4.2. .NET
11.5. Other ways to Contribute to jUDDI
11.5.1. Bug Reports
11.5.2. Internationalization
11.5.3. Contributing Source code
11.5.4. Releases
11.6. What the?

We welcome contributions to jUDDI. Visit the jUDDI web set at http://juddi.apache.org for more information.

Apache jUDDI is released under the Apache Software Foundation v2.0 License. Details on the license is located at the following link: http://apache.org/licenses/LICENSE-2.0.

If you wish to bring in 3rd libraries, please keep in mind that certain libraries cannot be used due to license restrictions. See http://www.apache.org/legal/3party.html for details.

Source code is accessible at the following link: https://svn.apache.org/viewvc/juddi/trunk/.

jUDDI, from a developer’s perspective, is divided into a number of smaller, more manageable modules. In general, each module contains all of the necessary unit tests in order to ensure functionality.

jUDDI has a number of components, however it is mostly Java based. The following sections describe the particulars for each language.


  1. Acquire a Subversion client.
  2. Execute svn co https://svn.apache.org/viewvc/juddi/trunk/
  3. Acquire a JDK5 or higher and setup the JAVA_HOME environment variable.
  4. Acquire Apache Maven. Known working version: 3.0.4
  5. Setup an environment variable, MAVEN_OPTS=-Xmx768m -XX:MaxPermSize=512m
  6. Make sure the Maven/bin folder and the JDK/bin folders are in the current path
  7. Execute "mvn clean install"

This will build, test and package all of the Java components of jUDDI. This includes the Technical Conformance Kit (TCK), a live Tomcat server, the user interfaces, and more.

For additional build output, add -Ddebug-true for Java.

To prepare a deployable jUDDI war for an alternate deployment scenario (other than Tomcat with CXF and OpenJPA), use the following procedure:

  1. Execute "mvn clean package -P<packageName>"

Where <packageName> is one of the following

  1. openjpa-jboss7up for EAP 6 and up, GA 7 and up
  2. hibernate-jbossws-native for EAP 5, Jboss GA 6 and down with the JbossWS Native soap stack
  3. hibernate-jbossws-cxf for EAP 5, Jboss GA 6 and down with the JbossWS Native soap stack
  4. hibernate (includes CXF in the war, used for Tomcat)
  5. openjpa (includes CXF in the war, used for Tomcat)
  6. axis2 (includes Axis2 in the war)


When altering the TCK based modules, make sure you clean install in the root check out location. Due to the build order, you may end up with strange results when just executing the tests, even with clean install.


To attach the debugger to the build process try "mvn -Dmaven.surefire.debug clean install". It listens on port 5005 by default. More info on debugging maven projects is here http://maven.apache.org/surefire/maven-surefire-plugin/examples/debugging.html

There are many ways you can contribute to jUDDI. We welcome all kinds and types contributions.

Having ran into a number of strange issues when developing with jUDDI, we decided to write a few of them down.

  1. I added a new class to juddi-core but it doesn’t end up in the packaged tomcat instance? A: Modify the pom and make sure the package name is added to juddi-core-openjpa
  2. Some unit tests fail, but only under windows. A: This is specifically for the SubscriptionListerner Tests and most likely has something to do with ports getting locked up by the Java process.