JavaRush /Java Blog /Random-KO /Gradle에 대한 빠른 소개
Viacheslav
레벨 3

Gradle에 대한 빠른 소개

Random-KO 그룹에 게시되었습니다

소개

이번 리뷰의 주제는 Gradle 자동 빌드 시스템입니다. 영어로 빌드 시스템을 Build Tools 라고 합니다 . Gradle에 대한 빠른 소개 - 1이것이 왜 필요한가요? Java로 프로젝트를 수동으로 구축하는 것은 다소 노동 집약적인 프로세스입니다. 프로젝트에 필요하고 프로젝트가 의존하는 라이브러리와 프레임워크를 올바르게 표시하는 것이 필요합니다. 여기에서 Habré에 대한 훌륭한 기사인 " 명령줄에서 Java 작업 " 을 읽을 수 있습니다 . 조만간 이 프로세스를 자동화하기 위한 몇 가지 스크립트를 만들기 시작할 것입니다. 이제 전 세계의 모든 개발자가 이 작업을 수행하고 누군가가 자신의 프로젝트를 위해 이미 작성한 내용을 모두가 다시 작성한다고 상상해 보십시오. 그리고 이 프로세스를 자동화하는 프로젝트 조립 시스템이 등장했습니다. 또한, 원하는 방식으로 프로젝트를 조합할 수 있게 해 주는 반면, 다소 표준화된 도구를 제공합니다. Gradle의 대안은 Maven 자동화 빌드 시스템입니다. 이 두 가지 조립 시스템은 한편으로는 다르지만 다른 한편으로는 많은 유사점을 가지고 있습니다. Gradle 웹사이트에는 " Maven에서 Gradle로 마이그레이션 " 이라는 주제에 대한 자료가 있습니다 . 이 튜토리얼에서 설명한 것처럼 Gradle과 Maven은 프로젝트를 빌드하는 방법에 대해 서로 다른 관점을 가지고 있습니다. Gradle은 서로 의존할 수 있는 작업 그래프를 기반으로 합니다. 작업은 일종의 작업을 수행합니다. Maven은 특정 "목표"가 첨부된 특정 단계의 모델을 사용합니다. 이러한 목표는 일부 작업이 수행되는 곳입니다. 그러나 이러한 서로 다른 접근 방식을 사용하면 두 빌드 시스템 모두 동일한 규칙을 따르며 종속성 관리도 유사합니다. Gradle을 사용하려면 Gradle을 다운로드해야 합니다. Google 또는 Yandex에서 "Gradle Build Tool"을 입력하면 첫 번째 결과에 공식 웹사이트인 https://gradle.org 가 표시됩니다 . 기본 Gradle 페이지에는 Gradle 문서 로 연결되는 "Docs"라는 텍스트가 있는 링크가 있습니다 . 먼저 Gradle을 설치(Install)해야 하므로 문서의 " Gradle 설치 " 섹션에 관심이 있습니다. "구식" 방법을 포함하여 많은 설치 방법이 있습니다. 수동으로(“ 수동으로 설치 ”). 지침에 따라 gradle-5.1.1-bin.zip과 같은 이름을 갖는 " 바이너리 전용 " 유형의 파일을 다운로드합니다. 다음으로, 아카이브의 압축을 풀고 지침에 따라 PATH 환경 변수를 구성합니다. 가장 중요한 점은 지침을 실행한 후 명령이 gradle -v설치된 Gradle의 버전을 표시한다는 것입니다. 위치를 결정할 때 시스템이 원하는 위치가 아닌 Gradle을 찾는 문제가 있을 수 있습니다. 따라서 Windows에서는 다음을 수행할 수 있습니다(*nix에는 유사 항목이 있음). for %i in (gradle.bat) do @echo. %~$PATH:i 이제 익숙해지기 시작할 수 있습니다.
Gradle에 대한 빠른 소개 - 2

Gradle 프로젝트 초기화

저는 Gradle이 작업 이라는 작업을 수행하는 것에 관한 것임을 즉시 언급하고 싶습니다 (나는 이를 작업이라고 부르겠습니다). 작업은 다양한 플러그인 에 의해 제공됩니다 . 공식 문서 " Gradle 플러그인 사용 " 에서 플러그인에 대한 자세한 내용을 읽어 보시기 바랍니다 . Gradle을 설치할 때 항상 사용할 수 있는 "핵심 플러그인" 세트가 있습니다. 이러한 플러그인에는 다양한 카테고리가 있지만 우리는 " 유틸리티 " 카테고리에 관심이 있습니다. 이 세트에는 Gradle 프로젝트 초기화 작업을 제공하는 " Build Init Plugin " 플러그인이 포함되어 있습니다. 우리는 프로젝트 유형 " java-application "을 생성하는 데 관심이 있습니다. Gradle 작업을 실행해 보겠습니다. gradle init --type java-application 예를 들어 Groovy DSL(Gradle용 표준 작업 설명 언어) 및 JUnit 테스트 프레임워크를 사용하고 싶다는 질문에 답해 보겠습니다(이에 대해서는 다른 리뷰에서 설명하겠습니다). 생성 후에는 다음과 같은 파일 세트를 받게 됩니다:
Gradle에 대한 빠른 소개 - 3
첫째, 초기화 후 Gradle 버전에 맞게 사전 구성된 특수 래퍼를 받습니다. 이는 특수 스크립트입니다. 이에 대한 자세한 내용은 공식 문서인 " The Gradle Wrapper " 를 읽어보시기 바랍니다 . 둘째, Gradle 빌드 스크립트인 build.gradle 파일을 볼 수 있습니다. 이것은 프로젝트에서 사용하는 라이브러리와 프레임워크, 프로젝트에 연결해야 하는 플러그인, 다양한 작업을 설명하는 기본 파일입니다. 공식 문서인 " Build Script Basics " 에서 이 파일에 대한 자세한 내용을 읽어보시기 바랍니다 .
Gradle에 대한 빠른 소개 - 4

