Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. Maven 2.2.1 or above
  2. Tomcat 6.x or above
  3. Java 6 (note: the djatoka service has compatibility issues with open-jdk)
  4. Subversion

Building DuraCloud

Info

Wiki Markup
Any portions of the configuration below for which you need to include a replacement value will be written in all capital letters and included in brackets: \[LIKE-THIS\]

Build with unit tests
  1. Check out latest stable release from Subversion repository
    Code Block
    svn co https://svn.duraspace.org/duracloud/tags/duracloud-0.89.0
    
  2. Set environment variables
    Code Block
    export JAVA_OPTS="-XX:MaxPermSize=256m"
    export MAVEN_OPTS="-Xmx1024m -XX:MaxPermSize=1024m"
    
  3. Configure Tomcat
    1. Add to $CATALINA_HOME/conf/tomcat-users.xml
      No Format
      <tomcat-users>
        <role rolename="manager"/>
        <role rolename="admin"/>
        <user username="any[ANY-usernameUSERNAME]" password="any[ANY-passwordPASSWORD]" roles="admin,manager"/>
      </tomcat-users>
      
  4. Start tomcat
    Code Block
    $CATALINA_HOME/bin/startup.sh
    
  5. Configure Maven2
    1. Add tomcat user to $M2_HOME/conf/settings.xml
      No Format
      <servers>
        <server>
          <id>tomcat-server</id>
          <username>any-username<<username>[ANY-USERNAME]</username>
          <password>any-password<<password>[ANY-PASSWORD]</password>
        </server>
      </servers>
      
  6. Build with only unit tests
    1. From top of source tree
      Code Block
      mvn clean install -PskipIntTests
      
      Note: Each of the maven2 project modules are configured to halt the build if there is a test failure. The only exception to this is the integration-test module which is configured to run through all of its tests regardless of failures. So the above build command can optionally exclude the '-PskipIntTests' flag if desired.

...

  1. Create unit-test-db
    • From inside the //unit-test-db module, run:
      Code Block
      mvn assembly:assembly
      java -jar target/unit-test-db-[versionVERSION]-db-util.jar
      
  2. Running the above db util jar will provide a commandline interface for adding credentials
  3. Add credentials for s3, emc, rackspace, root-user
    1. Set the root-user to username: 'root', password: 'rpw' to just use the application default.
    2. See root user discussion below for ways of changing the default.
  4. Add the connection details for the unit-test-db to $M2_HOME/conf/settings.xml
    No Format
    <profile>
      <id>always</id>
      <properties>
        <duracloud.home>locationhome>[LOCATION-whereWHERE-applicationAPPLICATION-hasHAS-writeWRITE-access<ACCESS]</duracloud.home>
        <unit.database.home.default>locationdefault>[LOCATION-whereWHERE-unitUNIT-testTEST-dbDB-wasWAS-created<CREATED]</unit.database.home.default>
        <unit.database.password.default>unitdefault>[UNIT-testTEST-dbDB-bootBOOT-password<PASSWORD]</unit.database.password.default>
      </properties>
    </profile>
    
    <activeProfiles>
      <activeProfile>always</activeProfile>
    </activeProfiles>
    
    • where duracloud.home is the directory under which the logs and osgi-container will be placed
    • where unit.database.home.default is the location of the unit-test-database created above
    • where unit.database.password.default is the boot password used during creation of the unit-test-database above
  5. The integration tests also expect a registry (read: 'space') of services to be available within the primary storage provider of service storage host
    1. The naming of the space follows the convention "duracloud-<version>-service-repo"
    2. The services to be loaded into the registry can be found in the target directories of each of the service projects
    3. See discussion below about application configuration, including the service storage host
  6. Build with unit and integration tests
    1. From top of source tree
      Code Block
      mvn clean install
      
  7. As mentioned before, if there are any failures in the //integration-test module, the build will still complete, but the failures will be listed

...

This step assumes the successful completion of the previous build instructions

Panel
titleLinux/Mac
  1. Start OSGi service container
    Code Block
    
    cd //services/servicesadmin
    mvn clean -f pom-run.xml pax:provision
    cd runner
    chmod +x run.sh
    export BUNDLE_HOME=

...

  1. [DURACLOUD_HOME]/osgi-container
    ./run.sh
    

...

    1. Wiki Markup
      Where \[DURACLOUD_HOME\] is a directory where the application has write access (can be same as <duracloud.home> set in Maven settings.xml above)
    2. The run.sh script will start an OSGi container and commandline interface to it
    3. The container starts with required bundles including the 'services-admin' installed
    4. See discussion below on OSGi container for more details
  1. Once the 'services-admin' is running, tests that deploy services into the OSGi environment may be run
  2. From inside the //integration-test module
    Code Block
    
    mvn install -PrunServicesAdminTests
    
Panel
titleWindows
  1. Set up OSGi service container
    Code Block
    
    cd services/servicesadmin
    mvn clean -f pom-run.xml pax:provision
    cd runner
    
  2. (Optional) Set the OSGi bundle storage location
    Code Block
    
    set BUNDLE_HOME=[BUNDLE_HOME]
    
    1. Wiki Markup
      Where \[BUNDLE_HOME\] is the full path to an empty directory where the osgi container content will be stored
    2. Open the run.bat file in the runner directory in a text editor and replace all instances of "$BUNDLE_HOME" with "%BUNDLE_HOME%"
    3. Note: A directory called "$BUNDLE_HOME" under the runner directory will be used as the default bundle home if one is not specified.
  3. (Optional) Set up logging
    1. Download this logback.xml file file into your bundle home directory.
    2. Open the logback.xml file in a text editor and edit the LOG_FILENAME property to point to a full file path (including file name) for a log file.
    3. Note: One benefit to performing this step will be faster start time for your OSGi container.
  4. Start OSGI service container
    Code Block
    
    run.bat
    
    1. The run.bat script will start an OSGi container and commandline interface to it
    2. The container starts with required bundles including the 'services-admin' installed
    3. See discussion below on OSGi container for more details
  5. Once the 'services-admin' is running, check to ensure that it was created properly
    1. In the console where run.bat was executed, an "osgi" prompt should be available. If it is not available, hitting enter should bring it up.
    2. Type "ss" and hit enter. This should list all of the available bundles. This list should include 50 items, all of which are either in the ACTIVE or RESOLVED state.

Optional items

Code coverage
  1. If you plan on using Clover, the following element needs to be added to your maven 'settings.xml'
    No Format
    <profiles>
      <profile>
        <id>profile-clover</id>
        <activation>
          <property>
            <name>profile</name>
            <value>clover</value>
          </property>
        </activation>
        <properties>
          <cloverLicense>[specifyLOCATION-locationOF-of-clover.license-FILE]</cloverLicense>
        </properties>
      </profile>
    </profiles>
    
  2. To run clover
    Code Block
    mvn clover2:instrument clover2:aggregate clover2:clover -Pprofile-clover
    
  3. A report will be generated in the following directory:
    //target/site/clover/

...

  1. This tool provides a commandline interface for interacting with the 'services-admin' installed in a running OSGi container (see notes above for starting the container)
  2. To build and run the CLI, from within the //servicesadminclient module
    Code Block
    mvn assembly:assembly
    java -cp target/servicesadminclient-<version>[VERSION]-cli.jar
    
Application initialization utility

...