1. 소개

이 예제에서는 mvn spring-boot : run 명령을 통해 Spring Boot 웹 애플리케이션을 시작하는 것과 java -jar 명령을 통해 jar / war 패키지로 컴파일 한 후 실행하는 것의 차이점을 살펴 봅니다.

여기서 Spring Boot 리 패키지 목표 의 구성에 이미 익숙하다고 가정 해 보겠습니다 . 이 주제에 대한 자세한 내용은 Create a Fat Jar App with Spring Boot를 참조하십시오 .

2. 스프링 부트 메이븐 플러그인

Spring Boot 애플리케이션을 작성할 때 Spring Boot Maven 플러그인 은 코드를 빌드, 테스트 및 패키징하는 데 권장되는 도구입니다.

이 플러그인은 다음과 같은 많은 편리한 기능과 함께 제공됩니다.

  • 우리를 위해 올바른 의존성 버전을 해결합니다.
  • 실행 가능한 단일 fat jar / war에 모든 의존성 (필요한 경우 임베디드 애플리케이션 서버 포함)을 패키지 할 수 있으며 다음 작업도 수행합니다.
    • 클래스 경로 구성을 관리하므로 java -jar 명령 에서 긴 -cp 옵션을 건너 뛸 수 있습니다.
    • 이제 패키지 내부에 중첩 된 모든 외부 jar 라이브러리를 찾아로드 하는 사용자 정의 ClassLoader 를 구현 합니다.
    • 자동으로 main () 메소드를 찾아 매니페스트에서 구성하므로 java -jar 명령 에서 기본 클래스를 지정할 필요가 없습니다.

3. Maven으로 분해 된 형태로 코드 실행

웹 애플리케이션을 작업 할 때 Spring Boot Maven 플러그인 의 또 다른 흥미로운 기능인 임베디드 애플리케이션 서버에 웹 애플리케이션을 자동으로 배포하는 기능을 활용할 수 있습니다 .

플러그인에 Tomcat을 사용하여 코드를 실행한다는 것을 알리려면 의존성이 하나만 필요합니다.

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId> 
</dependency>

이제 프로젝트 루트 폴더에서 mvn spring-boot : run 명령을 실행할 때 플러그인은 pom 구성을 읽고 웹 애플리케이션 컨테이너가 필요하다는 것을 이해합니다.

실행중인  실행 MVN 스프링 부팅을 명령 트리거를 아파치 톰캣의 다운로드와 톰캣의 시작을 초기화합니다.

해 보자:

$ mvn spring-boot:run
...
...
[INFO] --------------------< com.baeldung:spring-boot-ops >--------------------
[INFO] Building spring-boot-ops 0.0.1-SNAPSHOT
[INFO] --------------------------------[ war ]---------------------------------
[INFO]
[INFO] >>> spring-boot-maven-plugin:2.1.3.RELEASE:run (default-cli) > test-compile @ spring-boot-ops >>>
Downloading from central: https://repo.maven.apache.org/maven2/org/apache/tomcat/embed/tomcat-embed-core/9.0.16/tomcat-embed-core-9.0.16.pom
Downloaded from central: https://repo.maven.apache.org/maven2/org/apache/tomcat/embed/tomcat-embed-core/9.0.16/tomcat-embed-core-9.0.16.pom (1.8 kB at 2.8 kB/s)
...
...
[INFO] --- spring-boot-maven-plugin:2.1.3.RELEASE:run (default-cli) @ spring-boot-ops ---
...
...
11:33:36.648 [main] INFO  o.a.catalina.core.StandardService - Starting service [Tomcat]
11:33:36.649 [main] INFO  o.a.catalina.core.StandardEngine - Starting Servlet engine: [Apache Tomcat/9.0.16]
...
...
11:33:36.952 [main] INFO  o.a.c.c.C.[Tomcat].[localhost].[/] - Initializing Spring embedded WebApplicationContext
...
...
11:33:48.223 [main] INFO  o.a.coyote.http11.Http11NioProtocol - Starting ProtocolHandler ["http-nio-8080"]
11:33:48.289 [main] INFO  o.s.b.w.e.tomcat.TomcatWebServer - Tomcat started on port(s): 8080 (http) with context path ''
11:33:48.292 [main] INFO  org.baeldung.boot.Application - Started Application in 22.454 seconds (JVM running for 37.692)

