Version 10

    Building the JBoss Application Server.

     

    JBossAS 6.x

     

    From the root directory, run ./build.sh.  The standard maven goals (clean, install, etc.) can be passed to this script.  For example "./build.sh clean install".  If maven ( >= 2.0.9 ) is install on your workstation, maven can be called directly to build the app server.  For example "mvn clean install".

     

    During development it is sometimes useful to build a single module and update the distribution build.  This can be done by passing the module (directory) name to maven as a system property.  From the root directory:

    ./build.sh -Dmodule=main

     

    This will build the main "main" and run the distribution build.

     

    JBossAS 5.x and Earlier versions

     

    Prior to JBossAS 6, the application server must be built from the "build" directory.

    cd build

    ./build.sh or ant

     

    The ant build uses custom tasks called "buildmagic" to build all the AS modules and then build the distribution.

     

    Running the Testsuite.

     

    The AS integration testsuite is normally run from the "testsuite" directory.

    cd testsuite

    ./build.sh clean     - Clean the test output

    ./build.sh             - Run the default target "main" to build the testsuite

    ./build.sh tests         - Run all the tests

     

    To run just a basic subset of the tests

    ./build.sh smoke-tests

     

    How to add/update build dependencies.

     

    JBossAS 6.x

     

    The versions for all the dependencies of the build are controlled by the pom.xml located in the component-matrix directory.  So the first step is to add the dependency to the dependencyManagement section of this pom (component-matrix/pom.xml).

    <dependency>
      <groupId>org.something</groupId>
      <artifactId>new-artifact</artifactId>
      <version>1.0</version>
    </dependency>
    

     

    The next step is different depending on whether you want to add the dependency to a module, to the distribution, or to the testsuite.  The following provides some information about maintaining dependencies in the build.

     

    Add/update a module dependency

    1. add/update the dependency in component-matrix
    2. add/update the dependency in the appropriate module pom 

     

    Add/update a new dependency just to the distribution build

    1. add/update the dependency in component-matrix/pom.xml
    2. add/update the dependency in build/pom.xml
    3. the Ant distribution build can then reference the dependency using a property or fileset refid with the format: ${groupId:artifactId:[classifier:]type}


    Add/update a dependency used only in the testsuite

    1. add/update the dependency in component-matrix/pom.xml
    2. add/update the dependency in testsuite/pom.xml
    3. the Ant testsuite build can then reference the dependency using a property or fileset refid with the format: ${groupId:artifactId:[classifier:]type}


    Also note that any dependency added to a module will automatically be available to the distribution build and to the testsuite.  And any dependency added to the distribution pom (build/pom.xml) will automatically be available to the testsuite build.  Dependencies added to the testsuite build will only be available to the testsuite.

     

     

    JBossAS 5.x

     

    The versions for all the dependencies of the build are controlled by the pom.xml located in the component-matrix directory.  So the first step is to add the dependency to the dependencyManagement section of this pom (component-matrix/pom.xml).

    <dependency>
      <groupId>org.something</groupId>
      <artifactId>new-artifact</artifactId>
      <version>1.0</version>
    </dependency>

     

    The next step is to add the dependency (without the version number) to module(s) that requires it.  This could be any of the modules which contain a pom.xml file including the thirdparty directory.

     

    Adding the dependency to the thirdparty/pom.xml will download the jar file into a directory that matches the groupId. So given the following dependency declaration:

    <dependency>
      <groupId>org.something</groupId>
      <artifactId>new-artifact</artifactId>
    </dependency>

     

    The thirdparty directory will contain the following jar after running the build:

    thirdparty/org/something/lib/new-artifact.jar

     

    Optionally you can also add the dependency to the buildmagic plugin configuration if you want to use a path other than the default in the thirdparty directory.

     

    <dependency>
      <groupId>org.something</groupId>
      <artifactId>new-artifact</artifactId>
      <mapping>
        <componentId>somejars</componentId>
      </mapping
    </dependency>

     


     

    If a particular modules needs the new dependency available in the build classpath, it must be added to the build.xml file.  Located the path with id "library.classpath".  The refid of the new dependency must be added to this path.  For example to add the above dependency to the path, you would add something like this:

     

    <path refid="org.something.classpath"/>

     

    Versions prior to JBossAS 5.x

     

    Before 5.x the JBossAS build used a tool called jbossbuild to retrieve thirdparty dependencies.  These need to be updated in the file "build-thirdparty.xml".  Running this file generates an include file called libraries.ent that contains Ant path configuration for each dependency.

     

     

    Understanding the AS 5.x Thirdparty Build

     

    The build for AS version 5.x uses a mix of Maven and legacy Ant code.  The setup is somewhat confusing, so this section provides an explanation of how the build works.

     

    There are Ant build scripts (build.xml) and Maven poms (pom.xml) for each of the modules.  The Ant build should be considerered the main build scripts with the Poms mainly used for integration with external maven builds.  The Ant build scripts reference various jars using a file called libraries.ent located in the thirdparty directory.  This file (libraries.ent) contains Ant paths to the various thirdparty jar files used in the build and it allows the build.xml files to reference these jars to use them in the build classpaths and to include them in the distribution.  The libraries.ent file is generated by a maven plugin called the buildmagic-thirdparty-maven-plugin.

     

    By default the buildmagic-thirdparty-maven-plugin will use the maven groupId as the thirdparty componentId and maven artifactId as the thirdparty artifact.  However the plugin can be configured to map a Maven groupId/artifactId to a differnent componentId.  The downloaded dependency will then be given the configured componentId in thirdparty/libraries.ent.