매우 긴 내용이 될 것이라서 성질 급한 사람들을 위해 요약한다.
- 난 이제 가능하면 Maven 안 쓴다. 되도록 항상 Gradle 혹은 이것보다 나은 툴이 나온다면 그것을 사용하리라.
- Gradle의 사용자 가이드를 번역해 두었다. Java 프로젝트를 진행하는데 필요한 거의 모든 내용을 번역하였고, 또한 내가 경험하며 검색등으로 찾은 문제 해결책들도 모두 정리해 두었다. Maven 공부할 시간에 Groovy + Gradle 공부하는게 더 생산적이라고 생각한다.
내가 생각하는 Maven의 가장 큰 문제점은 두가지이다.
- 프로젝트 구성/빌드 툴로써 프로젝트 구성은 정적인 설정 정보이고 빌드는 동적인 행위이다. 그런데 이것을 정적인 데이터를 저장하는데 적합한 XML로 그 내용을 기술하게 함으로써 동적인 행위인 빌드에 크나큰 제약을 가한다. 게다가 XML은 너무 장황해서 실제 설정 내용보다 XML 뼈대가 더 많다.
- 다른 하나는 Gradle을 사용하다 느낀 것인데, Maven은 설계상의 문제도 있다. 바로 멀티 프로젝트 구성을 상속 구조로 한 점이다. 그에 반해 Gradle은 구성 주입 방식(Configuration Injection, 설정 주입 방식이 더 나은 번역일까?)을 사용한다. 이는 빌드 구성 정보에서 매우 큰 차이를 만든다.
상속 구조는 공통 설정을 여러 프로젝트가 공유할 때 비어있는(Abstract) 프로젝트를 만들어서 거기에다 공통 설정을 넣고 그걸 상속하게 해야한다. 게다가 어느 플러그인의 설정이 조금만 달라도 해당 플러그인이 아주 유연하게 만들어져 있지 않은 이상 설정을 분리해서 프로젝트별로 중복 기술해야 한다. 즉, Maven을 사용하면 쓸데없이 설정이 길어지고 중복이 발생하며 가독성도 매우 떨어진다.
그에 반해 구성주입 방식은 그냥 어떤 프로젝트 구성 정보가 있으면 그것을 필요한 프로젝트에 주입하는 방식이다. 주입시 프로젝트의 조건을 체크할 수 있어서 프로젝트 별로 약간 다른 설정이 가능하다. 또한 공통 구성만 주입하고 프로젝트 별로 다른 점은 바로 그 점만 프로젝트 별로 주입시켜주면 된다.
이렇게 크게 두가지점 이 Gradle이 Maven보다 훨씬 뛰어난 점이며 그것만으로도 Gradle을 사용하는 것이 훨씬 더 편하다는 것을 알 수 있다.
그럼 내가 Maven에서 Gradle(현재 1.2)로 변환한 프로젝트는 어느 정도의 복잡도를 가지고 있었을까? 단순히 CLASSPATH 지정만으로 해결되는 아키텍처들은 제외하고 빌드 구성에 영향을 주는 복잡성들만 나열하면 다음과 같다.
- 15개 정도의 프로젝트가 서로간의 의존 관계를 맺고 있다.
- Spring 3.1이 뼈대를 이룬다.(이것 자체는 빌드에 영향을 안 줌)
- Apache CXF를 통해 SOAP Client Java 클래스 자동 생성하고 이를 각종 서비스에서 사용한다.
- JPA 2를 ORM으로 사용하며 이것의 StaticMetaModel Java Class들을 자동 생성해야 한다.(Annotation Processor)
- Lombok 을 사용하여 Getter/Setter/Slf4j/기타 등등의 코드를 자동 생성한다.(Annotation Processor)
- 웹 프로젝트들은 공통 리소스를 가지고 있으며 Eclipse에서는 LinkedResource로 지정되어 개발시 불필요한 공통 요소 복제 작업이 안 일어나도록 처리하고 있다.
- 웹 프로젝트에서 Javascript 파일을 빌드 툴에서 자동 최적화 해서 배포해 준다.
- Carbon Five Database Migration 툴로 데이터베이스 마이그레이션을 진행한다.
- Eclipse와 연동해야 한다. Eclipse 전용 플러그인이 있지는 않아도, 최소한 Gradle의 구성 상태를 Eclipse 설정으로 그대로 명령어 한 방으로 옮길 수 있어야 한다.
- 추가) Maven의 Profile 기능을 통해 개발/통합테스트/Staging/Production등을 구분하고 프로필에 따라 서로 다른 빌드 로직을 탄다.
실제 복잡도는 더 높다. 단지 빌드에 무관한 항목들이라 기입하지 않았을 뿐이다.
저 모든 것들이 두 가지만 빼고 Maven에서 보다 더 쉽게 Gradle에서 설정 가능하였다. Eclipse 연동도 성공적으로 이뤄 내었다.
이떻게 했는지는 Gralde 사용자 가이드 번역에 모두 기록해 두었다. 저 정도 복잡도가 된다면 웬만한 자바 프로젝트는 아무 문제 없이 구성 가능할 것이다.
문제를 일으킨 것은 두가지다.
첫째, provided 스코프가 없다. 이는 내가 보기엔 치명적인 문제이며 나를 가장 많이 괴롭힌 것이었다. 하지만 이슈로 등록 되어 있어서 곧 해결 될 것으로 보이며 물론 현재 버전에서도 해결책을 찾아 내었다. 더 큰 문제는 Eclipse 연동시에 Eclipse가 provided로 지정된 라이브러리를 웹서버 띄울 때 배포하는 것이었는데 그것도 모두 해결해서 기록해 두었다. from_maven 참조
둘째, Carbon Five Database Migration(C5) 툴은 기본적으로 Maven 플러그인이다. 독립 툴이 아니다. 이를 Gradle 플러그인으로 직접 옮겼는데, 너무 쉽게 되었다. C5 자체가 실제 기능 코드와 Maven 플러그인 코드가 잘 분리되어 있기 때문이다. 게다가 Gradle 플러그인 만들어 추가 하는 것은 Maven으로 플러그인 만들어서 프로젝트에 추가 하는 것과는 차원이 다르게 쉽다.
Gradle은 기본적으로 모든 Ant 태스크를 사용할 수 있다. C5가 Ant 연동을 제공했다면 정말 아무것도 아닌 일이었겠지만, 뭐 그 덕분에 Gradle 플러그인 만드는게 얼마나 쉬운지도 배우게 되었다.
또한 나는 차기 프로젝트에서는 Ant/Maven을 둘 다 지원하는 flyway를 사용할 예정이다.
결론은 이렇다.
사실 Gradle을 사용하면서 느낀 Maven의 문제점은 더욱 더 많다. from_maven 참조 해 보시길.
앞에서도 말했듯이 난 이제 피치못할 상황이 아니면 Maven 사용 안 할 예정이다. Gradle 혹은 최소한 이보다는 나은 프로젝트 구성/빌드 도구를 사용할 것이다.
아무리 간편한 툴이라도 그 기능이 요구사항에 못 미치고 버그가 많다면 그걸 사용하면 안된다. 하지만 나는 기존에 내가 참여하고 있는 프로젝트의 빌드 구성을 모두 Gradle로 완벽하게 포팅함으로써(설정파일 줄 수가 Maven 2800줄에서 Gradle 650줄로 줄었다) 기능도 부족함이 없음을 스스로 증명했다.
비록 Groovy와 Gradle을 모두 다 배워야 하는 부담이 있겠지만, 그게 장기적으로 더 개발자를 이롭게 할 것이다. 나 같은 경우 순전히 Gradle을 하고 싶어서 Groovy를 배웠는데, 그 뒤로 우리 프로젝트를 관리하는 부가 시스템과 셸 스크립트들을 Groovy로 다 바꿔 버렸다. 원본 프로젝트의 Java 코드를 직접 호출 할 수 있기 때문에 훨씬 더 편해졌다.
Maven에서는 아무리 Java를 알아도 빌드 구성을 하면서 너무 힘든 경우가 많았다. 하지만 Gradle을 나의 Groovy 지식이 일천함에도 훨씬 더 편안하고 즐겁게 일을 마칠 수 있었다.
빌드가 아니라 프로젝트 운영 코드를 짜는데 더 집중하고 싶은가?
그러면 Gradle을 사용하자.
덧글
배포하고 L4 스위치 제어하고 재기동하고등등은 사이트마다 워낙 다른지라 애시당초 maven을 쳐다보지도 않았었죠.
예전에는 ATN+Groovy Task를 썼는데 Gradle로 이전한후 참 편하게 쓰고 있지요.
하지만 저는 프로젝트 관리용 툴과 배포자동화 툴을 분리할 생각입니다. 그래서 프로젝트 관리/빌드는 Gradle로, 배포 자동화는 Gant를 생각중입니다(Capistrano 역할을 Gant에 맡겨볼려구요).
제가 굳이 그걸 나누는 이유는 "프로젝트구성/빌드"와 "배포"는 별개의 행위이며 "배포"에 해당하는 코드가 "빌드"에 해당하는 코드에 들어가서 섞이는 것을 싫어하기 때문입니다. 저희 같은 경우 하나의 프로젝트가 네 군데에 배포됩니다. 그리고 각각에 배포되는 스크립트도 살짝씩 다르죠. 그런 것들이 빌드 스크립트 소스에 말려 들어가는 것을 원치 않습니다.
사실 배포에 해당하는 코드도 프로젝트와는 무관한 별도의 배포전용 build.gradle로 만들수 있겠죠. 근데 배포에 필요한 기능보다 Gradle의 기능셋이 더 큽니다. 그래서 굳이 Gradle을 사용하지 않고 Gant를 사용하려고 합니다.
하지만 막상 해보고 마음이 어떻게 바뀔지는 모릅니다. 아직 안해봤거든요.
결국엔 그냥 Capistrano로 갈 수도 있겠죠. Gant냐 Gradle이냐 보다 더 중요한 것은 Linux 머신 상에서 SSH/SCP 등을 넘나들며 유연하게 배포할 수 있느냐니까요.
Maven은 리모드 넥서스에서 시간을 너무 소비해서 적용에서 제외했었지요. 아직 Ant에 머무르고 있는데,
Gradle은 꽤 매력적으로 보입니다.
덕분에 Gradle을 알게 되었습니다. 감사합니다.
Ant,Maven, Gradle 모두 거쳐서 사용해보았습니다. Gradle이 최고입니다.
gant,Capistrano는 그 대신 Python 언어로 만들어진 Fabric이라는 것도 괜찮아보입니다.
Fabric이 더 간편하다는 얘기가 많네요.
저도 개인적으로 메이븐에 한번 데인적 있어서 Ant 만 주로 쓰고 있었는데...
기회가 되면 저도 Gradle 꼭 사용해봐야겠네요 ^^
이제 막 웹개발로 입문한 개발자인데 아직은 저와 먼이야기같네요. 갈길이 멀기만하군요~
현업 안드로이드 개발자인데 앞으로 안드로이드 쪽 빌드 시스템이 그래들로 옮겨갈 예정이라고 하네요. 처음 Gradle 을 접하게 되었는데 큰 도움이 되었습니다 =)
xml 뼈대가 진짜 너무 비대해집니다.... 이제는 그래들을 배워야 할 때 인거같습니다 좋은자료 잘보겠습니다^^
음.. 소스가 아주 간결해지고 깔끔해지는건 너무 좋은데,
MAVEN 의 M2ECLIPSE플러그인의 편의성과 수많은 플러그인을 생각했을땐,
아직 GRADLE 로 넘어가기엔 조~금은 이른게 아닌가 하는 생각이 들었습니다..
오늘 처음 GRADLE을 살펴본 느낌인데, 어떻게 생각하시는지요??
전 그저 오늘 처음본 소감을 말씀드린거고, 권남님의 의견을 듣고 싶어서요~
좀 더 편하게 Gradle 설정을 반영하고자 한다면 http://wiki.kwonnam.pe.kr/gradle/eclipse#gradle_eclipse_%EC%89%BD%EA%B2%8C_%EC%8B%A4%ED%96%89%ED%95%98%EA%B8%B0 를 참조하시면 좋을것 같습니다.
둘째로 Maven의 다양한 플러그인은 사실 시간이 해결해줄 문제일텐데요. Gradle의 경우 Ant 태스크를 모두다 지원해 줌으로써 그 플러그인 부족을 거의 해소해주고 있습니다.
순수 Gradle 플러그인만 대상으로 한다면 일단 제가 사용하는 영역에 대해서는 Gradle의 플러그인이 부족하다고 느끼지 않아서 뭐라 드릴 말씀이 없네요. 그리고 Maven은 플러그인의 경직성 때문에 저는 오히려 너무 불편합니다. 플러그인 설정 좀 유연하게 하려고 하면 발목 잡히는게 더 많은데 Gradle은 플러그인 설정의 유연성도 매우 높은 편입니다. 사실은 플러그인 개발자들이 그렇게 만들었다기 보다는 Gradle 자체의 유연성이 자연스럽게 녹아들어간것이지만요.
위 글에서보 보셨다 싶이 Gradle 플러그인이 부족하면.. 그냥 제가 플러그인을 짭니다. 저는. 오히려 그게 더 빠르고 유연할 때가 많습니다.
저는 더이상 제가 시작하는 프로젝트에는 Maven을 사용하지 않습니다. 딱 하나 함께 개발에 참여하는 사람들이 처음에 반발하는 것이 M2Eclipse에서 pom.xml 자동 반영해주는 걸 못하는 것인데, 그것도 External Tools로 버튼 만들어 두면 나중엔 오히려 더 편해합니다.
글을 잘 읽었습니다.
하지만 Nexus + Maven에 대해서는 언급을 하지 않으셨던데 단지 Maven만 사용 할때와
Nexus + Maven을 사용할때는 다르다고 생각합니다.
인터넷이 안되는 환경에서는 gradle을 사용할 수 없나요??
개인적으로 gradle 프로젝트를 진행하고 싶은데 인터넷 환경이 지원되지 않거든요~
이 라이브러리들이 인터넷의 Maven Repository에 올라가있기 때문에 인터넷 연결이 필요합니다.
하지만 이 리포지토리를 모두 외부와는 연결이 안되더라도, 현재 망내로 들고 오게 되면 외부와의 네트웍연결없이도 가능합니다.
그리고, Gradle은 의존성 외에도 다양한 빌드관련 기능들이 있어서, 의존성을 모두 로컬 파일로 복사해둔 상태로 사용하는 것도 지원합니다. 이 때는 의존성 관리는 포기하고 Gradle의 빌드 스크립팅 관련 기능만 사용하게 되는 거겠죠. http://wiki.kwonnam.pe.kr/gradle/dependencies#%ED%8C%8C%EC%9D%BC_%EC%9D%98%EC%A1%B4%EC%84%B1 를 참조해보세요.
또한, --offline 참조 : http://www.gradle.org/docs/current/userguide/gradle_command_line.html
한가지 여쭤보고 싶은 부분이...
gradle project 를 eclipse tomcat-plugin 과 연동이 가능할까요?
gradle project 의 경우 tomcat-plugin 의 서버 환경에서 아예 add and remove 목록에 나타나질 않아서요.
아무래도 이클립스에서 tomcat log 를 볼수 있었던 점이 아쉽네요.
정독해야겠습니다. 좋은 글 올려주셔서 감사합니다.
저도 Gradle 공부해봐야겠네요 maven만 봤었거든요
안드로이드 스튜디오는 키보드 세팅할게 너무 많아서 짜증....나네요.
무엇보다, 우분투 13.10에서 한글 입력이 안됩니다. 즉시 포기..
이클립스에서 gradle을 의존성 매니저로 써볼려고 했는데 안 되길래 찾아보니 이클립스 Integration에서는 아직 의존성 매니저 기능이 지원되지 않는다더라구요.
aar형식 덕분에 고민이 많습니다... gradle을 쓰긴 해야되는데 한글이 안되면 답이 없어서..
Gradle은 Eclipse에서도 잘 작동합니다. 다만, Eclipse용 Gradle플러그인이 별로 안 좋은 관계로 gradle eclipse 명령을 사용하는 것이 좋습니다.
내용과는 상관없이 배경이 사선 이미지라 그런지 가독성이 엄청 떨어지고
눈이 피곤해지네요.
배경을 바꾸면 훨씬 좋을 것 같아 덧글 달고 갑니다.
정리해 놓으신 글 덕분에 좋은 정보 + 생각 얻어 갑니다.
이클립스가 자꾸 느려져서 성질나 안드스튜를 깔아봤더니 gradle인지 뭔지가 떡하니 중앙에..
눙물을 머금고 찾아보니 이런 사이트가 떡
감사합니당
이제 공부해보려고 하는데 영어가 약한 저한테 도움이 많이될 것 같네요.!!
현재 개발을 하면서 어떤 문제가 반복적인 노가다성 작업인지, 인간의 실수를 유발하는 작업인지를 잘 살피고 그 문제를 해결하기 위해 공부하고 해결책을 제시하는 것은 훌륭한 프로그래머입니다.
다른 사람들의 반복 적이고 인간이 하기에는 오류가 많은 것을 자동화해주는 "프로그래머"라는 직업에 종사하면서 자기 자신이 겪고 있는 문제조차 공부하기 싫어 외면한다는 것은 좋은 프로그래머가 아닙니다.
provided를 좋지않은 관례로 여기고 있습니다. 따라서 고쳐질 것 같지는 않아요...
필요하실 경우 spring에서 만든 prop-deps plugin을 사용하시면 됩니다.
일단 저도 그루비부터 시작해야겠습니다. :)
이제 바이바이 maven....
구글에 "Gradle" 이라고 검색해보니 바로 권남님 블로그가 나오는군요.
간단히 요약 정리해두신 글을 보고야 어느정도 감이 잡히는듯 합니다.
좋은 정보 감사합니다.
성공하시길~
maven을 라이브러리 가져오는 도구라고 인식하던 중 gradle을 사용해보려고 하는데 약간 개념이 다른 것 같아서요.. 라이브러리를 가져오는 도구라기 보기에는 프로젝트 자체가 gradle에 의존하느 느낌이.. ㅠㅠ
대부분의 웹페이지에서 gradle플러그인을 설치하고 gradle 프로젝트를 생성하고 시작하더라구요..
저는 기존에 있던 프로젝트에서 gradle을 도입해서 라이브러리 관리를 좀 더 쉽게 해보려던 것인데 생각한것처럼 쉽지가 않네요
다만 Gradle은 좀 더 프로젝트에 동적인 설정이 많을 때 훨씬 유리합니다.
단순히 Library 의존성만 지정할 때는 Maven 써도 상관없습니다.
하지만 대부분의 웹 애플리케이션들은 개발이 진행될 수록 상당히 동적인 설정이 많이 들어가는 편입니다. 그럴 때 Gradle이 Maven보다 훨씬 강력합니다.
지금 무료 e북으로 제공되고 있는 gradle in action을 프린트해서 읽어보고 있습니다
초반부분을 읽어보니 생성했었던 프로젝트를 갈아 엎고 개선시킨다던지 다른 운영체제에서도 개발을 이어나가고 싶다던지 할때 불편했던 점을 보완시켜줄 수 있다는 생각이 드네요