로그에 'Started Application'이 포함 된 줄이 표시되면 http : // localhost : 8080 / 주소에서 브라우저를 통해 웹 애플리케이션을 쿼리 할 준비가 된 것입니다.

4. 독립 실행 형 패키지 애플리케이션으로 코드 실행

개발 단계를 통과하고 애플리케이션을 프로덕션 단계로 진행하려면 애플리케이션을 패키징해야합니다.

불행히도 jar 패키지 로 작업하는 경우 기본 Maven 패키지 목표에는 외부 의존성이 포함되지 않습니다.

이것은 우리가 더 큰 프로젝트에서 라이브러리로만 사용할 수 있음을 의미합니다.

이러한 제한을 피하려면 Maven Spring Boot 플러그인 리 패키지 목표를 활용하여 jar / war를 독립형 애플리케이션으로 실행해야합니다.

4.1. 구성

일반적으로 빌드 플러그인 만 구성하면됩니다.

<build>
    <plugins>
        ...
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
        </plugin>
        ...
    </plugins>
</build>

그러나 예제 프로젝트에는 둘 이상의 기본 클래스가 포함되어 있으므로 플러그인을 구성하여 실행할 클래스를 Java에 알려야합니다.

<plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
    <executions>
        <execution>
            <configuration>
                <mainClass>com.baeldung.webjar.WebjarsdemoApplication</mainClass>
            </configuration>
        </execution>
    </executions>
</plugin>

또는 start-class 속성 을 설정하여  :

<properties>
    <start-class>com.baeldung.webjar.WebjarsdemoApplication</start-class>
</properties>

4.2. 응용 프로그램 실행

이제 두 가지 간단한 명령으로 예제 전쟁을 실행할 수 있습니다.

$ mvn clean package spring-boot:repackage
$ java -jar target/spring-boot-ops.war

jar 파일을 실행하는 방법에 대한 자세한 내용은 Run JAR Application With Command Line Arguments 문서에서 찾을 수 있습니다 .

4.3. 전쟁 파일 내부

위에서 언급 한 명령이 전체 서버 애플리케이션을 실행하는 방법을 더 잘 이해하기 위해 spring-boot-ops.war을 살펴볼 수 있습니다.

압축을 풀고 내부를 들여다 보면 일반적인 용의자를 찾습니다.

  • META-INF , 자동 생성 된  MANIFEST.MF 포함
  • WEB-INF / classes , 컴파일 된 클래스 포함
  • WEB-INF / lib- 전쟁 의존성 및 임베디드 Tomcat jar 파일을 보유합니다.

팻 패키지 구성에 특정한 폴더가 있기 때문에 그게 전부는 아닙니다.

  •  WEB-INF / lib-provided , 임베디드 실행시 필요하지만 배포시 필요하지 않은 외부 라이브러리 포함
  • org / springframework / boot / loader- Spring Boot 커스텀 클래스 로더를 보유합니다.이 라이브러리는 외부 의존성을로드하고 런타임에서 액세스 할 수 있도록합니다.

4.4. 전쟁 매니페스트 내부

앞서 언급했듯이 Maven Spring Boot 플러그인은 기본 클래스를 찾고 java 명령 을 실행하는 데 필요한 구성을 생성합니다 .

결과 MANIFEST.MF 에는 몇 가지 추가 행이 있습니다.

Start-Class: com.baeldung.webjar.WebjarsdemoApplication
Main-Class: org.springframework.boot.loader.WarLauncher

특히 마지막 것은 사용할 Spring Boot 클래스 로더 런처를 지정하는 것을 볼 수 있습니다.

4.5. Jar 파일 내부

기본 패키징 전략으로 인해 전쟁 패키징 시나리오는 Spring Boot Maven Plugin 사용 여부에 관계없이 크게 다르지 않습니다.

플러그인의 장점을 더 잘 이해하기 위해 pom 패키징 구성을 jar로 변경하고 mvn clean package를 다시 실행할 수 있습니다.

이제 우리의 fat jar가 이전 war 파일과 약간 다르게 구성되어 있음을 확인할 수 있습니다.

  • 모든 클래스 및 리소스 폴더는 이제 BOOT-INF / classes 아래에 있습니다.
  • BOOT-INF / lib 는 모든 외부 라이브러리를 보유합니다.

