[
https://issues.apache.org/jira/browse/HIVE-2424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13263238#comment-13263238
]
Travis Crawford commented on HIVE-2424:
---------------------------------------
Looking at JarJar it aims to solve exactly the issue being discussed here:
"You can avoid problems where your library depends on a specific version of a
library, which may conflict with the dependencies of another library."
However, it does have some consequences:
"Jar Jar Links includes an Ant task that extends the built-in jar task. The
normal zipfileset element is used to embed jar files. A new rule element is
added which uses wildcards patterns to rename the embedded class files.
Bytecode transformation (via ASM) is used to change references to the renamed
classes, and special handling is provided for moving resource files and
transforming string literals."
So the basic idea is avoiding class version conflicts through renaming. This is
potentially problematic for classes outside the jarjar that are not aware of
the class renames.
I can investigate this further but my initial reaction to the jarjar approach
is that it sounds good if you're creating an entirely self-contained jar, but
not as an element of a multi-jar classpath. For example, this approach seems
totally appropriate for a fully self-contained JDBC jar that users can give to
their favorite GUI app, where UDFs are installed server-side. For a Hadoop job
that may depend on the bundled contents (UDF that makes a thrift call) this
approach seems problematic because thrift would be renamed and therefore
unavailable outside the jarjar, forcing users to resubmit the bundled jars
under their original name.
Thoughts?
> Don't expose thrift, commons and json classes in the hive exec jar
> -------------------------------------------------------------------
>
> Key: HIVE-2424
> URL: https://issues.apache.org/jira/browse/HIVE-2424
> Project: Hive
> Issue Type: Improvement
> Components: Build Infrastructure
> Reporter: Eli Collins
>
> The hive exec jar includes exploded thrift, json, and commons lang classes.
> These may conflict with the user's classpath. This could be fixed by jar
> jaring or using shade. A mechanism that allowed a user to substitute
> alternative versions w/o recompiling might be a useful intermediate step
> (though will require the user substitute alternative versions that work w/
> Hive).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
