티스토리 뷰
[Gradle UserGuide 도전기] 6. Build Script Basics
6.1. Projects and tasks
Gradle의 모든 것은 projects와 tasks라는 2개의 최상위 개념에 놓여 있다.
모든 Gradle build는 1개 이상의 projects로 구성되어 있다. project가 표현 할 내용은은 당신이 gradle을 이용해서 무엇을 하느냐에 달려있다. 예를 들어 project는 library JAR 혹은 web application일 수 있다.
각각의 project는 1개 이상의 tasks로 구성되어 있다. task는 어떤 수행 하려는 build의 atomic piece를 의미한다. 이걸로 클래스를 컴파일하거나 JAR을 만들거나 javadoc을 생성하거나 저장소에 어떤 archives를 퍼블리싱 할 수 있다.
이제 한 프로젝트 안에 있는 어떤 간단한 테스크의 정의를 살펴보자.
Every Gradle build is made up of one or more projects. What a project represents depends on what it is that you
are doing with Gradle. For example, a project might represent a library JAR or a web application. It might
represent a distribution ZIP assembled from the JARs produced by other projects. A project does not necessarily
represent a thing to be built. It might represent a thing to be done, such as deploying your application to staging
or production environments. Don't worry if this seems a little vague for now. Gradle's build-by-convention
support adds a more concrete definition for what a project is.
Each project is made up of one or more tasks. A task represents some atomic piece of work which a build
performs. This might be compiling some classes, creating a JAR, generating Javadoc, or publishing some
archives to a repository.
For now, we will look at defining some simple tasks in a build with one project. Later chapters will look at
working with multiple projects and more about working with projects and tasks.
6.2. Hello world
Gradle을 실행하고 싶으면 gradle 커맨드를 입력하면 된다. 커맨드를 입력하면 gradle은 build.gradle을 현재 디렉토리에서 찾는다. 우리는 build.gradle 파일을 build script(엄격하게는 build configuration script)라고 부른다. 이 build script에서 task와 project를 정의한다.
이제 build.gradle을 만들어 보자.
gradletest라는 폴더에서 gradle이 실행되서 .gradle 폴더가 이미 만들어져있다.
어차피 build.gradle로 다시 gradle할거니 지워도 된다.
다음은 build.gradle을 만든 폴더에서 gradle -q hello로 커맨드를 시작해보자.
gradle -q hello : gradle을 할건데 로그 메시지 생략을 위해 -q하고 hello 테스크를 하고 싶으니 뒤에 붙인다.
위의 과정은 빌드 스크립트에 hello라는 하나의 테스크를 정의하고 테스크가 해야 할 행동을 추가한 것이다. 또한 gradle -q hello 명령으로 제대로 수행이 되는지 확인하였다.
만약 이게 Ant의 target과 비슷하게 보였다면, 제대로 본 것이다. gradle의 task는 ant의 target과 동등한 개념이며 task가 앞으로도 보겠지만 더욱 powerful하다.
굳이 이름을 target이 아님 task라고 한 이유는 task가 더 의미를 잘 전달한다고 생각하기 때문이다. 다만 ant에도 task라는 용어가 있어 혼동스러울 수 있는데 앞으로 ant의 task를 언급할때는 항상 ant task라고 할 것이다.
6.3. A shortcut task definition
위의 build script를 더 짧게 만들 수도 있다.
실행결과는 동일하다.
6.4. Build scripts are code
Gradle은 groovy를 사용하여 build script를 작성하므로 프로그래밍을 하듯이 스크립트를 작성 할 수 있다.
toUpperCase() 메소드는 그루비에 내장된 메소드 인듯
여러개의 task를 작성해도 gradle upper, gradle count로 따로 실행 가능
6.5. Task dependencies
이제 task에 의존성을 더해보자. 여기서 의존성이란 하나의 task의 실행에 다른 task가 필요한 경우를 말한다.
dependsOn : 다른task 를 활용해서 intro를 실행하기 위해서는 hello가 선행되어야 한다고 명시
intro만 실행시켜도 hello가 실행되어짐.
의존관계를 선언 할 때는 순서를 지키지 않아도 괜찮다. 사용할 테스크가 아직 선언 안되었어도 사용이 가능하다. 이는 매우 중요한 부분으로 15.4 Adding dependencies to a task에서 자세히 살펴 볼 것이다.
taskY가 정의되기 전에 위에서 먼저 taskY를 사용해서 의존관계를 선언했다.
이때 dependsOn: taskY가 아닌 dependsOn: 'taskY'로 선언해야 한다. 혹은 ""로 묶어야 한다.
안 그러면 못 찾는다고 나온다... 웃긴건 순서가 제대로면 안 묶어도 된다. -_-;
아직 선언되지 않은 태스크를 이용할 때는 꼭 dependOn: 뒤에 '' 혹은 ""로 묶어서 정의하자.
제대로 실행된다.
6.6. Dynamic tasks
groovy는 task 정의를 좀 더 강력하게 할 수 있는데, 예를 들어 다음과 같이 dynamically하게 task를 생성할 수 있음.
4.times{counter-> 이 의미는 4번을 반복하고 각 증감자를 counter로 하겠다는것
0~3까지 task가 생성됨
6.7. Manipulation existing tasks
일단 테스크가 한번 만들어지면 API를 통해서 접근을 하게 된다.
위에서 작업한 스크립트에 dependsOn API로 의존성 부여
또는 기존의 테스크에 추가도 가능함
doFirst : 테스크 액션 중 가장 처음에 추가
doLast : 테스크 액션 중 가장 마지막에 추가
<< : doLast를 뜻 함
6.8. Shortcut notations
전 예제에서 알 수 있듯이 각 태스크는 빌드 스크립트의 property로 적용 할 수 있다. 이미 했던 부분이므로 실행은 하지 않고 가이드 내용만 보이고 넘어가자.
6.9. Extra task properties
테스크에 당신만의 properties를 넣을 수 있다.
ext.속성 = "값" 형태로 입력
주의 할 점은 <<을 쓰지 않고 바로 속성 값을 설정하여야 한다.
<<을 쓰면 doLast{} 내부에서 선언이 되버리는데 이 경우 에러가 난다.
6.10. Using Ant Tasks
Gradle은 Ant tasks들과의 통합을 쉽게 할 수 있도록 지원한다. Groovy는 AntBuilder를 포함한다. Gradle에서 Ant tasks의 사용은 build.xml을 통한 Ant tasks의 사용보다 더욱 편리함과 강력함을 제공한다. 다음 예제에서 당신은 어떻게 Ant tasks를 실행하고 Ant properties에 접근하는지 배울 것이다.
주의 할 점은 Ant tasks는 Ant의 명령어를 지칭하는 것. Gradle의 tasks와는 다른 개념. 즉 여기서는 Ant의 loadfile 커맨드를 사용하는 방법을 배우는 것.
우선 loadfile할 파일들을 간단히 만들어 놓음
현재 폴더에서 test_loadfile폴더를 찾은 후 안에 있는 파일을 가져옴
6.11. Using methods
method를 사용해서 build logic을 짤 수 있다. 6.10에서 했던 loadfile 테스크를 다음과 같이 재정의하고 fileList라는 method를 만들어서 다른 task에서도 사용하도록 한다. 이는 앞으로 multi-project builds에 유용하게 사용 될 것이다.
(생각해보니 문법 셋팅을 안해서 groovy로 셋팅하였다. 이쁘다 ^^)
6.10에서 보았듯이 파일을 불러오고 검사하고 정렬하는데 이를 fileList로 빼서 정의한다.
6.12. Default tasks
Gradle은 default task를 지원하는데 이는 별다른 요청을 하지 않아도 기본적으로 실행되는 task를 말한다. default task는 1개 또는 그 이상 선언 할 수 있다.
defaultTasks '태스크', '태스크' 형태로 지정 할 수 있다.
아무 테스크를 실행 안해도 defaultTasks로 지정된 테스크는 실행된다.
6.13. Configure by DAG
DAG란 Directed Acyclic Graph를 의미. 즉 gradle은 tasks를 관리할 때 DAG를 이용해서 그 순서를 찾아낸다. 자세한 내용은 챕터 56. The Build Lifecycle에서 나오겠지만, Gradle은 configuration phase와 execution phase로 나뉘는데 configuration phase에서 DAG를 구성하고 설정한다. 때문에 다음 예제에서는 task가 실행되기 전에 먼저 version의 값이 정해진다.
그래프가 준비를 마치면 release 테스크가 포함 되있는지 아닌지로 version값 지정
6.14. Where to next?
이번 챕터에서는 task에 관해서 알아보았다. 하지만 아직 task에 대해 다 배운 것이 아니다. 만약 바로 task에 관한 내용을 보고 싶다면 챕터 15. More about tasks를 참조하라.
'Dev Story > Gradle' 카테고리의 다른 글
[Gradle 도전기] 8. Dependency Management Basics (2) | 2015.01.02 |
---|---|
[Gradle 도전기] 7. Java Quickstart (0) | 2014.12.26 |
[Gradle 도전기] 5. Troubleshooting (0) | 2014.12.25 |
[Gradle 도전기] 4. Installing Gradle (0) | 2014.12.25 |
[Gradle 도전기] 3. Tutorials (0) | 2014.12.25 |