빌드툴이란 무엇인가? (feat. Gradle)

그래들, 메이븐과 같은 빌드툴이 나오게 된 이유는 무엇일까?
빌드툴에 대한 역사를 찍먹해보고 그래들의 장점을 알아보도록 하자아.

빌드툴이란 무엇인가?

자바 애플리케이션 개발과정을 살펴보면, 반복된 작업들이 있다는 것을 볼 수 있다.
이런 반복된 작업들 (정형화된 작업)을 자동화하기 위한 소프트웨어를 빌드툴 이라 한다.

1. 소스코드(.java)를 컴파일하여 클래스 파일(.class) 파일 생성
2. 코딩 규약에 맞게 작성했는지 확인
3. 코드를 정적으로 해석
4. 테스트를 하고 테스트 결과나 커버리지 측정 결과를 리포트로 출력
5. Javadoc과 같은 문서를 작성
6. 클래스 파일과 리소스 파일을 패키징하여 압축파일을 만듬(.jar 혹은 .war)
7. 압축 파일을 테스트 혹은 스테이징 환경에 배포
8. 압축 파일을 저장소에 등록

으잉? 이클립스/intellij 에서는 Run만 눌러도 잘 실행이 되었는데?
-> IDE에서의 빌드를 전제로 한 프로젝트가 생성되기 때문. 즉, 해당 IDE에서만 빌드가 가능하다는 얘기가 된다.

만약 빌드툴을 사용하지 않으면 어떤 문제가 발생할까?

빌드 툴을 사용한다면?

빌드툴에는 어떤 것들이 있을까?

Make

• Makefile 이라는 통일된 구조로 빌드를 처리 가능
• 소프트웨어 개발 세계에 빌드 개념을 처음 가져온 것이 바로 메이크
• C언어 빌드 툴

Ant

• 자바의 등장.. 메이크를 자바에 적용하기 위해서는 여러 문제가 발생 -> ANT의 탄생(Java + XML)
• 장점 : 간단하고 사용하기 쉬움
• 단점
  • 복잡한 처리를 하려면 빌드 스크립트가 장황해져 관리하기 어려움
  • 라이브러리 의존관계를 관리하는 구조가 존재하지 않음

Maven

• Ant의 문제를 해결하고자 등장. Ant에 빌드 생명 주기(lifecycle)개념을 추가함
• 장점 : 의존관계를 자동으로 관리해줌(메이븐 저장소)
• 단점
  • 기능이 많다 보니 이해해야 할 암묵적인 규칙이 많아짐
  • 기본 규칙을 벗어난 처리라도 하려면 사용이 어려워짐

Gradle

• 지금까지의 빌드 툴이 가진 장점은 활용하고 약점은 제거할 목적으로 만들어진 빌드 툴

1. 메이크 : 빌드 개념 확립
2. 앤트 : 범용성을 높임 ( = 크로스 플랫폼 대응)
3. 메이븐 : 빌드 스크립트 작성 효율을 높임 ( = 규칙 기반) - 규칙을 따라 프로젝트 구조(디렉터리 구조)를 만듬
4. 그레이들 : 유연성을 높임 ( = 스크립트 언어로 회귀)

첫 회사에서 ant로 빌드스크립트를 작성하였는데, 보기만해도 어떤 작업을 수행하는지 한눈에 들어와서 좋았던 기억이..

비교해보자.

Ant (임시로 짜봄)

<?xml version="1.0"?>
<project name="antProject" default="main" basedir=".">

    <description>sampleProject build</description>

    <property name="src.dir" value="./controller"/>
    <property name="lib.dir" value="./lib"/>
    <property name="classes.dir" value="./target/classes"/>

    <path id="classpath">
        <fileset dir="${lib.dir}" includes="**/*.jar"/>
    </path>

    <!-- clean -->
    <target name="clean">
        <delete dir="${classes.dir}"/>
    </target>

    <!-- compile -->
    <target name="compile">
        <mkdir dir="${classes.dir}"/>
        <javac srcdir="${src.dir}" destdir="${classes.dir}" debug="true" encoding="utf-8" classpathref="classpath"
               includeantruntime="false"/>
    </target>

    <!-- jar packaging -->
    <target name="jar" depends="compile">
        <mkdir dir="${jar.dir}"/>
        <jar destfile="${jar.dir}/Main.jar" basedir="${src.dir}"/>
    </target>

    <!-- testCompile -->
    ...
    <!-- test -->
    ...
    <!-- Copy Properties -->
    <target name="copy_prop">
        <copy todir="${classes.dir}" overwrite="true">
            <fileset dir="${src.dir}">
                <include name="**/*.properties"/>
            </fileset>
        </copy>
        <copy todir="${classes.dir}" overwrite="true">
            <fileset dir="${src.dir}">
                <include name="**/*.xml"/>
            </fileset>
        </copy>
    </target>

    <!-- deploy -->

    <target name="main" depends="clean, compile, copy_prop"/>
</project>

$ ant clean
$ ant build
$ ant jar
...

