Maven을 넘어 Gradle로 가자. 프로그래밍

Maven을 써 본 사람들은 대부분 느끼리라 생각하지만 매우 경직돼 있고 그로인해 무언가 Maven이 기본 지원하지 않는 빌드 과정을 추가해야 할 경우 고생이 이만 저만이 아니다. 이에, 요즘 Maven 대한 대안이 많이 나오고 있으며 그 중 가장 돋보이는 것이 Gradle(Groovy 기반)이 아닌가 싶다. 그래서 차기 프로젝트의 빌드 툴로 Gradle을 도입해보고자 현재 프로젝트의 빌드 구성(매우 복잡하다)을 Gradle로 바꿔보며 그 가능성을 시험해 보았고 그 과정을 정리해 보았다.

매우 긴 내용이 될 것이라서 성질 급한 사람들을 위해 요약한다.
  • 난 이제 가능하면 Maven 안 쓴다. 되도록 항상 Gradle 혹은 이것보다 나은 툴이 나온다면 그것을 사용하리라.
  • Gradle의 사용자 가이드를 번역해 두었다. Java 프로젝트를 진행하는데 필요한 거의 모든 내용을 번역하였고, 또한 내가 경험하며 검색등으로 찾은 문제 해결책들도 모두 정리해 두었다. Maven 공부할 시간에 Groovy + Gradle 공부하는게 더 생산적이라고 생각한다.

내가 생각하는 Maven의 가장 큰 문제점은 두가지이다.
  • 프로젝트 구성/빌드 툴로써 프로젝트 구성은 정적인 설정 정보이고 빌드는 동적인 행위이다. 그런데 이것을 정적인 데이터를 저장하는데 적합한 XML로 그 내용을 기술하게 함으로써 동적인 행위인 빌드에 크나큰 제약을 가한다. 게다가 XML은 너무 장황해서 실제 설정 내용보다 XML 뼈대가 더 많다.
  • 다른 하나는 Gradle을 사용하다 느낀 것인데, Maven은 설계상의 문제도 있다. 바로 멀티 프로젝트 구성을 상속 구조로 한 점이다. 그에 반해 Gradle은 구성 주입 방식(Configuration Injection, 설정 주입 방식이 더 나은 번역일까?)을 사용한다. 이는 빌드 구성 정보에서 매우 큰 차이를 만든다.
Gradle은 Groovy DSL로 작성하며, 설정 정보는 변수에 값을 넣는 형태로, 동적인 빌드는 Groovy 스크립트로 Gradle용 플러그인을 호출하거나 직접 코드를 짜면 된다.

상속 구조는 공통 설정을 여러 프로젝트가 공유할 때 비어있는(Abstract) 프로젝트를 만들어서 거기에다 공통 설정을 넣고 그걸 상속하게 해야한다. 게다가 어느 플러그인의 설정이 조금만 달라도 해당 플러그인이 아주 유연하게 만들어져 있지 않은 이상 설정을 분리해서 프로젝트별로 중복 기술해야 한다. 즉, Maven을 사용하면 쓸데없이 설정이 길어지고 중복이 발생하며 가독성도 매우 떨어진다.

그에 반해 구성주입 방식은 그냥 어떤 프로젝트 구성 정보가 있으면 그것을 필요한 프로젝트에 주입하는 방식이다. 주입시 프로젝트의 조건을 체크할 수 있어서 프로젝트 별로 약간 다른 설정이 가능하다. 또한 공통 구성만 주입하고 프로젝트 별로 다른 점은 바로 그 점만 프로젝트 별로 주입시켜주면 된다.

이렇게 크게 두가지점 이 Gradle이 Maven보다 훨씬 뛰어난 점이며 그것만으로도 Gradle을 사용하는 것이 훨씬 더 편하다는 것을 알 수 있다.

