Каталог src / main / webapp не распознается Eclipse

1. Это правильное поведение? (Я думал, что это можно рассматривать как другие ресурсы ...)
2. Могу я это исправить?
3. Интересно, есть ли в этой ситуации другие недостатки, о которых я бы не знал прямо сейчас?

1. Да, для меня это правильное поведение.
2. На самом деле нет смысла использовать src / main / webapp в качестве исходной папки, она не содержит компилируемых исходных файлов.
3. Я не знаю. Думаю, это зависит от ваших ожиданий :)

Тем не менее, m2eclipse внес свой вклад, который позволяет сделать src/main/webapp доступным на верхнем уровне с определенной меткой «Веб-ресурсы», примерно так:

Это может быть решением вашей проблемы (неудобное складывание).

Вместо добавления / src / main / webapp в качестве исходной папки в путь сборки Java добавьте его в качестве папки для включения в сборку развертывания:

MyProject -> properties -> Deployment Assembly: добавьте «/ src / main / webapp», развертываемый в «/»

Что касается maven, src/main/webapp не является исходной папкой в ​​том смысле, что ее содержимое не компилируется / не копируется в target/classes, поэтому с точки зрения m2eclipse это правильное поведение. Есть ли какая-то конкретная причина, по которой вам нужно пометить src / main / webapp как исходную папку Eclipse?

Вам просто нужно пометить src / main / webapp как папку src Eclipse:

щелкните правой кнопкой мыши папку webapp -> путь сборки -> использовать в качестве исходной папки

Не думайте, что вы можете легко изменить это поведение без каких-либо уродливых хаков, маркировка src - это просто что-то специфическое для Eclipse, которое он использует для настройки своего пути к классам и т. Д.

В моем случае Eclipse не смог распознать src/main/webapp как папку веб-ресурсов. Я решил это:

1. Удаление проекта
2. Перезапуск затмения
3. Получение свежего обновления проекта Maven из SVN.

Во многих ответах утверждается, что не имеет смысла иметь src/main/webapp в качестве исходной папки, потому что файлы JSP компилируются контейнером, а не maven во время цикла сборки.

Однако это имеет смысл, когда вы проводите тестирование безопасности:

Некоторые инструменты сканирования безопасности предоставляют плагины, которые можно интегрировать в IDE, чтобы группы разработчиков могли локально сканировать свой код и исправлять базовые уязвимости на своих машинах, тем самым сокращая объем работы для групп безопасности, которые, следовательно, могут работать над более сложным тестированием.

Тот факт, что Eclipse исключает этот конкретный каталог, является огромной проблемой: при этом инструменты безопасности не будут включать по умолчанию каталог webapp/ в процесс сканирования, что приводит к ложным отрицательным результатам (фактические уязвимости, которые не Инструмент не сообщает). Такое поведение затем приводит команды разработчиков к мысли, что их страницы JSP (например) безопасны с точки зрения безопасности.

Если группы тестирования безопасности не обращают внимания на проверки, проводимые группами разработчиков (иногда мы даже не можем проверить, какие проверки были выполнены локально), продукт, скорее всего, будет выпущен с уязвимостями в коде, содержащемся в папке webapp/.

Таким образом, такое поведение не имеет смысла с точки зрения безопасности, и люди, утверждающие, что это так, упускают некоторые моменты.

В любом случае я решил эту проблему, добавив папку src/main/webapp/ в путь сборки, щелкнув ее правой кнопкой мыши в package explorer -> build path -> use as source folder

Одно из решений - использовать поддержку m2e для подключаемого модуля build helper maven и объявить src / main / webapp как дополнительный путь к ресурсам. Это также заставляет eclipse копировать сохраненные ресурсы в структуру целевой папки сборки.

        <!-- help eclipse identify the webapp folder as a resource folder: -->
        <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>build-helper-maven-plugin</artifactId>
            <version>3.0.0</version>
            <executions>
                <execution>
                    <id>add-resource</id>
                    <phase>generate-resources</phase>
                    <goals>
                        <goal>add-resource</goal>
                    </goals>
                    <configuration>
                        <resources>
                            <resource>
                                <directory>src/main/webapp</directory>
                                <targetPath>${project.build.directory}/${project.build.finalName}</targetPath>
                            </resource>
                        </resources>
                    </configuration>
                </execution>
            </executions>
        </plugin>

Я могу придумать причину.

Я использую Maven для разработки проекта GWT в Eclipse. В моей конфигурации каталог src / main / webapp содержит файлы HTML и CSS, на которые я должен ссылаться в рамках моих усилий по разработке, даже если они не являются «компилируемыми» файлами.

Возможность получить к ним прямой доступ, а не нырять в папку src /, является плюсом. И определение его в POM, чтобы он был настроен таким образом, означает, что мне не нужно вручную добавлять папку каждый раз, когда я запускаю eclipse: eclipse.

Что касается Нестора, без шуток. Это сквозная среда разработки, а не просто компилятор. Он задуман как интерфейс для всех исходных артефактов, участвующих в сборке из JSP для создания конфигурации, такой как файлы POM. Зачем Eclipse вообще беспокоиться о редакторах XML и JSP, если они не компилируются? - Которые, кстати, суперполезные.

Плагин maven для eclipse (или наоборот) потрясающий, потому что он создает .classpath, .project и другие конфигурации, необходимые для немедленного начала работы с проектами maven в eclipse. Однако каждый раз, когда создается конфигурация eclipse (т.е. mvn eclipse: eclipse), неподдерживаемые каталоги необходимо добавлять вручную. Это большой отстой.

Тот факт, что эти плагины игнорируют возможность простого добавления новых исходных папок, просматриваемых из среды IDE, для меня загадка. На одной странице проекта плагина maven / eclipse даже упоминаются обходные пути для того, чтобы сделать эти источники временно доступными, переключив типы проектов и обманув плагин - конечно, вам нужно немедленно изменить его обратно или повредить сборку.

Почему бы им просто не создать возможность независимо управлять объявлениями источников в .classpath ???

Я нашел совершенно другую причину той же проблемы, с которой столкнулся - я не видел src / main / webapp в проводнике пакетов.

Оказалось, что это не имеет ничего общего ни с POM, ни с тем, что Eclipse (с использованием SpringSource Suite 3.5.0) может загружать проект maven.

Проблема заключалась в том, что внутри моей папки src / main / webapp / Scripts / были файлы .git и .gitignore. Я подозреваю, что, возможно, Eclipse не смог справиться с именами файлов, начинающимися с "." в папке webapp. Я проверял эту теорию в нескольких проектах, и пока она, похоже, не вызывает сомнений.

Надеюсь, это поможет.