[Gradle 도전기] 7. Java Quickstart

[Gradle UserGuide 도전기] 7. Java Quickstart

---

  7.1 The Java plugin

---

  Gradle은 다양한 곳에 쓰일 수 있는 general-purpose한 build tool이지만 그러기 위해서는 그에 맞는 build script를 작성해야 한다.

  대부분의 자바 프로젝트는 기본적으로 비슷하다. java source file을 컴파일 하고, 몇가지 unit tests를 실행, 당신의 classes가 들어있는 JAR file이 생성. 이러한 구조로 구성된다. 만약 이런 과정을 모든 프로젝트에서 일일히 하지 않아도 된다면 정말 훌륭 할 것이다. 다행이도, 당신은 그렇게 할 필요가 없다. Gradle은 plugins을 사용해서 이러한 문제를 해결 할 수 있다. plugin은 gradle이 어떤 프로젝트를 어떤 방식으로 설정할지 나타내는 개념이다. 보통은 많은 곳에서 유용할만한 미리 설정된 테스크들을 추가하면서 설정을 하게 된다. Gradle에는 몇가지 plugin이 들어 있으며, 당신은 당신이 작성한 코드와 내재된 코드를 자유롭게 조합해서 사용할 수 있다. 그렇게 내재된 plugin 중 하나가 Java plugin이다. Java plugin은 compile, unit test 등의 task가 들어있다.

  Java plugin은 convention based이다. 이 말은 기존에 보편적인 방식에 근거하여 build 구조가 형성된다. 만약 당신이 당신만의 코드를 넣고 싶다면 스크립트를 작성해야겠지만 그렇지 않다면 java plugin의 사용만으로도 충분히 유용한 빌드를 할 수 있을 것이다.

  7.2 A basic Java project

---

  1) plugin을 사용하려면 apply plugin: '이름' 코드를 넣어주면된다. 우리는 java plugin을 사용하니 apply plugin: 'java'를 적어주자. 이렇게 plugin을 추가 함으로서 java에 관련된 task들이 프로젝트에 추가된다. 이러한 사실은 gradle task 명령을 통해 사용가능한 task를 확인해보면 잘 알수있다. ( gradle task : 스크립트를 읽고 현재 사용 가능한 테스크를 나열해준다. apply 유무에 따라 어떻게 달라지는지 확인해보자 )

  ※ gradle이 사용하는 기본적인 폴더 구조가 있는데 이는 다음과 같다.

    - ./src/main/java : production source code

    - ./src/test/java : test source code

    - ./src/main/resource : JAR file에 리소스로서 포함될 모든 파일이 있는 곳

    - ./src/test/resource : 이 폴더의 파일은 테스트를 하기 위한 classpath에 포함된다.

    - ./build : 모든 결과 파일이 저장된다.

    - ./build/libs : 인코딩 된 JAR file이 저장된다.

  2) Building the Project.

    1번 과정에서 자바 플러그인을 적용시켰지만 이걸로는 프로젝트 빌드에 필요한 몇 안되는 테스크만이 포함된다. 그 중 몇가지를 설명하면 다음과 같다

    - build :여기서 가장 많이 사용되는 태스크가 build이다. build는 프로젝트 전체를 빌드하는데 사용한다. 만약 gradle build 명령을 수행하면 gradle은 당신의 코드를 컴파일하고 테스트하고 main클래스와 리소스가 포함된 JAR file을 생성할 것이다.

    - clean : build 디렉토리를 지운다. 이는 모든 build되었던 파일을 지운다는 의미이다.

    - assemble : unit test를 제외하고 빌드한다.

    - check : 컴파일 후 테스트를 한다.

  3) External dependencies.

    보통 자바 프로젝트는 외부 JAR files에 대한 dependencies를 갖는다. 이를 프로젝트에 연결하기 위해서는, gradle에게 이들을 찾으라고 말해주어야 한다. gradle에서는 jar file과 같은 artifacts는 repository에 저장된다. repository는 프로젝트에 dependencies를 가져오기 위해서 사용 되거나 프로젝트의 artifacts를 퍼블리싱하기 위해 사용된다. 이번 예제에서는 public Maven repository를 사용 할 것이다. 이를 위해 다음을 입력한다.

 이제 여기에 몇몇 dependencies를 추가하자. 다음과 같이 입력하면 컴파일 시에는 클래스들이 commons-collections에 dependency를 갖고, 테스트 컴파일 시에는 테스트 클래스들이 junit에 dependency를 갖을 것이다.

  4) Customizing the project.

    자바 플러그인은 당신의 프로젝트에 몇가지 properties를 추가한다. 이들 properties들은 defalut value를 갖고 있지만, 프로젝트에 맞지 않으면 쉽게 변경할 수 있다. 다음 예제는 sourceCompatibility와 version을 변경하고 JAR manifest에 몇가지 attributes를 넣는 코드이다.

    Java Plugin을 통해 프로젝트에 추가된 태스크들도 전 챕터에서 배웠던 태스크 관리 방식을 사용 할 수 있다.(의존성을 추가 한다던가 액션을 추가한다던가 등등)

    다음 예제는 플러그인을 통해 추가된 test 태그에 systemProperties를 추가하는 코드이다.

 5) Publishing the JAR file

    보통 jar file은 어딘가로 퍼블리싱 되어진다. 이를 하기 위해서는 gradle에게 어디에 퍼블리싱 되는지를 알려줘야 한다. Gradle에서는 JAR files과 같은 artifacts들을 repositories에 퍼블리싱 할 수 있다. 다음 예제에서는 로컬 디렉토리에 바로 퍼블리싱 하였지만, 외부에 접속해서도 퍼블리싱 할 수 있고, 여러곳에 퍼블리싱 할 수도 있다. 

   이렇게 퍼블리싱 설정을 해주었으면 gradle uploadArchives 명령을 통해 퍼블리싱을 할수있다.

