Spring MVC/Security, REST, Hibernate, Liquibase запускаем в две строки

[@vayho]

Есть же Spring Boot где это все уже есть. И и с xml пора бы уже мигрировать.

[@vayho]

Поясню немного подробнее, конфигурация которую вы предлагаете развернуть как мне кажется немного устарела. Есть Spring Boot с плагином для Maven и Gradle которые позволяет развернуть приложение за 15 минут. И там уже все будет и БД и локализация и JPA и Security.
Очевидно что количество программистов которых раздражает xml > количества программистов которых раздражает Java API. Поэтому без видимых преимуществ xml лучше сменить на Java, благо Spring на текущий момент предлагает красивое Java API. Тут и CDI аннотации и Spring аннотации и красивые билдеры.

[@intet]

Я бы поспорил с развертыванием приложения за 15 минут. Проблемы возникнут уже на стадии подготовки базы данных, простого решения разделить sql скриптов на две группы (одна для всех, другая только для разработки) я не вижу. С локализацией тоже есть вопросы — не генировать же страницы из jsp каждый раз при запросе? Компиляцию javascript/css тоже придется прикручивать. Но возможно стоило все-же использовать Spring Boot.

По поводу xml — это вопрос предпочтений. Мне лично кажутся немного странными классы в которых почти нет логики, зато куча параметров. И xml и java код не являются в данном случае идеальными.

[@vayho]

Для решения таких проблем Spring предлагает профили.
Например вот тут https://docs.spring.io/spring-boot/docs/current/reference/html/howto-database-initialization.html внизу описан процесс интеграции с liquabase. С помощью профилей можно переопределить параметры liquabase и грузить разные ченджлоги для разных режимов работы.

Вот пример(application.yml):

spring:
  profiles:
    active: development

---

spring:
  profiles: production
liquibase:
  changeLog: "classpath:/db/changelog/db.changelog-production.yaml"

---

spring:
  profiles: development
liquibase:
  changeLog: "classpath:/db/changelog/db.changelog-development.yaml"

По поводу локализации, компиляции js/css. В режиме разработки мы просто отключаем кеширование файлов с локализацией(обычно messages/messages.properties) и соответственно каждый раз данные берутся заново. Так же мы не компилируем js/css в режиме разработки. А вот уже в проде мы все компилируем сжимаем оптимизируем. Но эта задача лежит на Maven и Teamcity.
Кстати почему JSP? Есть же Thymeleaf(мы его не любим) и куча других шаблонизаторов, мы используем простеньки Pebble Engine. Но он расширяем и покрывает весь спектр наших задач.

[@intet]

В приведенном приложении так и сделано Js/css компилируется и сжимается только в случае боевого использования. Во время разработки файлы только линкуются, чтобы не было проблем с подключением страницы.
И как раз-таки настройка Teamcity, добавление профилей и прочие мелочи не позволят уложиться в 15 минут на запуск.

Кстати почему JSP?

Не хватило времени разобраться в разных шаблонизаторах. Хотелось один раз сгенирировать страницы, сложить в статичные ресурсы, а дальше лишь обрабатывать данные.

[@danaki]

https://jhipster.github.io/

[@feligz]

Недавно попробовал Jhipster, упомянутый выше, развернул базовое приложение с ангуляром за 5 минут, из которых 4 в проект загружались библы из инета.

[@intet]

С помощью jhipster очень удобно создавать основу проекта. Но в плане обучения у него есть существенный недостаток — создается все и сразу. Понять что к чему относиться, как работает, новичку очень трудно.
В целях образования полезно один раз пройти этап построения приложения от начала до самого конца и вот тут начинаются проблемы. Большинство обучающих материалов рассматривают лишь самый простые вещи, каждую по отдельности, а на интеграции возникают сложности.