• CustomBuildFramework

Custom Build Framework

In developing the Bitstorage subproject of DOMS, we created a rather elaborate build framework for handling interdependent webservices. Here is the documentation on how to use it.

Every module must have a build.xml. All build files have a specific structure

1. Property definitions
2. Import statements
3. Set definitions

There are at present three kinds of modules

• Common modules, ie. those that just produce a jar
• Webservice Modules, ie. those that end up producing a war
• Webservice interface modules, ie. those that compile a wsdl to java code for a webservice module

Property definitions

Every module build file must set the property global.dir to the correct value in regards to its basedir. This must happen as the firsts line of the project.     <property name="global.dir" value="${basedir}/../../.."/>

Every other property that should be set, must be set now, before any imports or something else is performed

Each of the kinds of module have specific properties that control how the build is performed

Common modules

• jarfile: the name of the jarfile to generate. Optional
• srcpack.zip: the name of the zipfile with the sources. Optional.

Default values

    <property name="jarfile" value="${ant.project.name}.jar"/>
    <property name="srcpack.zip" value="${ant.project.name}-src.zip"/>

Webservice Modules

• warfilename: the name of the warfile to generate. Optional
• wsdl.dir: The directory containing the wsdl file. Optional

Default values

    <property name="warfilename" value="${ant.project.name}.war"/>

If wsdl.dir is not set, the webservice will be built without a wsdl. This is the expected behaivour for pure REST webservices.

Webservices inherit from Common, so all properties above are also respected.

Webservice Interface Modules

• wsdl.dir: The directory containing the wsdl file. Required
• wsdl.file: The location of the wsdl file itself. Not relative. Required.
• wsdl.package: The java package name of the generated classes. Required
• generalSuperExceptionName: The qualified name of a class to act as the superclass of all generated exception classed. Optional.

If generalSuperExceptionName is set, all generated exceptions will have this line inserted

    extends ${generalSuperExceptionName}

And all webservice method definitions that throws any exceptions will be specified to throw this

   throws ${generalSuperExceptionName}

This is nessesary to use the exceptionmapper functionality. Note that the generalSuperException is not generated, it must be provided, for example in the src folder of the module.

The properties from common modules also applies here.

Webservice Interface Modules

Import statements

Then the nessesary imports should be performed. These depends on the kind of module

• Common modules: <import file="${global.dir}/build-common.xml"/>

• Webservice interface modules: <import file="${global.dir}/build-soap-webservice-interface.xml"/>

• Webservice Modules:

      <!--Contain the normal build tasks, including war-->
      <import  file="${global.dir}/build-webservice.xml"/>
  
      <!--Adds the soap libs to the build-->
      <import file="${global.dir}/build-soap-webservice.xml"/>
  
      <!--Adds the rest libs to the build-->
      <import file="${global.dir}/build-rest-webservice.xml"/>

  Of course, you only need to add the soap or the rest libs if you do not use both.

Set definitions