[
https://issues.apache.org/jira/browse/OOZIE-654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13444492#comment-13444492
]
Hadoop QA commented on OOZIE-654:
---------------------------------
Testing JIRA OOZIE-654
Cleaning local svn workspace
{code}
----------------------------
+1 PATCH_APPLIES
CLEAN cleaned target directories
+1 RAW_PATCH_ANALYSIS
+1 the patch does not introduce any @author tags
+1 the patch does not introduce any tabs
+1 the patch does not introduce any trailing spaces
+1 the patch does not introduce any line longer than 132
+1 the patch does adds/modifies 3 testcase(s)
+1 RAT
+1 the patch does not seem to introduce new RAT warnings
+1 JAVADOC
+1 the patch does not seem to introduce new Javadoc warnings
+1 COMPILE
+1 HEAD compiles
+1 patch compiles
+1 the patch does not seem to introduce new javac warnings
+1 BACKWARDS_COMPATIBILITY
+1 the patch does not change any JPA Entity/Colum/Basic/Lob/Transient
annotations
+1 the patch does not modify JPA files
+1 TESTS
Tests run: 902
Tests failures: 1
Tests errors: 0
+1 DISTRO
+1 distro tarball builds with the patch
----------------------------
{code}
The full output of the test-patch run is available at
https://builds.apache.org/job/oozie-trunk-precommit-build/70/
> Provide a way to use 'uber' jars with Oozie MR actions
> ------------------------------------------------------
>
> Key: OOZIE-654
> URL: https://issues.apache.org/jira/browse/OOZIE-654
> Project: Oozie
> Issue Type: Improvement
> Reporter: Harsh J
> Assignee: Robert Kanter
> Priority: Minor
> Attachments: OOZIE-654.patch, OOZIE-654.patch, OOZIE-654.patch
>
>
> Right now, say if you have a custom MR code in a jar that has a {{lib/}}
> folder inside which carries more dependent jars (a structure known as 'uber'
> jars), and you submit the job via a regular 'hadoop jar' command, these
> lib/*.jars get picked up by the framework because the supplied jar is
> specified explicitly via conf.setJarByClass or conf.setJar. That is, if this
> user uber jar goes to the JT as the mapred.jar, then it is handled by the
> framework properly and the lib/*.jars are all considered and placed on the
> classpath.
> Distributed cache jars do not have this effect, and that is cause the MR
> framework does not consider them as uber jars and does not extract and use
> their internal lib/ directories.
> We should have a way in oozie to let users promote one of their jars as uber
> jars, as an option.
> Proposal: Have an optional oozie-prefixed config, or an optional element in
> the MR action XML, that lets user specify what class should be loaded to be
> set as setJarByClass(...). This will have to be a class available in the
> higher level of the uber jar (not under lib/) but can be any class inside the
> targeted jar really (just not from a jar under lib/). We then set this as
> jobConf.setJarByClass(loadedCls), and then run the job.
> Thoughts?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