그럼 내가 Maven에서 Gradle(현재 1.2)로 변환한 프로젝트는 어느 정도의 복잡도를 가지고 있었을까? 단순히 CLASSPATH 지정만으로 해결되는 아키텍처들은 제외하고 빌드 구성에 영향을 주는 복잡성들만 나열하면 다음과 같다.

  1. 15개 정도의 프로젝트가 서로간의 의존 관계를 맺고 있다.
  2. Spring 3.1이 뼈대를 이룬다.(이것 자체는 빌드에 영향을 안 줌)
  3. Apache CXF를 통해 SOAP Client Java 클래스 자동 생성하고 이를 각종 서비스에서 사용한다.
  4. JPA 2를 ORM으로 사용하며 이것의 StaticMetaModel Java Class들을 자동 생성해야 한다.(Annotation Processor)
  5. Lombok 을 사용하여 Getter/Setter/Slf4j/기타 등등의 코드를 자동 생성한다.(Annotation Processor)
  6. 웹 프로젝트들은 공통 리소스를 가지고 있으며 Eclipse에서는 LinkedResource로 지정되어 개발시 불필요한 공통 요소 복제 작업이 안 일어나도록 처리하고 있다.
  7. 웹 프로젝트에서 Javascript 파일을 빌드 툴에서 자동 최적화 해서 배포해 준다.
  8. Carbon Five Database Migration 툴로 데이터베이스 마이그레이션을 진행한다.
  9. Eclipse와 연동해야 한다. Eclipse 전용 플러그인이 있지는 않아도, 최소한 Gradle의 구성 상태를 Eclipse 설정으로 그대로 명령어 한 방으로 옮길 수 있어야 한다.
  10. 추가) 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을 사용하자.



핑백

