다잇소


[IT/트랜드] [금융IT] Build 도구 Ant, Maven, 그리고 Gradle이란 무엇인가?

2016.09.28
박보경IT

 

Unix에 make, 오랫동안 개발자들에게 사랑 받아왔던, build 도구로써, 많은 단점에도 불구하고, 그 위치를 굳건히 해 왔습니다. Java가 널리 보급 되면서, 사람들은 새로운 Build 도구에서 make의 단점을 보완한 새로운 것을 원했습니다. 그러던 중, Ant라는 build 도구가 소개되고 빠른 속도로 보급되었습니다. 그렇지만, Ant도 만족스럽지 않은 build도구이다 보니, 새롭게 Maven이 소개되었습니다. Ant도 지지 않고, 부족한 단점을 보완하면서 Maven과 어깨를 나란히 했습니다. 그렇지만, 서로 약점을 가지고 있는 이 두 개의 build 도구의 장점을 취한 Gradle 새롭게 소개 되면서, 많은 프로젝트에서 보급되고 있습니다. 이러한 build 도구의 사용하면서, 우리는 장단점이 무엇이 정확히 알지 못 했습니다. 이제 이 도구들이 장단점이 무엇인지 알아 보도록 하겠습니다.

 

원문보기

https://technologyconversations.com/2014/06/18/build-tools/

 

읽기전에

Convention : 사용자 정의하지 않고, 미리 만들어진 작성 규약이라고 보면됩니다.

DSL : 특정영역에서 만들어진 간단한 언어라고 보시면 됩니다. 대표적인 것이 HTML, AWK같이 특정한 영역에서 사용됩니다.

 

 

Ant with Ivy


도구

Ant was the first among “modern” build tools. In many aspects it is similar to Make. It was released in 2000 and in a short period of time became the most popular build tool for Java projects. It has very low learning curve thus allowing anyone to start using it without any special preparation. It is based on procedural programming idea.

Ant 첫번째 현대적인 build 도구입니다. 많은 면에서 Make와 유사합니다. 2000년에 공개 되었고, 짧은 기간 동안에 가장 인기있는 Java 프로젝트용 build 도구가 되었습니다. 배우는 데 많은 노력이 들지 않아서 누구든지 특별한 준비 없이 사용을 할 수 있습니다. 절차적인 프로그램 개념을 기반으로 합니다.

 

After its initial release, it was improved with the ability to accept plug-ins.

초기 공개 이후에, plug-in을 추가할 수 있도록 개선되었습니다.

 

Major drawback was XML as the format to write build scripts. XML, being hierarchical in nature, is not a good fit for procedural programming approach Ant uses. Another problem with Ant is that its XML tends to become unmanageably big when used with all but very small projects.

주요 단점은 build script를 만드는 XML이었습니다. 태생적으로 수직계층적인 XML은 Ant가 사용하는 절차적인 프로그램 개념에는 적절하지 않았습니다. 또 다른 문제는 XML은 작은 프로젝트에 제외하면 다룰 수 없을 정도로 비대 해 졌습니다.

 

Later on, as dependency management over the network became a must, Ant adopted Apache Ivy.

나중에 Ant는 Apache Ivy를 네트워크상의 의존성 관리 위해 채택하였습니다.

 

Main benefit of Ant is its control of the build process.

Ant의 주요 장점은 build절차 제어입니다.

 

 

Maven


도구2

Maven was released in 2004. Its goal was to improve upon some of the problems developers were facing when using Ant.

Maven은 2004년에 공개되었습니다. 목적은 개발들이 Ant를 사용할 때 직면한 일부 문제를 개선하는 것 입니다.

 

Maven continues using XML as the format to write build specification. However, structure is diametrically different. While Ant requires developers to write all the commands that lead to the successful execution of some task, Maven relies on conventions and provides the available targets (goals) that can be invoked. As the additional, and probably most important addition, Maven introduced the ability to download dependencies over the network (later on adopted by Ant through Ivy). That in itself revolutionized the way we deliver software.

