Ошибка запуска игры 2.3

У меня возникла проблема при запуске последней версии play framework 2.3. Он компилируется просто отлично, хотя, когда я делаю activator run, возникает эта ошибка:

java.lang.NoSuchMethodError: scala.Predef$.ArrowAssoc(Ljava/lang/Object;)Ljava/lang/Object;

Полный журнал ошибок

Я явно пробовал scalaVersion в каждом файле build.sbt, и это одно и то же. Я пробовал несколько вещей, таких как activator clean, полное удаление кешей ОС sbt и локального репозитория sbt, обновление зависимостей до последней версии, но безуспешно. У меня есть версия scala.

Мои текущие зависимости: я пытался использовать как %%, так и принудительно _2.11 в имени зависимости.

Список зависимостей

Другие важные файлы

build.sbt

Common.scala

Dependencies.scala

Когда я полностью очищаю кеши, он загружает scala 2.10.4 без всякой причины: в этом журнале загрузки говорится, что sbt нужен старая скала. Любая идея, почему это?

Любые идеи?


scala playframework playframework-2.3
person rtfpessoa    schedule 13.06.2014    source источник
comment
Вы используете зависимость ws, предоставленную Play, но вы импортируете библиотеки JDBC и JSON отдельно. Это почему?   -  person DCKing    schedule 13.06.2014
comment
Это для подпроекта, которому не нужна вся игра.   -  person rtfpessoa    schedule 13.06.2014
comment
Это кажется актуальным: stackoverflow.com/questions/13098856/ . Что, если добавить scalaVersion в большее количество мест?   -  person DCKing    schedule 13.06.2014
comment
Я пробовал использовать scalaVersion явно в каждом файле build.sbt, и это точно так же.   -  person rtfpessoa    schedule 13.06.2014
comment
DCKing Я только что добавил журнал загрузок, у вас есть идеи, почему это так?   -  person rtfpessoa    schedule 13.06.2014
comment
Ваша сборка довольно сложная; кажется вероятным, что что-то вызывает какое-то поведение по умолчанию для SBT. Говорит ли вам о чем-нибудь информация об отладке?   -  person DCKing    schedule 13.06.2014
comment
last run — это то, что я впервые опубликовал в журнале. Он имеет полный журнал. И он взрывается за пределами моего кода, вот что делает это странным.   -  person rtfpessoa    schedule 13.06.2014
comment
Давайте продолжим обсуждение в чате.   -  person rtfpessoa    schedule 13.06.2014

Ответы (3)


arrow_upward
1
arrow_downward

Во-первых, не имеет значения, какая версия Scala используется для генерации вашей сборки. Система сборки может использовать версию 2.10.4, и это не мешает вашему коду использовать версию 2.11.1.

Чтобы посмотреть на проблему с вашей версией scala, вы должны учитывать, что настройки, добавленные непосредственно в build.sbt, добавляются в корневой проект, но не в другие проекты. Вы можете увидеть это с минимальным проектом, таким как:

$ cat build.sbt
scalaVersion := "2.11.1"

lazy val subproj = project in (file("subproj"))

Тогда вывод sbt выглядит так:

