Компиляция Maven завершается неудачно - нерешенные проблемы компиляции

2

У меня есть интересная проблема с spring сборкой webapp maven. При построении внутри eclipse все прекрасно, но при построении через maven и развертывании в контейнере tomcat 8 webapp сбой при запуске со следующей ошибкой:

Caused by: java.lang.NoClassDefFoundError: FilterConfig

Теперь я перепробовал все проблемы зависимости очевидные и хорошо документированные (настройка сферы, предусмотренный на javax.servlet-апи и импорта JSP-апи и убедившись, что они из последних версий, как это проект Java 8). Я убедился, что все плагины-компиляторы имеют последние версии:

Maven-плагин войны 3.1.0

Maven-компилятор-плагин 3.6.1

но веб-сервер не запускается без ошибок, отображаемых на выходе консоли maven. После долгих головы почесывания и кропотливого сравнения между (рабочим) затмением строить и таинственно неудовлетворительные мавенный эквивалентной было обнаружено, что в некоторых из файлов классов, порожденных мавенны были тексты, описывающие проблемы компиляции. (Из опции "Открыть s > Текстовым редактором" в eclipse из файла .class было извлечено следующее: некоторые символы должны были быть опущены, поскольку они не будут копировать правильно)

Unresolved compilation problems: 
    The import javax.servlet.Filter cannot be resolved
    The import javax.servlet.FilterChain cannot be resolved
    The import javax.servlet.FilterConfig cannot be resolved
    The import javax.servlet.ServletException cannot be resolved
    The import javax.servlet.ServletRequest cannot be resolved
    The import javax.servlet.ServletResponse cannot be resolved
    The import javax.servlet.http.HttpServletRequest cannot be resolved
    The import javax.servlet.http.HttpSession cannot be resolved
    Filter cannot be resolved to a type
    FilterConfig cannot be resolved to a type
    ServletException cannot be resolved to a type
    ServletRequest cannot be resolved to a type
    ServletResponse cannot be resolved to a type
    FilterChain cannot be resolved to a type
    ServletException cannot be resolved to a type
    HttpServletRequest cannot be resolved to a type
    HttpServletRequest cannot be resolved to a type
    HttpSession cannot be resolved to a type

Я не могу понять, как процесс maven завершается успешно и что никакие ошибки не отображаются ни с одним из целей mvn, которые я пробовал

mvn complier: compile

