...
The archetype is available at maven central. Here is the set of commands you would typically run.
Code Block |
---|
prompt>$ curl -so radix httphttps://svnraw.apachegithubusercontent.orgcom/repos/asfapache/oodt/trunk/mvn/archetypes/radix/src/main/resources/bin/radix | bash prompt> cd oodt; mvn package prompt> mkdir ../oodt-deploy; tar -xvf distribution/target/oodt-distribution-0.1-SNAPSHOT-bin.tar.gz -C ../oodt-deploy prompt> cd ../oodt-deploy; ./bin/oodt start |
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
inin italics
belowbelow)
- The
The groupId
isis a place to specify your company's namespace.
- The
The artifactId
isis a place to specify a short name of your project.
- The
The version
indicatesindicates the initial version label for your project.
- The
The oodt
flagflag 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.
- The
Code Block |
---|
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.
NOTE2: After you launch oodt (the fourth command), you may observe the following output:
Code Block |
---|
Using CLASSPATH:
-e Starting OODT File Manager [ Failed ]
-e Starting OODT Resource Manager [ Failed ]
-e Starting OODT Workflow Manager [ Failed ] |
Don't be confused. In order to see whether the oodt is running, open a browser to You can now check the installation by opening a browser to http://localhost:8080/opsui or running the various command line programs for the various components.. Click on 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.
Code Block |
---|
ps -ax | grep "oodt" |
NOTE: The "oodt start" command should return quite quickly. This is normal. If, however, the OpsUI link 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-deploy/logs/oodt.out"/logs/oodt.out"
Note | ||
---|---|---|
| ||
While starting/stopping oodt if you get errors like "Is File/Workflow/Resource Manager
You should get this message for all these three links: "Method GET not implemented (try POST)" which means all pcs_stat |
Version Control
If you want to manage your OODT RADiX distribution with Subversion.
Code Block |
---|
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
Info | ||
---|---|---|
| ||
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.
Code Block | ||||
---|---|---|---|---|
| ||||
/$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
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
FILEMGR_PORT=9000 export FILEMGR_PORT |
workflow
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
WFMGR_PORT=9001 export WFMGR_PORT |
Default Source Structure
Code Block | ||||
---|---|---|---|---|
| ||||
/$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 |
...