• 직관적이고 배우기 싶다.
• 디렉토리 구조에 관련도니 표준 규칙이 없고 프로젝트 단위로 다른 빌드 스크립트를 사용해야 하므로 재사용이 어렵다.
• 라이브러리 의존관계 관리 기능이 없어 라이브러리를 직접 받아야 한다.

Maven

<?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>

    <groupId>org.example</groupId>
    <artifactId>maven-project</artifactId>
    <version>1.0-SNAPSHOT</version>

    <properties>
        <maven.compiler.source>8</maven.compiler.source>
        <maven.compiler.target>8</maven.compiler.target>
    </properties>

    <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.11</version>
            <scope>test</scope>
        </dependency>
    </dependencies>

</project>

$ mvn clean
$ mvn compile
$ mvn install

• 앤트와 비교했을 때 빌드 스크립트가 확연히 간략해진 것을 알 수 있다.
• 디렉터리 구조와 빌드 순서(lifecycle) 가 표준화되어 있다.
• 표준 규칙을 따르면 빌드 내용을 상세하게 지시하지 않아도 빌드가 된다. 스크립트를 간략하게 하고 프로젝트의 재사용성을 높이는데 크게 공헌
• 제대로 사용하려면 복잡한 메이븐 규칙을 이해해야 하므로 초보자가 진입하기에 학습 장벽이 높다.
• 규칙에 맞지 않는 프로젝트에 사용 난이도가 높아진다. (적용이 불가하게 될지도...)

Gradle의 장점은 무엇일까?

그레들은 메이븐처럼 규칙 기반 빌드 및 의존관계 관리 기능을 제공하면서도 메이븐보다 유연하게 기능을 변경하거나 확장할 수 있는 빌드 툴
https://gradle.org/maven-vs-gradle/

빌드 스크립트 생산성이 높다.

• 빌드 스크립트 내용을 크게 줄일 수 있음.
  • 그레들은 메이븐과 마찬가지로 규칙 기반 빌드 접근법을 사용 (즉, 규칙을 따라 프로젝트 구조를 만들면 빌드 스크립트 내용을 크게 줄일 수 있다.)
• 그레들은 JVM언어인 그루비로 구축되어 있어 그루비의 장점을 그대로 활용할 수 있음빌드 순서를 제어하기 쉽다.

빌드 순서를 제어하기 쉽다.

• 그래들의 빌드 순서는 태스크(빌드 순서의 각 단계) 의존 관계에 따라 정해진다.(메이븐 처럼 빌드 순서가 정해져 있지 않다.)
• 사용자가 빌드 스크립트에 태스크 의존관계를 정의하면 이에 따라 빌드 순서가 정해진다.

멀티 프로젝트에 쉽게 대응한다.

컴포넌트로 만들기 쉽다.

별도로 설치할 필요가 없다.

• 그레들 래퍼(wrapper)라는 구조를 제공
  • 지정한 버전의 그레들을 자동으로 설치해주는 기능

ci(jenkins)에서 별도로 gradle을 설치할 필요가 없이 gradle wrapper를 사용하여 빌드가 가능하다.
이 말은 각 개발자의 PC에서도 gradle을 설치할 필요가 없다는 말이 된다.
만약 Maven이었다면 각기 다른 버전이 개발자 PC에 깔려있을지도 모른다. 누구는 빌드가 안되는 현상이 일어날지도...?

./gradlw build

Gradle 프로젝트 관련

Directory 구조

ㄴ gradle/wrapper/gradle-wrapper.properties - gradle wrapper 설정정보 파일
ㄴ gradle/wrapper/gradle-warpper.jar - gradlew, gradlew.bar 파일에서 사용
ㄴ gradlew : 리눅스 또는 맥 OS용 실행 쉘 스크립트
ㄴ gradlew.bat : 윈도우용 실행 배치 스크립트
ㄴ build.gradle : 라이브러리 의존성, 플러그인, 저장소 등을 설정하는 빌드 스크립트 파일
ㄴ settings.gradle : 프로젝트의 구성 정보 파일. (프로젝트 모듈화할 경우 사용)

build.gradle

plugins {
    id 'java'
}

group 'org.example'
version '1.0-SNAPSHOT'

repositories {
    mavenCentral()
}

dependencies {
    testImplementation 'org.junit.jupiter:junit-jupiter-api:5.7.0'
    testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine:5.7.0'
}

test {
    useJUnitPlatform()
}

plugin : 프로젝트를 빌드하기 위해 필요한 작업들을 지원하는 플러그인 설정
repositories : 필요한 라이브러리를 다운로드하기 위한 저장소 설정
depedencies : 저장소에서 필요한 라이브러리를 사용하기 위한 문장

java plugin의 task dependency

출처)

• Gradle 철저 입문 (https://search.shopping.naver.com/book/catalog/32503869922?cat_id=50010920&frm=PBOKPRO&query=gradle+%EC%B2%A0%EC%A0%80%EC%9E%85%EB%AC%B8&NaPm=ct%3Dl6ozs614%7Cci%3Db662970ac7026428f202c2827600b6411106e054%7Ctr%3Dboknx%7Csn%3D95694%7Chk%3D42055346d3719636dd81ea551826dae34cd1a80a)