Ответ 1
Получил ответ, который может не сработать для вас, поскольку он скорее зависит от многих вещей и обстоятельств, НО я подозреваю, что это действительно актуально для большинства людей здесь.
Устранение неполадок
(Пропустите, если вам неинтересно, как я понял это для своих настроек, но это может помочь вам. Решение 1 - это то, что вы хотите, если вы нетерпеливы.)
Как это началось...
Текущая рабочая директория активно развивающегося проекта начала выплевывать журналы, демонстрирующие это поведение сегодня, когда каких-либо ошибок не было. Я использовал Windows 7, Maven 3.0.4, плагин 2.4 компилятора и java (c) 1.6.0_31.
При достижении определенного подмодуля maven выплевывает некоторые сообщения об ошибках и отказывает сборку, за исключением того, что сообщения об ошибках не связаны (сообщая о использовании проприетарных API com.sun.*), и не было бы признаков фактической ошибки компиляции.
Вещи становятся странными...
В этот момент я нахожу этот поток, и я также пытаюсь перестроить с различными версиями java и версиями maven-compiler-plugin. Здесь интересная часть:
- с компилятором-плагином 2.5, я бы получил аналогичную проблему и не был действительный отчет об ошибке;
- с плагином 2.3 компилятора, я бы получил аналогичную проблему с бессмысленным сообщением об ошибке, сообщающим о недостающем пакете (который присутствует и в пути к классам, хотя!);
- с плагином 2.3.2 компилятора, я бы получил аналогичную проблему с бессмысленным сообщением об ошибке, сообщающим о недостающем пакете (который присутствует и в пути к классам, хотя!) НО * * в другой точке ** в компиляции тестовых классов модуля (ранее это происходило при компиляции нормальных классов).
От Weird to Weirder
Подозрившись, я переключился на другой каталог с чистой проверкой проекта и переделал все.
Все работало FINE. Путаница и отчаяние здесь.
Итак, я понял, что работал над довольно огромным и сложным классом в другой рабочей области, в неисправном модуле. И я имею в виду довольно огромный, сложный и довольно плохо написанный. Тип зверя, который заставляет вас сказать своему боссу "пожалуйста, не заставляйте меня касаться этого", и это заставляет ваш ключ DELETE щекотать вас каждый раз, когда у вас есть несчастье бегать по нему в вашей среде IDE. На самом деле, эта штука так же похожа на потомство темного маржического эксперимента и странно неэтичного биоресурса, что вы задаетесь вопросом, не произошло ли это из RTC Wolfenstein или Doom, если антагонисты были битами кода. Класс, который вы не хотите оставлять в покое, чтобы закодировать по ночам, и для которого Sonar спокойно сообщает о нарушениях качества кода 1000, включая индексы сложности, которые заставляют вас задаться вопросом, действительно ли PMD, JDepend и другие инструменты не имеют ход в то же время).
Но я отвлекаюсь...
Я скопировал его на это чистое и, казалось бы, рабочее рабочее пространство (к счастью для меня это не повлияло на другие файлы, поэтому было довольно просто: просто скопировать).
Затем я перестраиваю с Maven, и он становится все расшатанным, когда он снова возвращается к модулю, содержащему этот файл, за исключением того, что на этот раз он выдает load ошибки stacktrace, которые не заканчиваются. Поэтому я хочу попробовать повторно запустить ту же сборку, на этот раз сохраняя вывод в файле журнала, чтобы иметь более пристальный взгляд и (здесь новая странная вещь, потому что пока это было не странно)... это снова не обнаруживает ошибок.
Итак, я полагаю, что что-то явно очень противно, потому что javac перебирается с тем, что выглядит как переполнение стека, и ищите бит stacktrace, который я видел в своем журнале в первый раз. Вот кусок этого (как я подозреваю, некоторые могут столкнуться с этим и найти этот ответ полезным):
[ERROR] at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:360)
[ERROR] at com.sun.tools.javac.comp.Attr.attribExpr(Attr.java:377)
[ERROR] at com.sun.tools.javac.comp.Attr.visitApply(Attr.java:1241)
[ERROR] at com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1210)
[ERROR] at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:360)
[ERROR] at com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:1799)
[ERROR] at com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:1522)
[ERROR] at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:360)
[ERROR] at com.sun.tools.javac.comp.Attr.attribExpr(Attr.java:377)
[ERROR] at com.sun.tools.javac.comp.Attr.visitApply(Attr.java:1241)
[ERROR] at com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1210)
[ERROR] at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:360)
[ERROR] at com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:1799)
[ERROR] at com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:1522)
И Google красиво указывает мне на... StackOverflow, конечно:)
Компиляция Maven: сбой выполнения javac
Где я могу увидеть легкую вещь, чтобы попробовать (см. ниже).
Конечно, для устранения неполадок было бы проще облегчить, если бы во всех ситуациях и во всех случаях отображалась функция stacktrace, и было показано очевидное исключение StackOverflowException. Особенно учитывая, что в противном случае я уже видел эту ошибку и знаю, что это значит, но это намного сложнее понять, когда вы ** не можете видеть * ошибку.
Не знаю, почему Maven проглотил этот, но, может быть, javac просто разбился без предупреждения, и в управлении журналом произошла ошибка, и он не вымывается должным образом.
Это также объясняет, почему эта ошибка происходит относительно случайным образом: это повлияет на ваши аппаратные настройки, и небольшие изменения в классах javac передаются процессу.
Итак, теперь что??? Ну, если есть сумасшедшее исключение или исключение OutOfMemoryException, когда java пытается обработать ваш код, очевидно, вам нужно сделать что-то похожее на то, что объяснено ниже...
Решение
Решение 1 (также называемое "кратковременное/быстрое n-грязное/просим-делать-работать" )
Обновите настройки памяти. Самый простой способ - с чем-то вроде (для bash -подобной оболочки):
export MAVEN_OPTS="-Xss1024k -Xms512m -Xmx1024m"
BEWARE. Эти настройки будут зависеть от вашего оборудования платформы, очевидно (и от вашей оболочки).
В моем случае, я действительно имел обыкновение иметь:
export MAVEN_OPTS="-Xss128k -Xms384m -Xmx384m"
... потому что у меня довольно тяжелый проект и не такая рабочая станция, способная работать с памятью, поэтому мне нужно сжать каждый бит оперативной памяти, из которого я могу это сделать, чтобы иметь несколько экземпляров Eclipse, несколько серверов приложений и т.д.. Таким образом, мои JAVA_OPTS, ANT_OPTS и MAVEN_OPTS установлены с множеством опций, включая их.
Это не обязательно то, что вам нужно! По умолчанию xss для 64-битной JVM для Windows на самом деле 1024, поэтому я использую что-то значительно меньшее. Я просто говорю это, поскольку это может помочь другим в той же ситуации. Попытайтесь поднять его соответствующим образом и разумно для вас.
Итак, в конце концов, чтобы исправить эту конкретную проблему в моем проекте, мне пришлось изменить выше:
export MAVEN_OPTS="-Xss256k -Xms384m -Xmx384m"
И теперь все работает peachy.
Возможно, некоторые другие вещи для вас разные. Дайте мне знать.
Решение 2 (также называемое "long-term/zen" )
Вы знаете, что лучше, чем возиться с настройками памяти, которые другие не знают, чтобы возиться с ними и, возможно, не имеют возможности, и что ваши сборки менее переносимы? [аудитория кричит здесь]
Вы реорганизуете ад из этого приклада-уродливого класса, который заставляет javac плакать за свою маму.
Это так просто. Не тысячи и тысячи строк длинных классов, с сумасшедшими статическими инициализаторами, сверхтонкими методами и тому подобным. Если ваш код выглядит вам сложным, он уверен, что и для бедных javac.
Сохранить процесс javac сегодня: реорганизовать свой код!