The ShareLib behaves very similarly to oozie.libpath, except that it’s specific to the aforementioned actions and their required JARs. This is the simplest approach.Īlternatively, we can use the oozie.libpath property in our job.properties file to specify additional HDFS directories (multiple directories can be separated by a comma) that contain JARs. The advantage of using this property over the lib folder discussed above is in cases where we have many workflows all using the same set of JARs. The first approach is based on the fact that a workflow typically consists of a job.properties file, a workflow.xml file, and an optional lib folder (and perhaps other files such as Pig scripts). Oozie will take any of the JARs that we put in that lib folder and automatically add them to our workflow’s classpath when it’s executed. There are two ways to let Oozie know about Mapper and Reducer classes or any other additional JARs required by our workflow. we want to specify our own Mapper and Reducer classes, but how does Oozie know where to find those two classes? Suppose we have an Oozie workflow that runs a MapReduce action. Create oozie installation directory under preferred location, usually in /usr/lib/oozie and provide full permissions and download the oozie source code into that folder.Mapreduce Job History Server should be configured and started successfully and remaining hadoop & yarn daemons should be running fine.But if we are going to install oozie-4.1.0 or later versions then Jdk-1.7 on Ubuntu will not cause any issues.If our jdk version on Ubuntu is greater than or equal to jdk-1.7 then we need to make some changes in pom.xml file. If we plan to install Oozie-4.0.1 or prior version Jdk-1.6 is required on our machine.We are building the oozie distribution tar ball by downloading the source code from apache and building the tar ball with the help of Maven.

How to install maven in ubuntu 14.04