플러그인이 없으면 lib 폴더는 존재하지 않으며 BOOT-INF / classes 의 모든 내용은 패키지의 루트에 있습니다.

4.6. Jar Manifest 내부

또한 매니페스트. MF는 다음과 같은 추가 라인을 특징으로 변경되었습니다.

Spring-Boot-Classes: BOOT-INF/classes/
Spring-Boot-Lib: BOOT-INF/lib/
Spring-Boot-Version: 2.1.3.RELEASE
Main-Class: org.springframework.boot.loader.JarLauncher

Spring-Boot-Classes 와 Spring-Boot-Lib 는 클래스 로더가 클래스와 외부 라이브러리를 찾을 위치를 알려주기 때문에 특히 흥미 롭습니다.

5. 선택 방법

도구를 분석 할 때 이러한 도구가 만들어진 목적을 고려하는 것이 중요합니다. 개발을 용이하게하고 싶습니까? 아니면 원활한 배포와 이동성을 보장하고 싶습니까? 이 선택의 영향을 가장 많이받는 단계를 살펴 보겠습니다.

5.1. 개발

개발자로서 우리는 종종 코드를 로컬에서 실행하기 위해 환경을 설정하는 데 많은 시간을 할애하지 않고 코딩에 대부분의 시간을 소비합니다. 간단한 응용 프로그램에서는 일반적으로 문제가되지 않습니다. 그러나 더 복잡한 프로젝트의 경우 환경 변수를 설정하고 서버를 시작하고 데이터베이스를 채워야 할 수 있습니다.

애플리케이션을 실행할 때마다 올바른 환경을 구성하는 것은 매우 비실용적입니다 . 특히 두 개 이상의 서비스를 동시에 실행 해야하는 경우 더욱 그렇습니다.

Maven으로 코드를 실행하면 도움이됩니다. 이미 전체 코드베이스를 로컬로 체크 아웃 했으므로 pom 구성 및 리소스 파일을 활용할 수 있습니다. 환경 변수를 설정하고, 메모리 내 데이터베이스를 생성하고, 올바른 서버 버전을 다운로드하고 하나의 명령으로 애플리케이션을 배포 할 수도 있습니다.

각 모듈에 다른 변수와 서버 버전이 필요한 다중 모듈 코드베이스에서도 Maven 프로필을 통해 적절한 환경을 쉽게 실행할 수 있습니다.

5.2. 생산

우리가 생산으로 더 많이 이동할수록 대화는 안정성과 Security으로 더 많이 이동합니다. 그렇기 때문에 개발 기계에 사용 된 프로세스를 실제 고객이있는 서버에 적용 할 수 없습니다.

이 단계에서 Maven을 통해 코드를 실행하는 것은 여러 가지 이유로 나쁜 습관입니다.

  • 먼저 Maven을 설치해야합니다.
  • 그런 다음 코드를 컴파일해야하기 때문에 전체 JDK (Java Development Kit)가 필요합니다.
  • 다음으로 코드베이스를 서버에 복사하고 모든 독점 코드를 일반 텍스트로 남겨 두어야합니다.
  • MVN 명령은 수명주기의 모든 단계를 실행해야한다 (찾기 소스, 컴파일 및 실행)
  • 이전 포인트 덕분에 우리는 CPU와 클라우드 서버의 경우 돈을 낭비했습니다.
  • Maven은 각각 메모리를 사용하는 여러 Java 프로세스를 생성합니다 (기본적으로 각 프로세스는 상위 프로세스와 동일한 메모리 양을 사용함).
  • 마지막으로 배포 할 서버가 여러 대인 경우 위의 모든 작업이 각 서버에서 반복됩니다.

이것은 응용 프로그램을 패키지로 배송하는 것이 생산에 더 실용적인 이유 입니다.

6. 결론

이 예제에서는 Maven과 java -jar 명령을 통해 코드를 실행하는 것의 차이점을 살펴 보았습니다 . 또한 몇 가지 실제 사례 시나리오에 대한 간략한 개요를 실행했습니다.

이 기사에 사용 된 소스 코드는 GitHub에서 사용할 수 있습니다 .