Ответ 1
Что случилось с файлом WAR, исполняемым? Разве это не то, что вам действительно нужно?
P.S. как java -jar name.war
Есть ли способ, чтобы один загрузочный проект Spring мог быть упакован как в JAR, так и в WAR без изменения pom.xml
или источника приложения?
Я не ожидаю, что mvn package
сделает оба. То, что я хочу, это что-то вроде mvn i-want-a-jar
, и это будет пакет проекта как JAR. Или я мог бы запустить mvn i-want-a-war
, и он упаковал бы проект как WAR.
Возможно ли это?
Что случилось с файлом WAR, исполняемым? Разве это не то, что вам действительно нужно?
P.S. как java -jar name.war
Мне удалось это сделать, добавив
<packaging>${packaging.type}</packaging>
в файл POM, а затем установить разные профили для JAR и WAR:
<profiles>
<profile>
<id>jar</id>
<properties>
<packaging.type>jar</packaging.type>
</properties>
</profile>
<profile>
<id>war</id>
<properties>
<packaging.type>war</packaging.type>
</properties>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-tomcat</artifactId>
<scope>provided</scope>
</dependency>
</dependencies>
</profile>
</profiles>
Теперь mvn package -P war
создает WAR и mvn package -P jar
создает JAR.
Другой вариант - создать отдельные модули для JAR и WAR, но я не пошел по этому маршруту.
Недавно у нас было аналогичное требование, где существующий проект Spring Boot, который был первоначально упакован как исполняемый Jar, необходимый для поддержки развертываний Tomcat и WildFly.
Из-за некоторых зависимостей, используемых в этом проекте (например, WebJars), простой переключатель в WAR-пакет не был вариантом, поскольку некоторые из этих зависимостей были необходимы для WildFly (поддержка VFS), но не для другого развертывания.
Решение заключалось в том, чтобы реструктурировать модули проекта таким образом, чтобы основной модуль содержал фактический проект, но не применял плагин Spring Boots, в то время как несколько модулей модулей зависели от основного модуля и настраивали особенности артефакта развертывания (Boot и другие плагины, специфические для развертывания зависимости и т.д.).
Таким образом, сборка проекта могла генерировать несколько артефактов развертывания (Boot исполняемый JAR, традиционная WAR и WildFly специфическая WAR) в одном запуске сборки.
В случае, если кто-либо найдет это полезным, образец проекта для демонстрации подхода доступен в Github. Он основан на Gradle, но подход в целом должен быть возможен и с Maven.