...

The archetype is available at maven central. Here is the set of commands you would typically run.

prompt>$ curl -so radix httphttps://svnraw.apachegithubusercontent.orgcom/reposapache/asf/oodt/trunk/mvn/archetypes/radix/src/main/resources/bin/radix | bash
prompt> mv oodt oodt-src; cd oodt-src; mvn package
prompt> mkdir ../oodt; tar -xvf distribution/target/oodt-distribution-0.1-bin.tar.gz -C ../oodt 
prompt> cd ../oodt; ./bin/oodt start
prompt> ./resmgr/bin/batch_stub 2001

You should then edit the radix file replacing the parameters below with whatever you want.

• The first command is the running of a maven archetype to make an oodt project. Inside of the RADIX script downloaded in the curl command is an mvn archetype generation command. That command has a number of parameters that the 1 liner radix script encapsulates. (parameters marked

  in

  in italics

  below

   below)

  • The

    The groupId

    is

     is a place to specify your company's namespace. 

  • The

    The artifactId

    is

     is a place to specify a short name of your project. 

  • The

    The version

    indicates

     indicates the initial version label for your project. 

  • The

    The oodt

    flag

     flag indicates the version of OODT that you want your project to be built on. N.B., this should most likely match the most recent version of OODT.

     

prompt> mv oodt oodt-src; cd oodt-src; mvn install
prompt> mkdir ../oodt; tar -xvf distribution/target/oodt-distribution-0.1-bin.tar.gz -C ../oodt 
prompt> cd ../oodt; ./bin/oodt start
prompt> ./resmgr/bin/batch_stub 2001

• The second command simply moves into the created oodt project directory where your source and configuration can be maintained and later can be placed into version control. Then creates the distribution of your OODT project using "mvn package"
• The third command merely untars the distribution into the created deployment directory
• The fourth command moves into the deployment directory and starts the OODT system.
• The fifth command launches batch stub on the port 2001..

NOTE1: If you observe for some reason OODT doesn't start, make sure JAVA_HOME is set in your ~/.bashrc  (Example: export JAVA_HOME="/usr/lib/jvm/java-6-openjdk-i386") and then start OODT in a new terminal. The actual problem can be seen in the tomcat logs which is located in $OODT_HOME/tomcat/logs.

NOTE2NOTE: After you launch oodt (the fourth command), you may observe the following output:

...

Don't be confused. In order to see whether the oodt is running, open a browser to http://localhost:8080/opsui.  Click on PCI PCS Status link to get detailed information about running processes. A green arrow indicates that the corresponding process runs correctly.

...

Alternatively one may run the following command and get list of relevant processes and assigned ports.

ps -auxax | grep "javaoodt"

The "oodt start" command should return quite quickly. This is normal. If, however, the http://localhost:8080/opsui link above is not functional on your system, one good place to start looking for probable cause is the "oodt.out" log file, which can be found (if you've been following the example above) in "oodt/logs/oodt.out"

While starting/stopping oodt if you get errors like "Is File/Workflow/Resource Manager 
still running? Start/Stop aborted." in logs/oodt.out:

 You should get this message for all these three links: "Method GET not implemented (try POST)" which means all 
those managers are running. Note that you can also check if the managers are running as expected by visiting 
$OODT_HOME/pcs/scripts/ and by running

pcs_stat

Version Control

If you want to manage your OODT RADiX distribution with Subversion.

prompt> svn import <dataSystemName> http://your_repo_path/<dataSystemName>/trunk -m "Initial OODT Import"

If you want to manage your OODT RADiX distribution with Git

prompt> git init

prompt> git add .

prompt> git commit -a -m "Initial OODT import"

Default Deployment Structure

In order for the easy installation to work properly we will need to settle on a default deployment layout structure. Below is our plan of how we want to layout the deployment when the project is built. First we will list out an overview, then we can detail each path and what files are going to be saved into each.

/$DEPLOYMENT_BASE_DIR
  /bin
  /crawler
    /bin
    /etc
    /policy
    /lib
  /filemgr
  /data
	/archive
	/catalog
	/failure
	/met
	/staging
	/work
	/workflow
  /binextensions
    /etcbin
    /policyetc
    /lib
   /workflowfilemgr
    /bin
    /etc
    /policy
    /lib
  /extensionslogs
  /pcs
    /bin
    /etc
    /lib
	/logs 
	/policy
	/run
  /tomcat/pge
	/bin
	/lib
	/policy
  /dataresmgr
     /archivebin
     /stagingetc
    /lib
	/logs 
	/policy
	/run
  /tomcat
	/LICENSE
	/NOTICE
	/RELEASE-NOTES
	/RUNNING.txt
	/bin
	/common
	/conf
	/logs
	/server
	/shared
	/temp
	/webapps
	/work
  /workflow
    /metbin
     /failureetc
    /lib /catalog

	/logs
	/policy
	/run 

Deployment Path Descriptions

...

port

filemanager

FILEMGR_PORT=9000
export FILEMGR_PORT

workflow

WFMGR_PORT=9001
export WFMGR_PORT

Default Source Structure

/$DEPLOYMENT_BASE_DIR
  /crawler
    /policy
    /bin
    /etc
  /filemgr
    /policy
      /oodt
    /bin
    /etc
  /workflow
    /policy
    /bin
    /etc
  /webapps
    /fmprod
    /fmbrowser
    /wmonitor
    /curator
  /extensions
    /src/main
      /java
        /<package>
          /extractor
          /versioner
          /task
          /action
      /python
  /distribution
    /bin
      /oodt
    /etc
      /oodt.properties

...