플러그인 및 작업

이제 빌드 스크립트의 내용을 살펴보면 플러그인 섹션이 표시됩니다.
plugins {
    id 'java'
    id 'application'
}
이는 앞서 이야기한 것과 동일한 플러그인입니다. 그리고 플러그인이 있다면 이제 우리가 사용할 수 있는 작업이 있습니다. Gradle 작업 명령을 실행하고 이제 프로젝트에서 무엇을 할 수 있는지 확인할 수 있습니다.
Gradle에 대한 빠른 소개 - 5
예를 들어, 실행하면 gradle runJava 애플리케이션의 기본 클래스가 시작됩니다.
Gradle에 대한 빠른 소개 - 6
보시다시피 아래에도 같은 내용이 적혀 있는데 2 actionable tasks: 1 executed, 1 up-to-date 이게 무슨 뜻인가요? 이는 총 2개의 작업이 완료되었음을 의미합니다. 게다가 1개는 실제로 완료되었고, 1개는 실행되지 않았습니다. 왜냐하면... 즉, 상태가 현재이고 아무 작업도 수행되지 않았습니다. 소위 "Dry Run"을 실행할 수 있습니다. gradle run -m 이 명령을 실행해 보겠습니다. 실행 작업을 실행하기 위해 어떤 작업이 실행될지 살펴보겠습니다.
Gradle에 대한 빠른 소개 - 7
보시다시피 총 4개의 작업이 완료되었습니다. 실행이 실행되기 전에 종속성 작업 클래스가 실행되었습니다. 클래스 자체에는 2개의 종속성이 있으므로 compileJava 및 processResources도 실행했습니다. 작업을 수행할 때 특정 수준의 로그를 보면서 작업을 수행할 수 있습니다(로깅 수준에 따라 보고 싶은 메시지의 중요성이 결정됨). 예를 들어, 우리는 할 수 있습니다 gradle run -i. 다음과 같은 정보 메시지도 표시됩니다.
Task :classes UP-TO-DATE
Skipping task ':classes' as it has no actions.
Gradle 로그인에 대한 자세한 내용은 공식 문서 " Gradle Logging " 을 참조하는 것이 좋습니다 . 보시다시피, 클래스 작업은 UP-TO-DATE 이므로 건너뛰었습니다 . 즉, 상태가 현재이고 아무것도 수행할 필요가 없으므로 작업이 없습니다. 이는 기본적으로 Gradle에는 " 최신 확인 " 또는 소위 증분 빌드가 있기 때문입니다. Gradle 문서 " 최신 확인(AKA 증분 빌드) "에서 이 메커니즘에 대한 자세한 내용을 읽을 수 있습니다. 그러나 --rerun-tasks 플래그를 지정하는 작업을 실행하면 이 메커니즘을 비활성화할 수 있습니다. 예를 들어, gradle run --rerun-tasks. 실행 가능한 작업 2개: 실행된 작업 2개 보시다시피 실행된 작업 수는 그래프의 첫 번째 수준, 즉 실행 작업 자체와 직접적으로 의존하는 작업만 고려합니다. , 클래스. 클래스가 의존하는 작업은 여기에서 계산되지 않습니다(클래스 작업이 실행될 때 실행되지만). 또한 다음 작업에 대해서도 읽어야 합니다.
Gradle에 대한 빠른 소개 - 8

종속성

