[
https://issues.apache.org/jira/browse/HBASE-11118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058936#comment-14058936
]
Nick Dimiduk commented on HBASE-11118:
--------------------------------------
[~fs111] please give it another shot. The compat.module issues are a
side-effect of how the HBase build is managed for hadoop1/hadoop2
compatibility. Basically, Stack and I were both lazy in how we built and
published jars. I've done it properly now and the build of cascading.hbase is
now working for me with the following patch applied.
{noformat}
diff --git a/build.gradle b/build.gradle
index 75f3b46..5f25ea9 100644
--- a/build.gradle
+++ b/build.gradle
@@ -60,6 +60,7 @@ allprojects {
mavenCentral()
maven{ url 'http://conjars.org/repo/' }
maven{ url 'https://repository.apache.org/content/repositories/releases/' }
+ maven{ url 'http://people.apache.org/~ndimiduk/repository/' }
}
version = releaseVersion
}
diff --git a/cascading-hbase-hadoop/build.gradle
b/cascading-hbase-hadoop/build.gradle
index 6507a1a..d631762 100644
--- a/cascading-hbase-hadoop/build.gradle
+++ b/cascading-hbase-hadoop/build.gradle
@@ -20,7 +20,7 @@
apply from: "${rootDir}/etc/hadoop-shared-config.gradle"
-ext.hbaseVersion = '0.98.1-hadoop1'
+ext.hbaseVersion = '0.98.4-hadoop1-SNAPSHOT'
ext.hadoopVersion = '1.2.1'
dependencies {
diff --git a/cascading-hbase-hadoop2-mr1/build.gradle
b/cascading-hbase-hadoop2-mr1/build.gradle
index f36fc99..91e62ad 100644
--- a/cascading-hbase-hadoop2-mr1/build.gradle
+++ b/cascading-hbase-hadoop2-mr1/build.gradle
@@ -24,7 +24,7 @@ idea {
pathVariables MODULE_DIR: file( "${rootDir}/cascading-hbase-hadoop" )
}
-ext.hbaseVersion = '0.98.1-hadoop2'
+ext.hbaseVersion = '0.98.4-hadoop2-SNAPSHOT'
ext.hadoopVersion = '2.2.0'
dependencies {
{noformat}
> non environment variable solution for "IllegalAccessError: class
> com.google.protobuf.ZeroCopyLiteralByteString cannot access its superclass
> com.google.protobuf.LiteralByteString"
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: HBASE-11118
> URL: https://issues.apache.org/jira/browse/HBASE-11118
> Project: HBase
> Issue Type: Bug
> Affects Versions: 0.98.2
> Reporter: André Kelpe
> Priority: Blocker
> Fix For: 0.99.0, 0.98.4, 2.0.0
>
> Attachments: 11118.098-0.txt, 11118.098.txt, 11118.bytestringer.txt,
> 1118.suggested.undoing.optimization.on.clientside.txt,
> 1118.suggested.undoing.optimization.on.clientside.txt,
> HBASE-11118-0.98.00.patch, HBASE-11118-0.98.01.patch,
> HBASE-11118-0.98.02.patch, HBASE-11118-0.98.patch.gz,
> HBASE-11118-trunk.patch.gz, HBASE-11118.00.patch, HBASE-11118.01.patch,
> HBASE-11118.02.patch, shade_attempt.patch
>
>
> I am running into the problem described in
> https://issues.apache.org/jira/browse/HBASE-10304, while trying to use a
> newer version within cascading.hbase
> (https://github.com/cascading/cascading.hbase).
> One of the features of cascading.hbase is that you can use it from lingual
> (http://www.cascading.org/projects/lingual/), our SQL layer for hadoop.
> lingual has a notion of providers, which are fat jars that we pull down
> dynamically at runtime. Those jars give users the ability to talk to any
> system or format from SQL. They are added to the classpath programmatically
> before we submit jobs to a hadoop cluster.
> Since lingual does not know upfront , which providers are going to be used in
> a given run, the HADOOP_CLASSPATH trick proposed in the JIRA above is really
> clunky and breaks the ease of use we had before. No other provider requires
> this right now.
> It would be great to have a programmatical way to fix this, when using fat
> jars.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