> show scalaVersion
[info] subproj/*:scalaVersion
[info]  2.10.4
[info] sbttest/*:scalaVersion
[info]  2.11.1

Итак, как это можно исправить?

Мы можем создать lazy val, содержащий Seq[Setting[_]], и добавить его в определение подпроекта с помощью метода settings().

Вот пример build.sbt, который добавляет одинаковые настройки ко всем проектам:

$ cat build.sbt
lazy val root = project.in(file("."))
  .aggregate(subproj)
  .dependsOn(subproj)
  .settings(commonSettings: _*)

lazy val subproj = project.in(file("subproj"))
  .settings(commonSettings: _*)

lazy val commonSettings = Seq(
  scalaVersion := "2.11.1"
)

_* требуется, потому что settings() определено как требующее Setting[_]*, а не Seq[Setting[_]], поэтому _* выполняет преобразование между двумя типами. См. также: Что означает param: _* в Scala?

И вывод из sbt:

> show scalaVersion
[info] subproj/*:scalaVersion
[info]  2.11.1
[info] root/*:scalaVersion
[info]  2.11.1

Этот подход можно легко применить к вашей сборке.

person Gary Coady    schedule 14.06.2014
comment
На самом деле у меня так. Разница в том, что вместо того, чтобы помещать версию в основной build.sbt, я имею ее во всех них, когда я импортирую свой Commons.scala. Так что я думаю, что ваш ответ не добавляет много к проблеме. Как я уже объяснял, я даже пытался поместить его в каждый файл. Так что это не импорт отсутствующей версии. На самом деле при компиляции прямо сказано, что каждый компонент 2.11. Тем не менее я не нахожу реальной ошибки. Любые идеи? - person rtfpessoa; 14.06.2014
comment
Судя по вашему образцу build.sbt, один подпроект: lazy val precog = project.in(file(components/precog)).dependsOn(frameworkDependency, dependencyBuilder).aggregate(framework, dependencyBuilder) Обратите внимание, что здесь есть никакие настройки не определены. Импорт Commons._ не поможет, если вы также не добавите его в проект, например. lazy val precog = project.in (file (components/precog)). через метод settings(). - person Gary Coady; 14.06.2014
comment
Хорошо, вы не понимаете, что я говорю. В подпроекте build.sbt у меня есть appSettings. Хотя, даже если то, что я говорю, было неправильным, я попробовал вашу команду и получил версию всех подпроектов как 2.11.1. Так что проблема точно не в этом. У тебя есть другие идеи? Например, у меня есть подпроект, который также является игровым проектом, должен ли он иметь какие-либо отличия в его build.sbt? - person rtfpessoa; 14.06.2014
comment
Копия build.sbt, упомянутая в вопросе, устарела? Потому что, если я возьму предоставленные вами файлы, я увижу, что некоторые проекты имеют scalaVersion 2.10.4. Если я внесу предлагаемые изменения, все проекты будут иметь scalaVersion 2.11.1. При импорте предоставленного вами файла Commons.scala эти настройки не будут автоматически применяться к подпроектам. Он будет применять их только к корневому проекту. - person Gary Coady; 14.06.2014
comment
Как я уже сказал, это только build.sbt основного проекта. Остальные импортируют Commons._ и имеют appSettings в теле, чтобы он расширял настройки. Тем не менее, чтобы убедиться, я только что перешел на ваш способ (который на самом деле более организован), но я получаю точно такую ​​​​же ошибку. Кстати, ошибка может быть не о версии, о которой я только что сказал, потому что ошибки версии очень похожи на эту. Любые другие идеи? - person rtfpessoa; 14.06.2014
comment
Если вы хотите, вы можете прийти сюда: chat.stackoverflow.com/rooms/55574/ и мы можем лучше поболтать. Это больше место для комментариев. - person rtfpessoa; 14.06.2014
comment
Можете ли вы запустить show scalaVersion из sbt? Это покажет, какую версию scala ожидают ваши проекты. Во всех строках должно быть написано 2.11.1, иначе этот проект не подхватывает ваши настройки. (У меня недостаточно репутации, чтобы использовать интерфейс чата). - person Gary Coady; 14.06.2014
comment
Я сказал 3 ответа выше, я сделал это. И в каждой строчке написано версия 2.11.1. Ни один из них 2.10.4. - person rtfpessoa; 14.06.2014
comment
Хорошо, тогда мы хотя бы знаем, что настройки версии работают. Кроме того, я видел подобную проблему раньше, когда libraryDependency использовал старую версию scala-library. Попробуйте показать libraryDependencies и посмотрите, включены ли какие-либо библиотеки _2.10? scala-library:2.10.4 было бы особенно плохо иметь в списке. - person Gary Coady; 14.06.2014
comment
Только что протестировал: show libraryDependencies, но кажется, что он просто показывает мои явные зависимости, и все они 2.11. Он не показывает рекурсивные зависимости. - person rtfpessoa; 14.06.2014
comment
Ах. Можете ли вы попробовать github.com/jrudolph/sbt-dependency-graph, а затем запустить dependencyTree . Чтобы указать причину, по которой такие вещи могут вызвать проблему: я видел проблему, когда сборка scala 2.9 включала akka 2.x, которая сама транзитивно зависела от scala-library 2.10. В результате возникла ошибка при поиске базового класса scala (Option). - person Gary Coady; 14.06.2014
comment
Только что протестировано. У него есть ошибки, он говорит, что для некоторых подпроектов отсутствует файл, и каждый раз, когда я запускаю, подпроекты разные. Что это может быть? - person rtfpessoa; 14.06.2014
comment
Кажется, это связано с параллелизмом. После отключения параллелизма зависимости заработали, но нет 2.10, все они 2.11. Любые идеи? - person rtfpessoa; 14.06.2014
comment
Fiadliel Я только что обнаружил, что некоторые депо используют 2.11.0, а не 2.11.1. Может ли это быть проблемой? +-org.scala-lang:scala-library:2.11.0 (evicted by: 2.11.1) - person rtfpessoa; 14.06.2014
comment
только что попытался изменить scalaVersion на 2.11.0, он компилируется, но все та же ошибка. - person rtfpessoa; 14.06.2014
comment
Возможно, если вернуться к истокам, проблема выглядит как несовместимость между игровыми библиотеками и scala-библиотеками в пути к классам — больше ничего не должно иметь значения. Если вы посмотрите (внимательно) на вывод show fullClasspath, там должна быть только одна scala-library-2.11.x.jar и никаких других версий; также должен быть только один play_2.11-2.3.0.jar и никаких других play (например, play_2.10). - person Gary Coady; 14.06.2014
comment
Еще одна вещь, которую стоит попробовать: выполните команду sbt dist, чтобы создать распространяемый файл архива. Это может облегчить анализ того, какие версии библиотек включены в сборку. - person Gary Coady; 14.06.2014
comment
После дистрибутива в папке есть конфликтующие банки: pastebin.com/yBdJFd8n Есть идеи, почему? - person rtfpessoa; 14.06.2014
comment
кто-то добавил банки вручную в папку lib. Вероятно, так оно и было (не знаю, почему?). сейчас тестирую. Извините за беспокойство и большое-много-многое спасибо за вашу помощь. Только что проголосовал за вашу помощь, надеюсь, вы быстро растете здесь. Очень добрый и терпеливый :D - person rtfpessoa; 14.06.2014
comment
Приятно знать, что вы это поняли! Будет полезно (в конце концов) получить возможность использовать этот чат. И еще: упомянутые в чате файлы разрешения-кэша могли быть полезны. Но файл -runtime.xml, который вы разместили, был взят из каталога project/target/resolution-cache/reports, в котором показана конфигурация сборки (полезно, если сборка не удалась). Вы должны посмотреть файл-runtime.xml из target/resolution-cache/reports, и он мог показать проблему с путем к классам среды выполнения. - person Gary Coady; 15.06.2014
comment
Спасибо, так как я принял ответ и проголосовал за него, теперь у вас есть 26 баллов и вы можете общаться. :D - person rtfpessoa; 15.06.2014

arrow_upward
0
arrow_downward

Вы неправильно определяете свои зависимости.

При использовании SBT не используйте:

"org.mydep" % "mydep_2.11" % "1.0.0"

Вместо этого используйте:

"org.mydep" %% "mydep" % "1.0.0"

Оператор %% автоматически добавляет текущую версию Scala к текущей сборке. Если вы используете зависимости, созданные для других версий Scala, вы будете получать странные ошибки.

Также убедитесь, что вы где-то явно указали свою версию Scala:

scalaVersion := "2.11.1"
person DCKing    schedule 13.06.2014
comment
Это тоже не проблема, я пытался это заставить. Но так или иначе происходит одно и то же. ПРИМЕЧАНИЕ: обновлен начальный пост с этой информацией. - person rtfpessoa; 13.06.2014
comment
@rtfpessoa Я думаю, вам следует опубликовать полный файл сборки. Недостаточно информации, где сейчас что-то может пойти не так. - person DCKing; 13.06.2014
comment
что вы подразумеваете под файлом сборки? - person rtfpessoa; 13.06.2014
comment
@rtfpessoa Файл build.sbt или Build.scala, в зависимости от того, что вы используете для сборки и запуска приложения. - person DCKing; 13.06.2014

arrow_upward
0
arrow_downward

Проблема была связана с некоторыми добавленными вручную jar-файлами, которые я обнаружил в папке lib и которые вызывали проблемы с зависимостями проекта, определенными в build.sbt. Единственный способ выяснить это — сгенерировать activator dist и поискать похожие зависимости с разными версиями, так как в графе зависимостей не было конфликтов.

person rtfpessoa    schedule 13.06.2014