모든 빌드 시스템의 주요 작업 중 하나는 종속성, 즉 프로젝트에 필요한 라이브러리/프레임워크를 관리하는 것입니다. 빌드 시스템은 적시에 사용할 수 있는지 확인하고 애플리케이션의 최종 결과물을 올바른 방식으로 어셈블해야 합니다. 기본적으로 java-application에 대한 gradle init 후에 빌드 스크립트에 다음 내용이 표시됩니다.
dependencies {
    implementation 'com.google.guava:guava:26.0-jre'
    testImplementation 'junit:junit:4.12'
}
여기서 우리가 무엇을 연결하고 있는지 즉시 알 수 있습니다. 그러나 약간의 이해 없이는 구현과 테스트 구현이 무엇인지 명확하지 않습니까? Gradle의 문서는 잘 작성되어 있으므로 여기서 다시 Gradle 문서로 돌아가야 합니다. 이를 " 종속성 구성 관리 "라고 합니다. 문서에 명시된 대로 각 종속성은 특정 범위, 즉 이 종속성을 사용할 수 있는 영역으로 선언됩니다. 이 범위는 일부 구성에 의해 지정되며 각 구성에는 고유한 이름이 있습니다. 많은 Gradle 플러그인이 사전 정의된 구성을 추가한다는 점도 흥미롭습니다. 어떤 구성이 있는지 확인하기 위해 다음을 실행할 수 있습니다. gradle --console plain dependencies 이 방법으로 사용 가능한 모든 구성과 해당 종속성 목록이 표시됩니다. 사용 가능한 구성만 볼 수 있도록 이 목록을 필터링할 수 있습니다. gradle --console plain dependencies | find " - " 무엇을 사용해야 할지 어떻게 알 수 있나요? 여기서는 조금 읽어야 합니다. 왜냐하면 우리는 "Java" 플러그인을 사용하므로 해당 문서와 " 종속성 관리 " 섹션 부터 시작하겠습니다 . 여기서는 "컴파일"이라는 구성(일명 범위)이 있었고 이는 "컴파일 중에 필요한 종속성"을 의미했음을 알 수 있습니다. 그러나 구현으로 대체되었습니다(영어로 대체됨). " API 및 구현 분리 " 섹션에서 대체에 대한 자세한 내용을 읽을 수 있습니다 . 이 종속성은 "컴파일 클래스 경로"에 있는 것으로 나타났습니다. 그러나 때때로 우리는 의존성이 최종 결과물에 포함되기를 원합니다. 무엇을 위해? 예를 들어, 필요한 모든 것을 자체적으로 포함해야 하는 실행 가능한 jar가 있을 것입니다. 그러면 우리는 어떻게 해야 합니까? 첫째, "기본적으로"(즉, 기본적으로 추가 작업 없이) 이러한 지원이 없습니다. 이는 모든 사람이 자신의 방식으로 아카이브를 수집하기를 원하고 Gradle은 최소화하려고 노력한다는 사실로 설명됩니다. 또한 (코드에서 추가 조작 없이) 클래스 경로에서 jar 아카이브를 사용할 수 없습니다. 그런 식으로 작동하지 않습니다( 자세한 내용은 " Oracle: JAR 파일의 클래스 경로에 클래스 추가 " 참조). 따라서 가장 아름다운 방법은 빌드 스크립트에서 다음 코드를 사용하는 것입니다.
jar {
    manifest {
        attributes 'Main-Class': 'jrgradle.App'
    }
    from configurations.compileClasspath.collect { it.isDirectory() ? it : zipTree(it) }
}
jar 작업 설정에서 jar 파일 매니페스트에 추가할 항목을 지정합니다(" Oracle: 애플리케이션의 진입점 설정 " 참조). 그런 다음 컴파일에 필요한 모든 종속성이 jar에 포함될 것이라고 말합니다. 대안은 " Gradle Shadow Plugin "을 사용하는 것입니다. 복잡해 보일 수도 있지만 다른 플러그인을 사용하면 삶이 더 편해집니다. 예를 들어, 웹 애플리케이션을 생성할 때(일반적으로 실행되는 Java 애플리케이션과 반대) 특별한 플러그인인 " Gradle War Plugin " 을 사용합니다. 이 플러그인 은 동작이 다르며 그곳에서 우리의 삶이 더 쉬워질 것입니다(필요한 모든 종속성은 플러그인 자체에 의해 별도의 특수 디렉토리에 배치됩니다. 이러한 작업은 웹 애플리케이션 설계 방법에 따라 규제됩니다. 그러나 이는 완전히 다른 이야기입니다.
Gradle에 대한 빠른 소개 - 9

결과

Gradle은 프로젝트 빌드 시스템을 위한 탁월한 선택입니다. 이는 Spring 및 Hibernate와 같은 잘 알려진 프로젝트의 개발자가 사용한다는 사실로 확인됩니다. 위에서는 가장 기본적인 사항들만 다루었습니다. 그 뒤에는 개발자에게 나타나는 백만 가지 기능과 기회가 숨겨져 있습니다. Gradle은 또한 이 리뷰에서 다루지 않은 다중 모듈 프로젝트 생성을 지원하지만 Gradle 자체에는 " 다중 프로젝트 빌드 생성 "이라는 훌륭한 튜토리얼이 있습니다. 이 리뷰를 통해 Gradle의 문서가 5+에서 작성되었으며 어디를 봐야 할지 이해하면 필요한 것을 쉽게 찾을 수 있다는 점을 보여주길 바랍니다. 그리고 이것은 기본을 이해하면 올 것입니다. 또한 Gradle에는 훌륭한 튜토리얼이 있습니다. Gradle을 사용하여 볼 수 있는 다른 항목에 대한 간단한 목록으로 마무리하고 싶습니다.
Gradle에 대한 빠른 소개 - 10
#비아체슬라프
코멘트
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION