Как я могу заставить HBase хорошо работать с управлением зависимостями sbt?

Я пытаюсь запустить проект sbt, который использует Hadoop CDH3 и HBase. Я пытаюсь использовать файл project/build/Project.scala для объявления зависимостей от HBase и Hadoop. (Я признаю, что мое понимание sbt, maven и ivy немного слабое. Пожалуйста, извините меня, если я сказал или сделал что-то глупое.)

Все прошло гладко с зависимостью Hadoop. Добавление зависимости HBase привело к зависимости от Thrift 0.2.0, для которой, похоже, нет репо, или так звучит из этого Пост SO.

Итак, на самом деле у меня есть два вопроса: 1. Честно говоря, я не хочу зависимости от Thrift, потому что я не хочу использовать интерфейс HBase Thrift. Есть ли способ сказать sbt пропустить это? 2. Есть ли лучший способ настроить это? Должен ли я просто сбросить банку HBase в каталог lib и двигаться дальше?

Обновление Это файл sbt 0.10 build.sbt, который выполнил то, что я хотел:

scalaVersion := "2.9.0-1"

resolvers += "ClouderaRepo" at "https://repository.cloudera.com/content/repositories/releases"

libraryDependencies ++= Seq(
  "org.apache.hadoop" % "hadoop-core" % "0.20.2-cdh3u0",
  "org.apache.hbase" % "hbase" % "0.90.1-cdh3u0"
)

ivyXML :=
  <dependencies>
    <exclude module="thrift"/>
  </dependencies>

hadoop scala sbt thrift hbase
person Leif Wickland    schedule 06.06.2011    source источник

Ответы (2)


arrow_upward
4
arrow_downward

Глядя на файл HBase POM, Thrift находится в репозитории по адресу http://people.apache.org/~rawson/repo. Вы можете добавить это в свой проект, и он должен найти Thrift. Я думал, что SBT разберется с этим, но это пересечение SBT, Ivy и Maven, так что кто действительно может сказать, что на самом деле должно произойти.

Если вам действительно не нужен Thrift, вы можете исключить зависимости, используя встроенный XML Ivy, как описано в документации в вики SBT.

override def ivyXML = 
  <dependencies>
    <exclude module="thrift"/>
  </dependencies>

Re: сбросить банку в каталог lib, это было бы краткосрочной выгодой, долгосрочной потерей. Это, безусловно, более целесообразно, и если это какое-то доказательство концепции, которую вы выбрасываете на следующей неделе, обязательно просто закиньте банку и забудьте об этом. Но для любого проекта, срок жизни которого превышает пару месяцев, стоит потратить время на правильное управление зависимостями.

Хотя у всех этих инструментов есть свои проблемы, преимущества заключаются в следующем:

  1. Анализ зависимостей может сказать вам, когда ваши прямые зависимости имеют конфликтующие транзитивные зависимости. До появления этих инструментов это обычно приводило к странному поведению во время выполнения или методу, который не находил исключений.
  2. Обновления очень просты. Просто измените номер версии, обновите, и все готово.
  3. Это позволяет избежать фиксации двоичных файлов в системе контроля версий. Они могут быть проблематичными, когда приходит время объединять ветки.
  4. Если у вас нет четкой политики в отношении версий двоичных файлов в вашем каталоге lib, легко потерять представление о том, какие версии у вас есть.
person leedm777    schedule 07.06.2011
comment
Спасибо, @dave! Бит ivyXml сделал свое дело. Я думаю, что причина, по которой sbt не взял Thrift, заключается в том, что репозиторий ~rawson не был в его списке благословленных репозиториев. - person Leif Wickland; 07.06.2011

arrow_upward
0
arrow_downward

У меня есть очень простой пример проекта sbt с Hadoop на github: https://github.com/deanwampler/scala-hadoop.

Посмотрите на project/build/WordCountProject.scala, где я определяю переменную с именем ClouderaMavenRepo, которая определяет расположение репозитория Cloudera, и переменную с именем hadoopCore, которая определяет конкретную информацию для jar-файла Hadoop.

Если вы зайдете в репозиторий Cloudera в браузере, вы сможете перейти к соответствующей информации для Hive.

person Dean Wampler    schedule 07.06.2011