2023.10.10 - [Knowledge/개발지식] - [개발지식] 빌드와 컴파일
[개발지식] 빌드와 컴파일
오늘 부트캠프에서 빌드와 컴파일에 대한 이야기가 나왔다. 느낌적으론 알 거 같은데 말로 표현하려니 어려워 따로 정리를 해보려고 한다. 빌드와 컴파일은 프로그래밍에서 중요한 단계이다. Ja
jh7722.tistory.com
이전글 중에 빌드와 컴파일에 대해 정리하였다. 이번엔 스프링에서 주로 사용하는 2개의 빌드관리툴인 Maven과 Gradle를 정리해 보자.
빌드 관리 도구
두 개념을 설명하기 전 일단 빌드 관리 도구가 무엇인지부터 알 필요가 있다.
소스코드를 컴파일, 테스트, 패키징 등의 빌드 프로세스를 자동화하고 관리를 해주는 도구를 의미한다. 이 도구를 사용하면 개발 프로젝트에서 반복적인 빌드 작업을 간소화하고 표준화할 수 있으며, 팀원 간의 일관성 있는 작업환경을 유지할 수 있다.
대표적인 주요 기능은 다음과 같다.
- 컴파일: 소스 코드를 실행 가능한 바이너리나 바이트 코드로 변환
- 의존성 관리: 라이브러리와 프레임워크의 종속성을 자동으로 다운로드하고 관리
- 테스팅: 단위 테스트나 통합 테스트를 자동으로 실행
- 패키징: 컴파일된 코드와 다른 리소스들을 하나의 패키지로 묶는다.
- 배포: 생성된 패키지를 서버나 저장소에 업로드
Java에서 대표적인 빌드 관리도구는 'Maven', 'Gradle'이 있고 최근에는 CI/CD(지속적 통합 및 지속적 배포) 환경과 밀접하게 연관되어 있다.
Maven
자바의 대표적인 관리 도구였던 Ant를 대체하기 위해 개발되었다. (최근에는 Ant환경을 사용하는 프로젝트를 경험하기는 어렵다.)
프로젝트의 외부 라이브러리를 쉽게 참조할 수 있게 'pom.xml' 파일로 명시하여 관리한다. 참조한 라이브러리에 연관된 다른 라이브러리까지 자동으로 관리된다.
Maven을 사용하는 이유
기존에 사용하던 Ant는 빌드의 기능만 가지고 있다. 그렇기 때문에 자동으로 라이브러리를 관리줄 필요성을 느꼈고 그것을 위해 나온 것이 Maven이다.
Maven을 사용하는 주요 이유는 다음과 같다.
- 의존성 관리: Maven의 중심적인 기능 중 하나는 자동 의존성 관리이다. pom.xml 파일에 필요한 라이브러리와 그 버전을 명시하면, Maven이 이를 자동으로 다운로드하고 프로젝트에 포함시켜 준다. 또한 의존성의 의존성인 참조 라이브러리까지 자동으로 관리된다.
- 프로젝트의 표준화: Maven은 프로젝트의 디렉터리 구조, 라이브러리 관리 방법, 빌드 및 배포 프로세스를 표준화한다. 이로 인해 다양한 프로젝트 간에 일관성이 유지되며, 개발자가 새로운 프로젝트에 참여할 때 러닝 커브를 줄일 수 있다.
- 생명주기 관리: Maven은 프로젝트의 빌드 생명주기를 정의하고 관리한다. 예를 들면, 컴파일, 테스트 실행, 패키징, 설치, 배포 등의 단계를 표준화하고 자동화한다.
- 통합 빌드와 CI/CD: Maven은 지속적 통합(Jenkins, Travis CI 등) 도구와의 통합이 용이하여 지속적 통합 및 지속적 배포(CI/CD) 프로세스를 자동화하기 위한 핵심 컴포넌트로 사용될 수 있다.
Maven의 생명주기
Maven의 기능은 생명주기 순서에 따라 관리되고 동작한다. 메이븐의 생명주기는 크게 기존 생명주기(Defalut LifeCycle), 클린 생명주기(Clean Lifecyle), 사이트 생명주기(Site LifeCycle)의 3가지로 구분된다.
각 생명주기는 위 그림과 같이 존재하며, 특정 단계를 수행하기 위해선 이전 단계를 마쳐야 한다.
즉, 각 단계는 메이븐이 제공하는 플러그인이 설정된 목표(goal)를 수행하는 방식으로 동작하며 순차적으로 실행된다.
생명주기 단계의 역할은 다음과 같다.
클린 생명주기
- clean : 이전 빌드가 생성된 모든 파일을 제거한다.
기본 생명주기
- validate : 프로젝트를 빌드하는 데 필요한 모든 정보를 사용할 수 있는지 검토한다.
- compile : 프로젝트의 소스코드를 컴파일한다.
- test : 단위 테스트 프레임워크를 사용해 테스트를 실행한다.
- package : 컴파일한 코드를 가져와서 JAR 등의 형식으로 패키징을 수행한다.
- verify : 패키지가 유효하여 일정 기준을 충족하는지 확인한다.
- install : 프로젝트를 사용하는 데 필요한 패키지를 로컬 저장소에 설치한다.
- deploy : 프로젝트를 통합 또는 릴리스 환경에서 다른 곳에 공유하기 위해 원격 저장소에 패키지를 복사한다.
사이트 생명주기
- site : 메이븐의 설정 파일 정보를 기반으로 프로젝트의 문서 사이트를 생성한다.
- site-deploy : 생성된 사이트 문서를 웹 서버에 배포한다.
생명주기를 실제로 다양한 기능을 제공한다. 내가 스프링 기반 프로젝트를 진행할 때는 배포 파일을 생성하기 위한 Jar 나 War 파일을 만들기 위해 Clean 하고 Package 하는 정도로 밖에 사용 안 해봤는데 실제로 프로젝트 내 어떤 방식으로 사용되는지 알아볼 필요가 있을 것 같다.
pom.xml의 자주 사용 되는 태그
- modelVersion : maven의 버전을 의미
- groupId : 프로젝트 그룹 id를 뜻하며, 일반적으론 대표하는 사이트 도메인을 역순으로 적어서 사용한다.
- artifactId : groupId 외에 다른 프로젝트와는 구분될 수 있는 프로젝트 id를 작성한다. (실질적인 프로젝트를 구분할 수 있는 아이덴티티로 활용된다.)
- version : 프로젝트의 버전을 의미하며 개발 단계에 따라 구분하여 작성한다.
- name : 프로젝트의 이름
- description : 해당 프로젝트의 간략한 설명을 작성
- properties : pom.xml 파일 내에서 빈번하게 사용되는 중복 상수를 정의하는 영역, 해당 영역의 상수를 사용하기 위해서는 ${태그명}의 형태로 사용된다.
- dependendies : 해당 프로젝트에서 의존성을 가지고 사용하는 라이브러리를 정의하는 영역, 각 라이브러리마다 <dependency> 태그를 사용하여 구분한다.
- build : 프로젝트 빌드와 관련된 정보를 설정하는 영역이다.
해당 설명은 태그의 개념적인 요소이며 실제 설정코드로 사용하면 아래 코드와 같이 사용된다.
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<!-- 프로젝트 그룹 ID -->
<groupId>com.example</groupId>
<!-- 프로젝트 ID -->
<artifactId>my-sample-project</artifactId>
<!-- 프로젝트 버전 -->
<version>1.0-SNAPSHOT</version>
<!-- 프로젝트 이름 -->
<name>Sample Project</name>
<!-- 프로젝트 설명 -->
<description>A sample project for demonstrating pom.xml</description>
<!-- 중복 상수 정의 영역 -->
<properties>
<java.version>11</java.version>
</properties>
<!-- 의존성 라이브러리 정의 영역 -->
<dependencies>
<!-- 예시 라이브러리 의존성 -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
<version>2.5.0</version>
</dependency>
</dependencies>
<!-- 프로젝트 빌드 설정 영역 -->
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.1</version>
<configuration>
<source>${java.version}</source>
<target>${java.version}</target>
</configuration>
</plugin>
</plugins>
</build>
</project>위 예제 또한 간단히 작성되어있고 실제로 사용할 때는 추가적인 설정이 필요할 수 있다. 회사에서 보면 어느 정도 연차가 있는 개발자분들은 본인만에 pom.xml이 있거나 세팅팀이 있는 경우도 있어 내가 설정을 직접 만질 필요가 없었다. 현재는 퇴사 후 개인 프로젝트를 많이 진행하고 있어 나만의 pom.xml를 만드는 것도 좋은 공부가 될 것 같다.
Maven의 한계?
Maven의 한계가 있어 Gradle이 나온 것은 다 알고 있는 사실이다. 그럼 Maven의 한계는 무엇일까?
- XML 기반의 구성: Maven은 pom.xml을 사용하여 프로젝트를 구성합니다. XML은 명료하고 구조화된 포맷을 제공하지만, 복잡한 빌드 논리나 커스터마이징을 위한 스크립트 작성이 번거롭고 불편할 수 있다.
그리고 기본적으로 태그 형태로 작성되고 위상에 대한 정렬도 해줘야 하기 때문에 프로젝트 규모가 커질수록 간결한 구성의 어려움이 있다. - 비교적 느린 빌드 시간: Maven은 효과적인 증분 빌드를 제공하지 않기 때문에, 작은 변경사항에도 전체 빌드를 다시 수행해야 할 수 있다.
- 빌드 라이프 사이클의 제한성: Maven은 기본적으로 정의된 라이프 사이클을 가지고 있다. 이를 커스터마이징 하기 위해서는 Maven의 플러그인 시스템을 사용해야 하며, 때로는 매우 복잡한 작업이 될 수 있다.
Gradle
Gradle은 Groovy 스크립트를 활용한 빌드 관리 도구이다. 안드로이드 프로젝트의 표준 빌드 시스템으로 채택되어 있으며 멀티 프로젝트의 빌드에 최적화하여 설계되었다.
Maven에 비해 더 빠른 처리속도를 가지고 있으면 (최대 100배) 더 간결한 구성이 가능하다.
Gradle과 Maven의 차이점 비교
1. 기반언어
- Maven : XML을 기반하여 프로젝트 구조와 의존성을 정의한다. XML를 선언적으고 명확하지만, 때론 XML 구조가 복잡해질 수 있다.
- Gradle : Groovy 스크립트를 기반하여 프로젝트 구조와 의존성 정의한다. XML과 다르게 코드를 이용해 접근할 수 있어 더 동적이고 간결하게 빌드 프로세스를 정의할 수 있다.
- 코드 기반 구성은 XML보다 더 많은 유연성을 제공한다.
2. 성능
- Maven : 빌드 캐싱을 지원하지 않아 (일부 플러그인을 통해 유사하게 활성화 가능) 전체 생명주기를 실행해야 할 때가 있어 종종 느릴 수 있다.
- Gradle : Gradle 4.x 버전 이후 빌드 캐싱을 지원해 이미 빌드된 작업에 결과를 저장하고 재사용하여 빌드 시간을 줄여준다.
- 둘 다 병렬 빌드를 지원하지만 Gradle이 동시에 빌드하는 것 만큼 Maven에서 효과적으로 지원하지 않는다.
- 이론적으로 10배에서 최대 100배까지도 속도차이가 발생된다고 한다.
3. 사용성
- Maven : 구조가 간단하며, 대부분 Java 개발자들에게 익숙한 패턴이다. XML를 선언적 특성 때문에 초기에 접근하기가 상대적으로 쉽다.
- Gradle : 새로운 사용자에게는 조금 어려울 수 있다. 하지만 한번 익숙해지면 유연함과 성능 향상을 느낄 수 있다.
- 최근에는 Gradle 도 많이 사용되지 때문에 익숙함에 빈도는 거의 동일하다.
Gradle 대표 용어 설명
- plugins : 필요한 플러그인들을 추가
- group과 version : 프로젝트 기본 정보를 설정
- sourceCompatibility : 사용할려는 자바 버전 설정
- repositories : 라이브러리가 저장된 위치 등 설정
- mavenCentral : 기본 Maven Repository
- dependencies : 라이브러리 사용을 위한 의존성 설정
- test : 테스트를 위한 설정
plugins {
id 'org.springframework.boot' version '2.5.5'
id 'io.spring.dependency-management' version '1.0.11.RELEASE'
id 'java'
}
group = 'com.example'
version = '0.0.1-SNAPSHOT'
sourceCompatibility = '1.8'
repositories {
mavenCentral()
}
dependencies {
implementation 'org.springframework.boot:spring-boot-starter-web'
testImplementation 'org.springframework.boot:spring-boot-starter-test'
}
test {
useJUnitPlatform()
}
'Knowledge > 개발지식' 카테고리의 다른 글
| [네트워크] PDU(protocol data unit) (0) | 2024.05.16 |
|---|---|
| [개발지식] 라이브러리와 프레임워크 (0) | 2024.05.01 |
| [개발지식] 객체와 관계형 데이터베이스와의 차이 with JPA (0) | 2024.03.11 |
| [스진초 5기/개발지식] DDD 설계와 SQL 중심 설계 (1) | 2023.11.10 |
| [개발지식] 빌드와 컴파일 (0) | 2023.10.10 |
2023.10.10 - [Knowledge/개발지식] - [개발지식] 빌드와 컴파일
[개발지식] 빌드와 컴파일
오늘 부트캠프에서 빌드와 컴파일에 대한 이야기가 나왔다. 느낌적으론 알 거 같은데 말로 표현하려니 어려워 따로 정리를 해보려고 한다. 빌드와 컴파일은 프로그래밍에서 중요한 단계이다. Ja
jh7722.tistory.com
이전글 중에 빌드와 컴파일에 대해 정리하였다. 이번엔 스프링에서 주로 사용하는 2개의 빌드관리툴인 Maven과 Gradle를 정리해 보자.
빌드 관리 도구
두 개념을 설명하기 전 일단 빌드 관리 도구가 무엇인지부터 알 필요가 있다.
소스코드를 컴파일, 테스트, 패키징 등의 빌드 프로세스를 자동화하고 관리를 해주는 도구를 의미한다. 이 도구를 사용하면 개발 프로젝트에서 반복적인 빌드 작업을 간소화하고 표준화할 수 있으며, 팀원 간의 일관성 있는 작업환경을 유지할 수 있다.
대표적인 주요 기능은 다음과 같다.
- 컴파일: 소스 코드를 실행 가능한 바이너리나 바이트 코드로 변환
- 의존성 관리: 라이브러리와 프레임워크의 종속성을 자동으로 다운로드하고 관리
- 테스팅: 단위 테스트나 통합 테스트를 자동으로 실행
- 패키징: 컴파일된 코드와 다른 리소스들을 하나의 패키지로 묶는다.
- 배포: 생성된 패키지를 서버나 저장소에 업로드
Java에서 대표적인 빌드 관리도구는 'Maven', 'Gradle'이 있고 최근에는 CI/CD(지속적 통합 및 지속적 배포) 환경과 밀접하게 연관되어 있다.
Maven
자바의 대표적인 관리 도구였던 Ant를 대체하기 위해 개발되었다. (최근에는 Ant환경을 사용하는 프로젝트를 경험하기는 어렵다.)
프로젝트의 외부 라이브러리를 쉽게 참조할 수 있게 'pom.xml' 파일로 명시하여 관리한다. 참조한 라이브러리에 연관된 다른 라이브러리까지 자동으로 관리된다.
Maven을 사용하는 이유
기존에 사용하던 Ant는 빌드의 기능만 가지고 있다. 그렇기 때문에 자동으로 라이브러리를 관리줄 필요성을 느꼈고 그것을 위해 나온 것이 Maven이다.
Maven을 사용하는 주요 이유는 다음과 같다.
- 의존성 관리: Maven의 중심적인 기능 중 하나는 자동 의존성 관리이다. pom.xml 파일에 필요한 라이브러리와 그 버전을 명시하면, Maven이 이를 자동으로 다운로드하고 프로젝트에 포함시켜 준다. 또한 의존성의 의존성인 참조 라이브러리까지 자동으로 관리된다.
- 프로젝트의 표준화: Maven은 프로젝트의 디렉터리 구조, 라이브러리 관리 방법, 빌드 및 배포 프로세스를 표준화한다. 이로 인해 다양한 프로젝트 간에 일관성이 유지되며, 개발자가 새로운 프로젝트에 참여할 때 러닝 커브를 줄일 수 있다.
- 생명주기 관리: Maven은 프로젝트의 빌드 생명주기를 정의하고 관리한다. 예를 들면, 컴파일, 테스트 실행, 패키징, 설치, 배포 등의 단계를 표준화하고 자동화한다.
- 통합 빌드와 CI/CD: Maven은 지속적 통합(Jenkins, Travis CI 등) 도구와의 통합이 용이하여 지속적 통합 및 지속적 배포(CI/CD) 프로세스를 자동화하기 위한 핵심 컴포넌트로 사용될 수 있다.
Maven의 생명주기
Maven의 기능은 생명주기 순서에 따라 관리되고 동작한다. 메이븐의 생명주기는 크게 기존 생명주기(Defalut LifeCycle), 클린 생명주기(Clean Lifecyle), 사이트 생명주기(Site LifeCycle)의 3가지로 구분된다.
각 생명주기는 위 그림과 같이 존재하며, 특정 단계를 수행하기 위해선 이전 단계를 마쳐야 한다.
즉, 각 단계는 메이븐이 제공하는 플러그인이 설정된 목표(goal)를 수행하는 방식으로 동작하며 순차적으로 실행된다.
생명주기 단계의 역할은 다음과 같다.
클린 생명주기
- clean : 이전 빌드가 생성된 모든 파일을 제거한다.
기본 생명주기
- validate : 프로젝트를 빌드하는 데 필요한 모든 정보를 사용할 수 있는지 검토한다.
- compile : 프로젝트의 소스코드를 컴파일한다.
- test : 단위 테스트 프레임워크를 사용해 테스트를 실행한다.
- package : 컴파일한 코드를 가져와서 JAR 등의 형식으로 패키징을 수행한다.
- verify : 패키지가 유효하여 일정 기준을 충족하는지 확인한다.
- install : 프로젝트를 사용하는 데 필요한 패키지를 로컬 저장소에 설치한다.
- deploy : 프로젝트를 통합 또는 릴리스 환경에서 다른 곳에 공유하기 위해 원격 저장소에 패키지를 복사한다.
사이트 생명주기
- site : 메이븐의 설정 파일 정보를 기반으로 프로젝트의 문서 사이트를 생성한다.
- site-deploy : 생성된 사이트 문서를 웹 서버에 배포한다.
생명주기를 실제로 다양한 기능을 제공한다. 내가 스프링 기반 프로젝트를 진행할 때는 배포 파일을 생성하기 위한 Jar 나 War 파일을 만들기 위해 Clean 하고 Package 하는 정도로 밖에 사용 안 해봤는데 실제로 프로젝트 내 어떤 방식으로 사용되는지 알아볼 필요가 있을 것 같다.
pom.xml의 자주 사용 되는 태그
- modelVersion : maven의 버전을 의미
- groupId : 프로젝트 그룹 id를 뜻하며, 일반적으론 대표하는 사이트 도메인을 역순으로 적어서 사용한다.
- artifactId : groupId 외에 다른 프로젝트와는 구분될 수 있는 프로젝트 id를 작성한다. (실질적인 프로젝트를 구분할 수 있는 아이덴티티로 활용된다.)
- version : 프로젝트의 버전을 의미하며 개발 단계에 따라 구분하여 작성한다.
- name : 프로젝트의 이름
- description : 해당 프로젝트의 간략한 설명을 작성
- properties : pom.xml 파일 내에서 빈번하게 사용되는 중복 상수를 정의하는 영역, 해당 영역의 상수를 사용하기 위해서는 ${태그명}의 형태로 사용된다.
- dependendies : 해당 프로젝트에서 의존성을 가지고 사용하는 라이브러리를 정의하는 영역, 각 라이브러리마다 <dependency> 태그를 사용하여 구분한다.
- build : 프로젝트 빌드와 관련된 정보를 설정하는 영역이다.
해당 설명은 태그의 개념적인 요소이며 실제 설정코드로 사용하면 아래 코드와 같이 사용된다.
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<!-- 프로젝트 그룹 ID -->
<groupId>com.example</groupId>
<!-- 프로젝트 ID -->
<artifactId>my-sample-project</artifactId>
<!-- 프로젝트 버전 -->
<version>1.0-SNAPSHOT</version>
<!-- 프로젝트 이름 -->
<name>Sample Project</name>
<!-- 프로젝트 설명 -->
<description>A sample project for demonstrating pom.xml</description>
<!-- 중복 상수 정의 영역 -->
<properties>
<java.version>11</java.version>
</properties>
<!-- 의존성 라이브러리 정의 영역 -->
<dependencies>
<!-- 예시 라이브러리 의존성 -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
<version>2.5.0</version>
</dependency>
</dependencies>
<!-- 프로젝트 빌드 설정 영역 -->
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.1</version>
<configuration>
<source>${java.version}</source>
<target>${java.version}</target>
</configuration>
</plugin>
</plugins>
</build>
</project>위 예제 또한 간단히 작성되어있고 실제로 사용할 때는 추가적인 설정이 필요할 수 있다. 회사에서 보면 어느 정도 연차가 있는 개발자분들은 본인만에 pom.xml이 있거나 세팅팀이 있는 경우도 있어 내가 설정을 직접 만질 필요가 없었다. 현재는 퇴사 후 개인 프로젝트를 많이 진행하고 있어 나만의 pom.xml를 만드는 것도 좋은 공부가 될 것 같다.
Maven의 한계?
Maven의 한계가 있어 Gradle이 나온 것은 다 알고 있는 사실이다. 그럼 Maven의 한계는 무엇일까?
- XML 기반의 구성: Maven은 pom.xml을 사용하여 프로젝트를 구성합니다. XML은 명료하고 구조화된 포맷을 제공하지만, 복잡한 빌드 논리나 커스터마이징을 위한 스크립트 작성이 번거롭고 불편할 수 있다.
그리고 기본적으로 태그 형태로 작성되고 위상에 대한 정렬도 해줘야 하기 때문에 프로젝트 규모가 커질수록 간결한 구성의 어려움이 있다. - 비교적 느린 빌드 시간: Maven은 효과적인 증분 빌드를 제공하지 않기 때문에, 작은 변경사항에도 전체 빌드를 다시 수행해야 할 수 있다.
- 빌드 라이프 사이클의 제한성: Maven은 기본적으로 정의된 라이프 사이클을 가지고 있다. 이를 커스터마이징 하기 위해서는 Maven의 플러그인 시스템을 사용해야 하며, 때로는 매우 복잡한 작업이 될 수 있다.
Gradle
Gradle은 Groovy 스크립트를 활용한 빌드 관리 도구이다. 안드로이드 프로젝트의 표준 빌드 시스템으로 채택되어 있으며 멀티 프로젝트의 빌드에 최적화하여 설계되었다.
Maven에 비해 더 빠른 처리속도를 가지고 있으면 (최대 100배) 더 간결한 구성이 가능하다.
Gradle과 Maven의 차이점 비교
1. 기반언어
- Maven : XML을 기반하여 프로젝트 구조와 의존성을 정의한다. XML를 선언적으고 명확하지만, 때론 XML 구조가 복잡해질 수 있다.
- Gradle : Groovy 스크립트를 기반하여 프로젝트 구조와 의존성 정의한다. XML과 다르게 코드를 이용해 접근할 수 있어 더 동적이고 간결하게 빌드 프로세스를 정의할 수 있다.
- 코드 기반 구성은 XML보다 더 많은 유연성을 제공한다.
2. 성능
- Maven : 빌드 캐싱을 지원하지 않아 (일부 플러그인을 통해 유사하게 활성화 가능) 전체 생명주기를 실행해야 할 때가 있어 종종 느릴 수 있다.
- Gradle : Gradle 4.x 버전 이후 빌드 캐싱을 지원해 이미 빌드된 작업에 결과를 저장하고 재사용하여 빌드 시간을 줄여준다.
- 둘 다 병렬 빌드를 지원하지만 Gradle이 동시에 빌드하는 것 만큼 Maven에서 효과적으로 지원하지 않는다.
- 이론적으로 10배에서 최대 100배까지도 속도차이가 발생된다고 한다.
3. 사용성
- Maven : 구조가 간단하며, 대부분 Java 개발자들에게 익숙한 패턴이다. XML를 선언적 특성 때문에 초기에 접근하기가 상대적으로 쉽다.
- Gradle : 새로운 사용자에게는 조금 어려울 수 있다. 하지만 한번 익숙해지면 유연함과 성능 향상을 느낄 수 있다.
- 최근에는 Gradle 도 많이 사용되지 때문에 익숙함에 빈도는 거의 동일하다.
Gradle 대표 용어 설명
- plugins : 필요한 플러그인들을 추가
- group과 version : 프로젝트 기본 정보를 설정
- sourceCompatibility : 사용할려는 자바 버전 설정
- repositories : 라이브러리가 저장된 위치 등 설정
- mavenCentral : 기본 Maven Repository
- dependencies : 라이브러리 사용을 위한 의존성 설정
- test : 테스트를 위한 설정
plugins {
id 'org.springframework.boot' version '2.5.5'
id 'io.spring.dependency-management' version '1.0.11.RELEASE'
id 'java'
}
group = 'com.example'
version = '0.0.1-SNAPSHOT'
sourceCompatibility = '1.8'
repositories {
mavenCentral()
}
dependencies {
implementation 'org.springframework.boot:spring-boot-starter-web'
testImplementation 'org.springframework.boot:spring-boot-starter-test'
}
test {
useJUnitPlatform()
}
'Knowledge > 개발지식' 카테고리의 다른 글
| [네트워크] PDU(protocol data unit) (0) | 2024.05.16 |
|---|---|
| [개발지식] 라이브러리와 프레임워크 (0) | 2024.05.01 |
| [개발지식] 객체와 관계형 데이터베이스와의 차이 with JPA (0) | 2024.03.11 |
| [스진초 5기/개발지식] DDD 설계와 SQL 중심 설계 (1) | 2023.11.10 |
| [개발지식] 빌드와 컴파일 (0) | 2023.10.10 |