설정한대로 repos디렉토리가 생성되고 여기에 퍼블리싱 된다.

  6) Creating an Eclipse project

    Eclipse 특유의 descriptor file(.project와 같은)을 위해서는 또 다른 플러그인을 하나 추가해야 하는데 apply plugin: 'eclipse'가 바로 그것이다. 플러그인을 추가 한 후에는 gradle eclipse 명령을 통해 descriptor file을 생성 할 수 있다.

  7) Summary

    다음은 1~6번 과정까지 했던 최종 결과물이다.

7.3 Multi-project Java build

---

  1)Defining a multi-project build

  다중 프로젝트를 정의하기 위해서는 별도의 setting file이 필요하다. setting file은 소스 트리 상에서 가장 루트 디렉토리에 작성한다. 그리고 이 때 파일의 이름은 settings.gradle이라고 한다. 이 파일에서 우리는 include "서브프로젝트명", "서브프로젝트명" 의 형태로 다중프로젝트를 구성한다.

shared, api, services/webservice, services/shared 이렇게 4가지의 서브 프로젝트를 선언한다.

  userguide에서는 이렇게 바로 사용법만 남기고 넘어 갔는데 딱 이렇게 settings.gradle만 작성하고 gradle build를 하면 어떻게 될까? 이 경우 ./shared, ./api, ./services, ./services/webservice, ./services/shared 이렇게 5개의 폴더가 생성되고 각각에 build 폴더가 생성되었다.(물론 루트디렉토리도 build 폴더가 생성되었다.)  setting.gradle에는 4개의 하위 프로젝트만 적었지만 실제로는 중간 경로까지 프로젝트로 계산하는 것 같다. 여기서 조금 더 나가서 각각에 build.gradle을 작성해서 task를 작성했더니 build 중에 모두 인식하여 task가 추가 되었다.

build.gradle이 없어도 build 폴더가 생성 되었다.

  2) Common configuration

  대다수의 다중 프로젝트에는 모든 프로젝트가 똑같이 사용하는 설정이 있다. 이번 예제에서는 이러한 중복되는 설정을 루트 프로젝트에서 한번에 설정하는걸 배운다. 우린 이러한 기술을 configuration injection이라고 한다.

  루트 프로젝트에서 모든 하위 프로젝트에 configuration injection을 하는 방법은 subprojects라는 메소드를 이용하는 것이다. 이 메소드는 빌드 과정 중 모든 하위 프로젝트를 돌면서 configuration injection을 수행한다.

모든 프로젝트를 돌면서 build가 됨

하위 프로젝트의 manifest에 provider: gradle이 추가된걸 볼 수 있다.

주의 할 점은 subprojects에서만 수행이 된다는 점. 루트프로젝트에는 적용이 안되었다.

  3) Dependencies between projects

  당신은 한 빌드 내에서 프로젝트간의 dependencies를 추가 할 수 있다. 예를 들어 한 프로젝트의 JAR file이 다른 프로젝트의 컴파일에 사용되어 질 수 있습니다. api 빌드 파일에서 우리는 shared 프로젝트에 대한 dependency를 추가 해보겠습니다. 이 dependency로 인해서 gradle은 api보다 shared 프로젝트가 먼저 실행되야 한다는걸 알게 됩니다.

프로젝트의 경로는 맨 앞에 콜론(:)이 온다. 이는 최상위 프로젝트를 뜻한다.

만약 services에 있는 shared를 택하고 싶다면 :services:shared라고 지정한다.

api보다 shared가 먼저 컴파일 되는걸 볼 수 있다.

  4) Creating a distribution

    우리는 client에게 보내질 distribution을 추가 할 수 있다. 이 부분 잘 이해안감 나중에 다시 할 것.