덧글

  • 밀리네스 2012/10/15 10:19 # 답글

    1년 반째 gradle을 쓰고 있는중인데, 단순 빌드가 아닌 사이트 자동화도 gradle로 처리중입니다.
    배포하고 L4 스위치 제어하고 재기동하고등등은 사이트마다 워낙 다른지라 애시당초 maven을 쳐다보지도 않았었죠.
    예전에는 ATN+Groovy Task를 썼는데 Gradle로 이전한후 참 편하게 쓰고 있지요.
  • 권남 2012/10/15 10:59 #

    Gradle 자체가 Ant를 내장하고 있어서 거의 불가능이 없는 툴이지요. 정말 잘 활용하고 계신것 같습니다. 경험을 공유해주시면 좋겠습니다.

    하지만 저는 프로젝트 관리용 툴과 배포자동화 툴을 분리할 생각입니다. 그래서 프로젝트 관리/빌드는 Gradle로, 배포 자동화는 Gant를 생각중입니다(Capistrano 역할을 Gant에 맡겨볼려구요).
  • 밀리네스 2012/10/15 11:21 #

    Gant 공식 사이트에서도 Gradle이 성장하면 Gant는 필요 없을거라고 하는데 굳이 Gant 병행을 선택하시는 이유가 무엇인지 궁굼합니다.
  • 권남 2012/10/15 13:41 #

    "성장하면"이 아니라 이미 충분히 성장했고 Gradle 입장에서 이미 Gant는 필요없는존재라고 생각합니다.

    제가 굳이 그걸 나누는 이유는 "프로젝트구성/빌드"와 "배포"는 별개의 행위이며 "배포"에 해당하는 코드가 "빌드"에 해당하는 코드에 들어가서 섞이는 것을 싫어하기 때문입니다. 저희 같은 경우 하나의 프로젝트가 네 군데에 배포됩니다. 그리고 각각에 배포되는 스크립트도 살짝씩 다르죠. 그런 것들이 빌드 스크립트 소스에 말려 들어가는 것을 원치 않습니다.

    사실 배포에 해당하는 코드도 프로젝트와는 무관한 별도의 배포전용 build.gradle로 만들수 있겠죠. 근데 배포에 필요한 기능보다 Gradle의 기능셋이 더 큽니다. 그래서 굳이 Gradle을 사용하지 않고 Gant를 사용하려고 합니다.
    하지만 막상 해보고 마음이 어떻게 바뀔지는 모릅니다. 아직 안해봤거든요.

    결국엔 그냥 Capistrano로 갈 수도 있겠죠. Gant냐 Gradle이냐 보다 더 중요한 것은 Linux 머신 상에서 SSH/SCP 등을 넘나들며 유연하게 배포할 수 있느냐니까요.
  • oeegee 2013/02/06 12:28 # 삭제 답글

    말씀하신 Gradle, Gant 외에 flyway, Capistrano 너무 많네요.
    Maven은 리모드 넥서스에서 시간을 너무 소비해서 적용에서 제외했었지요. 아직 Ant에 머무르고 있는데,
    Gradle은 꽤 매력적으로 보입니다.
    덕분에 Gradle을 알게 되었습니다. 감사합니다.
  • 권남 2013/09/16 13:31 #

    flyway DB 마이그레이션 툴입니다.
    Ant,Maven, Gradle 모두 거쳐서 사용해보았습니다. Gradle이 최고입니다.
    gant,Capistrano는 그 대신 Python 언어로 만들어진 Fabric이라는 것도 괜찮아보입니다.
    Fabric이 더 간편하다는 얘기가 많네요.
  • 난누구여긴어디 2013/03/28 17:50 # 답글

    좋은 글 감사합니다.
    저도 개인적으로 메이븐에 한번 데인적 있어서 Ant 만 주로 쓰고 있었는데...
    기회가 되면 저도 Gradle 꼭 사용해봐야겠네요 ^^
  • 달빛 2013/05/16 10:06 # 답글

    블로그에서 유용한 글들 많이 읽고가는 초보개발자입니다.
    이제 막 웹개발로 입문한 개발자인데 아직은 저와 먼이야기같네요. 갈길이 멀기만하군요~
  • huewu 2013/06/03 09:53 # 삭제 답글

    정말 좋은 자료 감사합니다.

    현업 안드로이드 개발자인데 앞으로 안드로이드 쪽 빌드 시스템이 그래들로 옮겨갈 예정이라고 하네요. 처음 Gradle 을 접하게 되었는데 큰 도움이 되었습니다 =)
  • 권남 2013/06/03 10:02 #

    네, Android Studio가 Gradle기반으로 바뀌었다는 얘기를 들었습니다. 확실히 편해지실거예요.
  • 애너벨리 2013/07/05 09:49 # 삭제 답글

    저도 Maven을 쭉 써왔지만 많이 불편하다고 느꼈습니다..
    xml 뼈대가 진짜 너무 비대해집니다.... 이제는 그래들을 배워야 할 때 인거같습니다 좋은자료 잘보겠습니다^^
  • 애너벨리 2013/07/05 13:41 # 삭제 답글

    권남님 오전부터 지금껏 그래들을 쭉 해봤는데,
    음.. 소스가 아주 간결해지고 깔끔해지는건 너무 좋은데,
    MAVEN 의 M2ECLIPSE플러그인의 편의성과 수많은 플러그인을 생각했을땐,
    아직 GRADLE 로 넘어가기엔 조~금은 이른게 아닌가 하는 생각이 들었습니다..
    오늘 처음 GRADLE을 살펴본 느낌인데, 어떻게 생각하시는지요??
    전 그저 오늘 처음본 소감을 말씀드린거고, 권남님의 의견을 듣고 싶어서요~
  • 권남 2013/07/05 14:43 #

    Maven의 M2Eclipse는 pom.xml 변경시 자동적용을 해주지요. 그게 편할지는 모르지만 저는 제가 변경한 설정을 고치다가 최종적으로 반영하고 싶을 때 gradle eclipse clean 하는 것이 더 편하게 느껴집니다. 저는 Maven 쓸 때도 M2Eclipse가 불편하고 느려서 안썼습니다. maven eclipse 명령을 썼지요.
    좀 더 편하게 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로 버튼 만들어 두면 나중엔 오히려 더 편해합니다.
  • 애너벨리 2013/07/19 09:43 # 삭제 답글

    좋은 말씀 감사합니다 ~ 좀 더 깊게 보고 있는 중입니다
  • 에쿠우스 2013/08/22 11:47 # 삭제 답글

    저는 이제 처음 maven을 적용하려고 합니다.
    글을 잘 읽었습니다.
    하지만 Nexus + Maven에 대해서는 언급을 하지 않으셨던데 단지 Maven만 사용 할때와
    Nexus + Maven을 사용할때는 다르다고 생각합니다.
  • 권남 2013/08/22 17:32 #

    Maven과 Nexus를 함께 사용하면 어떤점이 다른지 잘 모르겠습니다만, Nexus는 그냥 Maven 리포지토리일 뿐이므로 Gradle도 Nexus를 Maven이 사용하는 것과 동일하게 사용합니다.
  • Kevin 2013/08/24 21:36 # 삭제 답글

    빌드하는데 필요한게 Maven plugin이나 기본 기능으로 안 돼서, 얼마전에 플러긴을 만들어서 쓰고 있습니다만, 플러긴 만드는거 자체도 좀 불편하고, 플러긴으로도 안 되는게 있고 해서 꽤 편법을 써서 해결을 했습니다. Maven에 안 그래도 불만이 많았는데, 이글 보니까 이제는 저도 Gradle로 넘어가야겠네요. 좋은 정보 고맙습니다.
  • 청명공자 2013/09/16 11:32 # 삭제 답글

    한가지 gradle 관련 문의 드릴께요..
    인터넷이 안되는 환경에서는 gradle을 사용할 수 없나요??
    개인적으로 gradle 프로젝트를 진행하고 싶은데 인터넷 환경이 지원되지 않거든요~
  • 권남 2013/09/16 18:21 #

    Gradle과 Maven의 핵심 중에 하나는 라이브러리 의존성관리입니다.
    이 라이브러리들이 인터넷의 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
  • 국희땅콩샌드 2013/11/16 17:50 # 삭제 답글

    gradle 관련한 자료와 가이드 잘 보았습니다.

    한가지 여쭤보고 싶은 부분이...
    gradle project 를 eclipse tomcat-plugin 과 연동이 가능할까요?
    gradle project 의 경우 tomcat-plugin 의 서버 환경에서 아예 add and remove 목록에 나타나질 않아서요.

    아무래도 이클립스에서 tomcat log 를 볼수 있었던 점이 아쉽네요.
  • 권남 2013/11/16 21:53 #

    Eclipse WTP를 사용하시면 됩니다. tomcat-plugin은 굉장히 오래전에 쓰던 것인데 아직까지 사용할 이유가 있는지 잘 모르겠습니다.
  • hunikey 2013/12/05 13:19 # 삭제 답글

    인텔리제이 + Gradle 안드로이드 환경에 관한 자료를 찾다가 오게되었는데 많은 내용을 올려주셨네요.

    정독해야겠습니다. 좋은 글 올려주셔서 감사합니다.
  • Jack 2014/01/07 14:18 # 삭제 답글

    잘보고 갑니다.
    저도 Gradle 공부해봐야겠네요 maven만 봤었거든요
  • 두얼굴의 범고래 2014/02/19 21:54 # 답글

    근데 개인적으로 gradle은 안드로이드 스튜디오에서, 메이븐은 이클립스에서 써야할 듯 합니다.
    안드로이드 스튜디오는 키보드 세팅할게 너무 많아서 짜증....나네요.
    무엇보다, 우분투 13.10에서 한글 입력이 안됩니다. 즉시 포기..



    이클립스에서 gradle을 의존성 매니저로 써볼려고 했는데 안 되길래 찾아보니 이클립스 Integration에서는 아직 의존성 매니저 기능이 지원되지 않는다더라구요.
    aar형식 덕분에 고민이 많습니다... gradle을 쓰긴 해야되는데 한글이 안되면 답이 없어서..
  • 권남 2014/02/20 11:01 #

    저는 Ubuntu 13.10 + IntelliJ IDEA 12/13 사용자인데 한글 입력에 문제가 없습니다. 한글 입력기에 문제가 있는 것은 아닌지 확인 해보시기 바랍니다.

    Gradle은 Eclipse에서도 잘 작동합니다. 다만, Eclipse용 Gradle플러그인이 별로 안 좋은 관계로 gradle eclipse 명령을 사용하는 것이 좋습니다.
  • yakkle 2014/04/15 15:20 # 삭제 답글

    안녕하세요. gradle 검색해서 들어왔는데 참고가 될 만한 내용 잘 봤습니다.
    내용과는 상관없이 배경이 사선 이미지라 그런지 가독성이 엄청 떨어지고
    눈이 피곤해지네요.
    배경을 바꾸면 훨씬 좋을 것 같아 덧글 달고 갑니다.
  • 권남 2014/04/16 18:15 #

    넵. 안정적이고 글읽기 좋은 것으로 바꾸도록 하겠습니다.
  • 오토나스 2014/05/08 17:23 # 삭제 답글

    전자정부프레임웍을 써야 하는데 Maven이 싫어서(왜 싫은지는 잘 모르겠습니다. 그냥 싫어요!) 흠 잡을 게 없을까 검색하다가 여기까지 왔네요. Maven을 지나 Gradle 이라니.... 아! 넘 힘들어요. ^^;
    정리해 놓으신 글 덕분에 좋은 정보 + 생각 얻어 갑니다.
  • d 2014/06/01 06:47 # 삭제 답글

  • belll 2014/08/22 22:33 # 삭제 답글

    전 maven도 모르고 gradle도 모르는 쌩초보..-ㅅ-..
    이클립스가 자꾸 느려져서 성질나 안드스튜를 깔아봤더니 gradle인지 뭔지가 떡하니 중앙에..
    눙물을 머금고 찾아보니 이런 사이트가 떡
    감사합니당
  • 트라이건 2014/11/06 11:55 # 삭제 답글

    감사합니다.
    이제 공부해보려고 하는데 영어가 약한 저한테 도움이 많이될 것 같네요.!!
  • 갈수록 미쳐요 2014/12/05 12:41 # 삭제 답글

    메이븐 없이 생 스프링으로 개발을 하고 있습ㄴ;ㅣ다 항상 새로운 것을 배우는게 훌륭한 프로그래머 맞나요? 힘들어서 올려봅니다 ㅋㅋ
  • 권남 2014/12/07 14:09 #

    항상 새로운 것을 배우는 것은 훌륭한 프로그래머가 아닙니다.(그렇다고 나쁘다는 뜻도 아닙니다. 단지 새로운 것을 배운다는 것 자체가 훌륭한 프로그래머의 정의는 아니다 라는 의미입니다.)

    현재 개발을 하면서 어떤 문제가 반복적인 노가다성 작업인지, 인간의 실수를 유발하는 작업인지를 잘 살피고 그 문제를 해결하기 위해 공부하고 해결책을 제시하는 것은 훌륭한 프로그래머입니다.

    다른 사람들의 반복 적이고 인간이 하기에는 오류가 많은 것을 자동화해주는 "프로그래머"라는 직업에 종사하면서 자기 자신이 겪고 있는 문제조차 공부하기 싫어 외면한다는 것은 좋은 프로그래머가 아닙니다.
  • 최빈 2015/02/13 10:54 # 삭제 답글

    providedCompile 은 아직도 안고쳐졌네요 ㅠㅠ
  • 권남 2015/02/13 14:46 #

    안고쳐졌다기 보다는 할 생각이 없어보입니다.
    provided를 좋지않은 관례로 여기고 있습니다. 따라서 고쳐질 것 같지는 않아요...
    필요하실 경우 spring에서 만든 prop-deps plugin을 사용하시면 됩니다.
  • cookatrice 2015/03/13 09:16 # 삭제 답글

    좋은정보 감사합니다. )
    일단 저도 그루비부터 시작해야겠습니다. :)
    이제 바이바이 maven....
  • Cowshed 2015/06/12 16:54 # 삭제 답글

    안녕하세요. 회사에서 최근에 Maven 방식에서 Gradle 방식으로 넘어가게 되었는데
    구글에 "Gradle" 이라고 검색해보니 바로 권남님 블로그가 나오는군요.
    간단히 요약 정리해두신 글을 보고야 어느정도 감이 잡히는듯 합니다.
    좋은 정보 감사합니다.
  • 권남 2015/06/12 21:18 #

    Gradle은 이제 워낙 성숙해서 안되는거 없이 Maven보다 훨씬 쉽게 모든 문제가 해결 가능할겁니다.
    성공하시길~
  • ㄴㄷ 2016/07/22 02:26 # 삭제 답글

    gradle을 접해보려고 하는데요 초보자의 관점에서 gradle은 무엇을 위한 용도이다! 간단하게 정의해주실 수 있으신가요?
    maven을 라이브러리 가져오는 도구라고 인식하던 중 gradle을 사용해보려고 하는데 약간 개념이 다른 것 같아서요.. 라이브러리를 가져오는 도구라기 보기에는 프로젝트 자체가 gradle에 의존하느 느낌이.. ㅠㅠ
    대부분의 웹페이지에서 gradle플러그인을 설치하고 gradle 프로젝트를 생성하고 시작하더라구요..
    저는 기존에 있던 프로젝트에서 gradle을 도입해서 라이브러리 관리를 좀 더 쉽게 해보려던 것인데 생각한것처럼 쉽지가 않네요
  • 권남 2016/07/22 22:56 #

    Gradle과 Maven은 기본적으로 하는 일이 같습니다. Maven을 안다면 Gradle의 역할도 아는 것입니다.
    다만 Gradle은 좀 더 프로젝트에 동적인 설정이 많을 때 훨씬 유리합니다.
    단순히 Library 의존성만 지정할 때는 Maven 써도 상관없습니다.

    하지만 대부분의 웹 애플리케이션들은 개발이 진행될 수록 상당히 동적인 설정이 많이 들어가는 편입니다. 그럴 때 Gradle이 Maven보다 훨씬 강력합니다.
  • ㄴㄷ 2016/07/23 01:20 # 삭제 답글

    오래된 글이라 답변 안해주실줄 알았는데.. 감사합니다 ㅎㅎ
    지금 무료 e북으로 제공되고 있는 gradle in action을 프린트해서 읽어보고 있습니다
    초반부분을 읽어보니 생성했었던 프로젝트를 갈아 엎고 개선시킨다던지 다른 운영체제에서도 개발을 이어나가고 싶다던지 할때 불편했던 점을 보완시켜줄 수 있다는 생각이 드네요
댓글 입력 영역