Maven은 XML를 build spec을 작성하는 계속 사용하였습니다. Ant 개발자에게 일부 task의 성공적인 실행하도록 모든 명령을 작성하도록 요구하지만, Maven은 convention에 의존하고, 이용 가능한 target(호출될 수 있는)을 제공합니다. 추가된 것, 아마도, 가장 중요한 추가로써, Maven은 네트워크 상에 의존성 부분들은 내려 받을 수 있는 기능을 소개하였습니다. 그것은 그 자체로 우리가 software를 전송하는 방법을 크게 변화시켰습니다.

 

However, Maven has its own problems. Dependencies management does not handle well conflicts between different versions of the same library (something Ivy is much better at). XML as the build configuration format is strictly structured and highly standardized. Customization of targets (goals) is hard. Since Maven is focused mostly on dependency management, complex, customized build scripts are actually harder to write in Maven than in Ant.

하지만, Maven도 자체적으로 문제가 있습니다.  의존성 관리는 같은 library의 두 버전의 충돌을 잘 다루지 못 합니다. 환경 설정 구조으로써 XML은 엄격하게 구조화되고 고도로 표준화되었습니다. target의 개성화는 어렵습니다. Maven 대개 의존성관리에 초점을 두어서, 복잡하고 개성화된 script는 실제로 Ant보다 작성하기 어렵습니다.

 

Main benefit from Maven is its life-cycle. As long as the project is based on certain standards, with Maven one can pass through the whole life cycle with relative ease. This comes at a cost of flexibility.

 

Maven의 주요 장점은 life-cycle입니다. 프로젝트가 특정 표준에 맞추어 지기만 하면, 상대적으로 쉽게 전체 life-cycle 동안 프로젝트는 잘 진행 됩니다. 이것은 비용적으로 유연성에 갖게 합니다.

 

 

 

Gradle


도구3

Gradle combines good parts of both tools and builds on top of them with DSL and other improvements. It has Ant’s power and flexibility with Maven’s life-cycle and ease of use. The end result is a tool that was released in 2012 and gained a lot of attention in a short period of time. For example, Google adopted Gradle as the default build tool for the Android OS.

Gradle은 DSL과 다른 개선점들을 이용하여, 도구와 빌드의 좋은 점을 조합한 것 입니다. Gradle은 Ant의 강력함, Maven의 life-cycle 유연성 그리고 사용 편리성이 있습니다. 이 결과적인 도구는 2012년에 공개되었고, 짧은 기간에 많은 주목을 받았습니다. 예를 들면, Google은 Android OS의 기본 build 도구로 선택하였습니다.

 

Gradle does not use XML. Instead, it had its own DSL based on Groovy (one of JVM languages). As a result, Gradle build scripts tend to be much shorter and clearer than those written for Ant or Maven. The amount of boilerplate code is much smaller with Gradle since its DSL is designed to solve a specific problem: move software through its life cycle, from compilation through static analysis and testing until packaging and deployment.

Gradle은 XML을 사용하지 않습니다. 대신에, Gradle 자신의 Groovy를 토대로 한 DSL을 가지고 있습니다. 결과적으로, Gradle build script는 Ant나 Maven작성된 것 보다 훨씬 짧으면서 명확합니다. 반복적인 코드량은 Gradle에서 급격히 줄어듭니다. packing과 배치 전 과정인 컴파일부터 정적 분석(코드 inspection 같은)과 테스트까지 life-cycle동안 software를 이동시키는 것을 해결했기 때문입니다.

 

Gradle effort can be summed as “convention is good and so is flexibility”.

Gradle 결과는 “convention은 좋고, 게다가 유연하다”로 요약이 됩니다.

 

 

미래에는 Gradle가 널리 보급되겠지만, 간단한 프로젝트를 운용 시에는 상대적으로 적은 비용이 들어가는 Ant도 고려 해 볼만 하겠습니다. 프로젝트에 적절한 방법을 선택하시기 바랍니다.

 

 
설정된 프로필 사진이 없습니다.
| Wise리더
관심분야 IT,여행,맛집

카테고리 레이어 닫기