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

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

2 голосов
/ 07 июня 2011

Я пытаюсь запустить проект sbt, использующий Hadoop и HBase CDH3. Я пытаюсь использовать файл 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>

Ответы [ 2 ]

4 голосов
/ 07 июня 2011

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

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

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

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

Хотя все эти инструменты имеют свои проблемы, преимущества:

  1. Анализ зависимостей может сказать вам, когда ваши прямые зависимости имеют конфликтующие переходные зависимости. До появления этих инструментов это обычно приводило к странному поведению во время выполнения или к методу, в котором не найдено исключений.
  2. Обновления очень просты. Просто измените номер версии, обновите, и все готово.
  3. Это избавляет от необходимости фиксировать двоичные файлы для контроля версий. Они могут быть проблематичными, когда приходит время объединять ветви.
  4. Если у вас нет явной политики в отношении версии двоичных файлов в каталоге lib, легко потерять отслеживание того, какие версии у вас есть.
0 голосов
/ 07 июня 2011

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

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

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

...