generate - spring boot war

El proyecto One Spring Boot se implementa en JAR o WAR

Question

¿Hay alguna manera de que un solo proyecto de Spring Boot pueda empaquetarse en JAR y WAR sin cambiar el pom.xml o el origen de la aplicación?

He leído Cómo convertir una aplicación JAR Spring Boot en WAR , pero convierte el proyecto en WAR y pierde la capacidad de empaquetarse como JAR.

No espero que el mvn package haga ambas cosas. Lo que quiero es algo como mvn i-want-a-jar y empaquetaría el proyecto como JAR. O podría ejecutar mvn i-want-a-war y mvn i-want-a-war el proyecto como WAR.

es posible?

Answer 1

¿Qué pasa con un archivo WAR que es ejecutable? ¿No es eso lo que realmente necesitas?

PS como
java -jar name.war

Answer 2

Logré hacerlo agregando

<packaging>${packaging.type}</packaging>

al archivo POM y luego establecer diferentes perfiles para JAR y 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>

Ahora el mvn package -P war produce un mvn package -P jar WAR y mvn package -P jar produce un JAR.

Otra opción es crear módulos separados para JAR y WAR, pero no seguí esa ruta.

Answer 3

Recientemente hemos tenido un requisito similar, donde un proyecto existente basado en Spring Boot que originalmente se empaquetó como un archivo ejecutable necesitó para admitir las implementaciones de Tomcat y WildFly.

Debido a algunas dependencias utilizadas en este proyecto (por ejemplo, WebJars), un simple cambio al paquete WAR no era una opción, ya que algunas de esas dependencias eran necesarias para WildFly (soporte VFS) pero no para otra implementación.

La solución fue reestructurar los módulos del proyecto de forma tal que el módulo central contenía el proyecto real pero sin aplicar el complemento de Spring Boot, mientras que varios módulos de paquete dependerían del módulo principal y configuraría los detalles del artefacto de implementación (Boot y otros complementos, dependencias específicas de implementación, etc. .).

De esta manera, la compilación del proyecto pudo generar artefactos de implementación múltiples (JAR ejecutable de Boot, WAR tradicional y WAR específico de WildFly) en una única ejecución de compilación.

En caso de que alguien lo encuentre útil, el proyecto de muestra para demostrar el enfoque está disponible en Github . El proyecto puede ser construido por Gradle o Maven.