[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building xxxx 2.0.1
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ EBPP ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 5 resources
[INFO]
[INFO] --- maven-compiler-plugin:3.6.1:compile (default-compile) @ EBPP ---
[INFO] Nothing to compile - all classes are up to date
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2.413 s
[INFO] Finished at: 2017-06-28T15:11:45+01:00
[INFO] Final Memory: 9M/213M
[INFO] ------------------------------------------------------------------------

выше, но с -x показал много отладочного вывода, но ничего не предлагать проблемы с компиляцией, на самом деле он утверждает, что в файле класса определены неразрешенные зависимости

...
[DEBUG]    javax.servlet:javax.servlet-api:jar:3.1.0:provided  
[DEBUG]    org.apache.velocity:velocity:jar:1.7:compile
[DEBUG]    commons-collections:commons-collections:jar:3.2.1:compile 
[DEBUG]    commons-lang:commons-lang:jar:2.4:compile 
[DEBUG]    javax.servlet.jsp:jsp-api:jar:2.2:provided 
...

mvn dependency: build-classpath

[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building xxxx 2.0.1
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-dependency-plugin:2.8:build-classpath (default-cli) @ EBPP ---
[INFO] Dependencies classpath:
C:\Users\xxxxxx\.m2\repository\org\springframework\webflow\spring-webflow\2.4.5.RELEASE\spring-webflow-2.4.5.RELEASE.jar;C:\Users\xxxxxx\.m2\repository\commons-logging\commons-logging\1.2\commons-logging-1.2.jar;C:\Users\xxxxxx\.m2\repository\opensymphony\ognl\2.6.11\ognl-2.6.11.jar;C:\Users\xxxxxx\.m2\repository\org\springframework\webflow\spring-binding\2.4.5.RELEASE\spring-binding-2.4.5.RELEASE.jar;C:\Users\xxxxxx\.m2\repository\org\springframework\webflow\spring-js\2.4.5.RELEASE\spring-js-2.4.5.RELEASE.jar;C:\Users\xxxxxx\.m2\repository\org\springframework\webflow\spring-js-resources\2.4.5.RELEASE\spring-js-resources-2.4.5.RELEASE.jar;C:\Users\xxxxxx\.m2\repository\org\springframework\spring-beans\4.3.0.RELEASE\spring-beans-4.3.0.RELEASE.jar;C:\Users\xxxxxx\.m2\repository\org\springframework\spring-context\4.3.0.RELEASE\spring-context-4.3.0.RELEASE.jar;C:\Users\xxxxxx\.m2\repository\org\springframework\spring-aop\4.3.0.RELEASE\spring-aop-4.3.0.RELEASE.jar;C:\Users\xxxxxx\.m2\repository\org\springframework\spring-expression\4.3.0.RELEASE\spring-expression-4.3.0.RELEASE.jar;C:\Users\xxxxxx\.m2\repository\org\springframework\spring-web\4.3.0.RELEASE\spring-web-4.3.0.RELEASE.jar;C:\Users\xxxxxx\.m2\repository\org\springframework\spring-webmvc\4.3.0.RELEASE\spring-webmvc-4.3.0.RELEASE.jar;C:\Users\xxxxxx\.m2\repository\org\springframework\spring-core\4.3.9.RELEASE\spring-core-4.3.9.RELEASE.jar;C:\Users\xxxxxx\.m2\repository\com\xxxxxxx\ebpp\JComms\2.0.1\JComms-2.0.1.jar;C:\Users\xxxxxx\.m2\repository\log4j\log4j\1.2.17\log4j-1.2.17.jar;C:\Users\xxxxxx\.m2\repository\javax\mail\mail\1.4.7\mail-1.4.7.jar;C:\Users\xxxxxx\.m2\repository\javax\activation\activation\1.1\activation-1.1.jar;C:\Users\xxxxxx\.m2\repository\org\apache\httpcomponents\httpclient\4.5.1\httpclient-4.5.1.jar;C:\Users\xxxxxx\.m2\repository\org\apache\httpcomponents\httpcore\4.4.3\httpcore-4.4.3.jar;C:\Users\xxxxxx\.m2\repository\commons-codec\commons-codec\1.9\commons-codec-1.9.jar;C:\Users\xxxxxx\.m2\repository\commons-httpclient\commons-httpclient\3.1\commons-httpclient-3.1.jar;C:\Users\xxxxxx\.m2\repository\com\xxxxxxx\ebpp\JCore\2.0.1\JCore-2.0.1.jar;C:\Users\xxxxxx\.m2\repository\javax\servlet\javax.servlet-api\3.1.0\javax.servlet-api-3.1.0.jar;C:\Users\xxxxxx\.m2\repository\org\apache\velocity\velocity\1.7\velocity-1.7.jar;C:\Users\xxxxxx\.m2\repository\commons-collections\commons-collections\3.2.1\commons-collections-3.2.1.jar;C:\Users\xxxxxx\.m2\repository\commons-lang\commons-lang\2.4\commons-lang-2.4.jar;C:\Users\xxxxxx\.m2\repository\javax\servlet\jsp\jsp-api\2.2\jsp-api-2.2.jar;C:\Users\xxxxxx\.m2\repository\junit\junit\3.8.2\junit-3.8.2.jar;C:\Users\xxxxxx\.m2\repository\org\springframework\spring-context-support\4.3.9.RELEASE\spring-context-support-4.3.9.RELEASE.jar;C:\Users\xxxxxx\.m2\repository\com\xxxxxxx\xxxxxxx\440\xxxxxxx-440.jar
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 3.331 s
[INFO] Finished at: 2017-06-28T15:13:05+01:00
[INFO] Final Memory: 13M/213M
[INFO] ------------------------------------------------------------------------

mvn validate

[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building xxx 2.0.1
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 0.109 s
[INFO] Finished at: 2017-06-28T15:15:32+01:00
[INFO] Final Memory: 7M/213M
[INFO] ------------------------------------------------------------------------

Я действительно в тупике. Я предполагаю, что maven использует другой компилятор из eclipse, но у меня действительно закончились идеи.

Кто-нибудь еще сталкивался с этим раньше?

Спасибо заранее.

  • 0
    Длинный выстрел, но, возможно,: у вас есть «Автоматически строить», проверенный в затмении, но работающий через командную строку? Eclipse создает свое собственное здание и может попытаться сделать это в той же папке, в то же время, что и maven, и все может столкнуться.
  • 0
    хммм, я обычно делаю сборку maven внутри затмения "запустить как> Maven clean", затем "запустить как> Maven install". Просто чтобы быть уверенным, что я пытался с автоматически отключить сборку, и это все еще проблема. : - /
Теги:
maven

2 ответа

0
Лучший ответ

Поэтому, сравнивая этот проект с другим успешным проектом (который был преобразован из Java 4), подозрение, что использование нестандартных имен каталогов было причиной беспорядочного поведения mavens (при копировании warSourceDirectory). Я проанализировал каталог классов (теперь называемый) WebRoot > WEB-INF > и обнаружил, что для проблемного приложения это было заполнено, и вы уже догадались - неправильно скомпилировали файлы классов! Очевидно, что плагин войны скопировал эти плохие файлы поверх файлов, которые Maven имел, в том же процессе сборки, который просто успешно выполнялся - следовательно, нет ошибок.

Я не уверен, почему плохие файлы были там, поскольку они не были в старом проекте Java 4. Я подозреваю, что они, должно быть, были созданы каким-то образом во время предыдущей неудачной сборки maven, используя неправильные настройки.

Поделиться
1

Я подозреваю, что это сочетание затмения, строящего ваши файлы с ошибками компиляции (да, Eclipse может это сделать: если вы никогда не дойдете до не компилируемого кода, тогда вы даже не получите ошибок), а Maven не очистит вывод Eclipse в первую очередь.

Затем Maven видит, что файл обновлен и не перезаписывает его.

Я предлагаю следующее (чтобы проверить, прав ли я):

  • Отключить автоматическую сборку Eclipse (или полностью закрыть затмение).
  • Запустите цель Maven, например package, но также запустите clean (т.е. mvn clean package); точка должна быть на 100% уверена, что Maven создает эти файлы, а не Eclipse.
  • Maven теперь должен сообщать об ошибках компиляции.

Что касается самой ошибки, похоже, что у вас действительно отсутствует зависимость (но, вероятно, в классе Eclipse, а не в Maven).

Поделиться
  • 0
    Поэтому я попытался автоматически отключить сборку затмений, а затем полностью закрыл затмение после выполнения проекта в чистом виде (с отключенной проверкой запуска сборки). Затем я запустил пакет mvn в каталоге проектов (у которого на тот момент не было целевого каталога). Команда mvn выполнена успешно, без ошибок и создана целевая директория. Затем я снова открыл Eclipse, чтобы просмотреть содержимое сгенерированного файла класса (так как мои текстовые редакторы не показывают то же самое представление) ... Увы, это то же самое.
  • 0
    Между прочим, в моем пути сборки eclipse я использую только Maven Dependencies, когда-то раскрытый в окне свойств проекта показывает присутствующий javax.servlet-api-3.1.0.jar. ... Я думаю, что maven должен оставить эти нерешенные проблемы компиляции там в надежде, что код будет недоступен? Код на самом деле является фильтром, указанным в файле web.xml, поэтому он запускается при запуске.
Показать ещё 3 комментария

Ещё вопросы

Сообщество Overcoder
Наверх
Меню