이젠 몇번째인지도 모르겠다. Maven에 대한 달콤한 설명이 담긴 아티클이나 블로그를 읽고 Maven을 써보려고 시도했다가 실망하고 포기한 횟수가 말이다. 제대로 규모있는 프로젝트에 적용도 안해보고 겉모습만 보고 Maven이 좋다고 떠들어대는 사람들에게 짜증도 많이 났다. 수년간 이미 ANT로 빌드를 잘 하고 살아왔는데 구지 Maven이라는 엉성한 툴에 자꾸 도전을 하게 되는 이유는 사실 딱 한가지이다. 라이브러리 파일을 프로젝트마다 저장하고 매번 다운 받는 다는 것이 불편했기 때문이다.

스프링과 하이버네이트를 비롯한 다양한 오픈+상용 프레임워크로 구성된 프로젝트를 만들어보면 빌드와 런타임 또 테스트시에 필요로 하는 jar 파일만 수십여개다. 용량도 만만치 않은데다가 매번 버전관리하는 것도 귀찮았다. 나 처럼 다양한 프로젝트를 자주 만들어서 기술을 테스트 해보는 경우에는 원격 리포지토리에 매번 용량이 큰 프로젝트를 통채로 올리는 것도 부담이 됐다. 게다가 Subversion은 commit/update에 트랜잭션 개념이 적용된다. 초기 checkout이나 import를 할 때 중간에 실패하면 다 롤백되버린다는 것. 네트웍이 좋지 않거나, 원격지에 있는 리포지토리를 사용하게 되면 checkout 하다가 실패해서 여러번 다시 시도하는 일도 종종 생기기 마련이다.

그런면에서 Maven이 주장하는 센트랄 리포지토리를 통한 다운로드와 로컬 리포지토리를 통한 라이브러리 파일의 공유기능은 얼마나 매력적인가.

언젠가 스프링, 하이버네이트로 만들어진 프로젝트를 다운 받은 적이 있는데 프로젝트 자체는 아주 작은 용량이었다. 이를 Maven을 설치하고 빌드를 하니 필요로 하는 라이브러리들이 네트웍에서 척척 받아지고, 테스트까지 멋지게 돌아가는 모습을 보고는 바로 이거다 하는 생각이 들었다.

하지만 Maven을 정작 사용해서 프로젝트를 만들어보니 기대했던 것과는 다르게 불편한 점과 실망스러운 점이 한두가지가 아니었다. 조금 불편한 점이라면 다른 장점을 생각해서 그냥 사용해보도록 하겠는데, 이건 거의 프로젝트 개발환경이 엉망이 되는데다, 생산성이 극도로 저하되고 불필요한 스트레스를 잔뜩 받게 되는 수준이었다.

많은 개발자들이 막연하게 가지고 있는 환상중의 하나가 Maven을 사용하면 라이브러리 의존관계문제가 간단히 해결된다는 것이다. 우리가 사용하는 많은 프레임워크들은 그 자체로 또 다른 라이브러리나 프레임워크를 사용하기도 한다. 이런 경우 프로젝트 빌드, 런타임, 테스트시에 필요로 하는 파일들을 일일히 확인해서 이를 프로젝트에 포함시켜야 하는데 그게 만만치 않은 작업이다. 하지만 Maven은 개발하는 애플리케이션이 직접 사용하는 프레임워크의 버전만 pom.xml에 간단히 적어주면 알아서 필요한 파일과 그 의존 파일까지 가져온다는 것이 Maven을 100미터 떨어져서 볼 때 느끼는 매력이다.

하지만 막상 자세히 들여다보면 그런 환상적인 의존관계 관리나 파일 다운로딩은 존재하지 않는다. 혹시나 사용할 라이브러리가 JUnit, Log4J와 일부 Commons정도라면 모르겠다. 하지만 일단 스프링이나 하이버네이트와 같은 규모있는 프레임워크를 쓰기 시작한다면 역시나 의존관계의 수렁에 발을 담그지 않고 곱게 넘어갈 방법이 없다는 것을 깨달을 것이다.

Maven의 의존관계 관리가 그다지 쓸모있지 않은데는 여러가지 이유가 있다.

첫째는 매우 한심한 수준의 Maven 리포지토리에 있다. 과연 우리가 필요로 하는 라이브러리와 프레임워크들이 모두 Maven의 센트랄 리포지토리에 존재하냐 하면 그렇지 않다. 없는 프로젝트들도 많거니와 있다고 해도 아주 옛날버전인 경우가 많다. 더군다나 한 프로젝트의 pom.xml에는 dependency가 명시 되어있으나 센트랄 리포에는 없는 것들도 무지 많다. 그러면 결국 dependency 파일에러가 나면서 라이브러리를 직접 로칼 리포지토리에 넣으라는 당황스러운 메시지를 만나게 된다.

나는 센트랄 리포지토리가 어떻게 관리되는지는 잘 모른다. 하지만 Matt Raible등의 Maven에 대한 불평을 잘 들어보면 제대로 관리 되고 있지 않다는 점은 분명하다. 쓰레기성 데이터도 많고, 필요한 라이브러리가 제때에 반영되지도 않는다.

아무리 멋지게 Maven으로 프로젝트를 만들고 이를 배포해도, 그 의존라이브리러가 없다면 결국 개개인이 파일을 구해서 로컬 리포지토리에 넣어주는 수고를 반복적으로 해야한다는 말이다.

두번째 문제는 의존관계 설정이 불필요하게 들어가 있는 경우가 많다는 것이다. 사실 불필요하다는 것은 사용하는 컨텍스트에 따라서 달라진다. 예를 들어 스프링은 사용하른 의존라이브러리의 숫자가 60여개가 넘는다. 그런데 사실 스프링 전체적으로는 그렇지만 우리가 사용하는 애플리케이션에서 그 기능을 쓰지 않는한 그 모든 파일이 필요한 것은 아니다. 예를 들어 나는 ibatis만 쓰고 hibernate를 쓰지 않는다. 그런데.. 스프링의 pom에는 hibernate와 관련 라이브러리가 모두 스프링의 의존파일이라고 명시되어있다면 매번 나는 불필요한 하이버네이트 라이브러리들을 가지고 가야 할 것이다.

그래서 optional이라는 설정이 있다. 반드시 필요하지 않은 라이브러리는 참조는 하되 꼭 필요하지 않고 선택적으로 사용하라는 뜻인 것 같다. 문제는 optional은 자동으로 다운로드 되지 않는다. 내가 일일히 설정을 바꿔줘야 한다.  SpringFramwork을 내 프로젝트에 dependency로 설정했다고 해서 내가 필요로하는 기능을 사용하기 위해서 스프링이 필요로하는 라이브러리는 또다시 명시적으로 필요하다고 등록을 해줘야 한다는 말이다.

그렇다고 모든 필요할지도 모르는 파일들이 라이브리러의 pom에 모두 설정이 되어있으면? 위에서 말한 것처럼 엄청나게 불필요한 라이브러리 파일들이 내 프로젝트에 모두 포함되게 된다. 예를 들어 spring을 설정했더니 spring -> hibernate -> jboss -> commons-xxx -> avalon -> … 이런 식으로 물고 물어서 엄청난 다운로딩이 일어나고 war파일의 크기가 필요한 것의 수십배로 늘어날 지도 모른다는 것이다.

그래서 필요한 것이 exclusion이다.

예를 들면 아래와 같은 설정이 종종 등장하게 된다.

<dependency>
    <groupId>org.hibernate</groupId>
    <artifactId>hibernate-annotations</artifactId>
    <version>3.3.0.ga</version>
    <!– persistence-api –>
    <exclusions>
        <exclusion>
            <groupId>org.hibernate</groupId>
            <artifactId>hibernate</artifactId>
        </exclusion>
        <exclusion>
            <groupId>org.apache.lucene</groupId>
            <artifactId>lucene-core</artifactId>
        </exclusion>
    </exclusions>
</dependency>

나는 hibernate-annotations만 필요하고 hibernate는 최신버전인 3.2.5를 쓰고 싶다. 그런데 hibernate-annotations에는 내가 필요로 하지 않는 lucene-core와 버전이 다른 hibernate가 dependency로 설정되어있다. 이 경우 일일히 위와 같이 exclustion을 해줘야 한다. Exclustion이 덕지 덕지 들어있는 POM을 가지고는 그 프로젝트의 의존관계를 깔끔하게 이해할 수 있으리란 기대는 일찌감치 포기하는게 좋다. 또한 내가 사용하는 라이브러리의 그 자체 POM을 일일히 열어보고 그것이 필요로 하는 라이브러리들이 무엇이 있고 무엇을 사용할지를 일일히 확인하고 필요없는 것은 excusion해주는 노가다가 뒤따른다.

세번째 문제는 매번 버전에 민감하게 세팅이 필요하다는 점이다. OSGi처럼 범위를 준다거나, 특정 버전 이상에서 가장 최신의 것을 선택하거나 하는 방법이 불가능하다.

결국 Maven의 의존관계 관리 기능은 단순하게 생각하면 환상적으로 보이지만, 실전에서는 리포지토리에 없는 파일의 수동 추가, 의존관계의 수동분석을 통한 exclusions관리, 그리고 세세한 버전 설정등의 노가다가 따라야 하고 이는 결국 ANT로 해서 일일히 필요한 라이브리러 파일을 프로젝트에 추가해줬을 때에 비해서 장점이라곤 설정을 완벽하게 해놨을 때 프로젝트간 의존파일을 공유할 수 있다는 정도 밖에 없다.

 

불편한 설정방법 또한 중요한 이유이다.

애트리뷰트를 전혀 사용하지 않고 엘레멘트로만 구성된 Maven XML설정파일은 정말 그 길이가 장난이 아니다. 무슨 똥고집인지는 모르겠으나 Maven 개발팀은 애트리뷰트 적용을 완고하게 거부하고 있다. 여러사람들이 애트리뷰트 버전을 만들어서 적용해보려는 수고를 하지만 받아들여질 가능성은 거의 없어 보인다. 그렇다고 편리하게 설정을 할 수 있도록 지원해주는 툴도 없다. 한줄에 끝날 설정을 태그를 열고 닫고, 중첩하고 해서 5-6줄 이상으로 늘려서 적다보면 정말 지친다. ANT 설정파일이 복잡하다고는 하지만 Maven 작업보다 훨씬 나은 것 같다.

 

문서의 부족도 큰 문제이다.

Maven은 수많은 플러그인의 조합으로 동작하게 되어있다. 기본 phase들로 구성된 라이프사이클에 많은 플러그인들이 바인딩 되서 동작하게 되어있다. 하지만 하나 하나 제대로 된 최신 문서를 찾아보기 힘들다. 사실 Maven자체에 대한 개념을 쉽게 이해하는 문서도 매우 부족하다. 그나마 Maven개발팀이 만든 회사들(회사를 잘도 만들고, 옮기고, 닫고 그러는 것 같다)에서 내어놓은 일부 문서가 조금 도움이 되지만 0.01버전만 올라가도 동작하지 않는 예제들과 빠르게 업데이트 되지 않는 문서들을 보면 한숨만 나온다. 나온지 한참됐는데 아직도 alpha-2인 The Definite Guide가 그나마 Maven초보자들에게 조금 도움이 되는 문서이다. Better Builds with Maven은 버전이 정확히 일치하지 않으면 내용대로 실행이 안되는 문제점이 있지만 그나마 상세한 설명이 있는 자료이다. 하지만 이정도 문서 가지고 초보자들이 쉽게 Maven으로 프로젝트를 구성해서 사용할 수 있을 것으로는 전혀 기대할 수 없다.

플러그인 문서의 한심함은 더 말할 나위가 없다. Maven으로 프로젝트 설정작업을 한참 하다 보면 나도 모르게 사용하는 플러그인의 소스를 뜯어보고 있는 모습을 발견하게 된다. 나만 그런건 아닌가보다. 얼마전 Bill Burke도 비슷한 불평을 올린 적이 있다. "Are these plugin developers idiots?" 100% 동감한다. 댓글에 달린 "It is really a shame that Java community does not have a sophisticated build tool after so many years!" 을 읽다가 내가 Maven을 대신할 빌드툴을 만들까하는 생각까지도 잠깐 하기도 했다.

 

마지막으로 Maven이 강제하는 프로젝트 구조도 고민스럽다. Maven을 처음 쓸때 가장 당황스러웠던 점은 일반적으로 eclipse에서 흔히 쓰는 스타일인

project root – src
                  – test
                  – web
                  – bin

구조가 아니라

project root – src – main – java
                                     – resources
                                     – webapp
                          – test  – java
                                    – resources

구조를 강제한다는 점이다.

일단 당황스러운 것은 main/test라는 한단계 늘어난 폴더 구조이다. 이클립스의 Package Explorer창에서 패키지가 긴 프로젝트 파일을 열고 닫고 찾는 일이 얼마나 귀찮은지 아는 나에게 거기다 한단계 더 들어간 구조를 강제하는 것은 화면의 낭비이자, 네이게이션에 대한 불편함을 가중시키는 짜증나는 구조로 밖에 안보였다. 그것을 내가 흔히 쓰는 편한 구조로 바꾸고 싶었지만 결국 못하고 말았다. 아키텍처 구조를 바꾸는 것도 만만치 않은 일인데다 바꿔놔도 여러가지 플러그인에서 제대로 동작한다는 보장도 없기 때문에 전혀 권장되지 않는 방법이기 때문이다.

또 하나 불편한 점은 자바소스와 리소스를 분리했다는 점이다. 얼핏보면 개념적으로는 좋은 접근처럼 보인다. 대부분의 설정용 리소스가 루트에 있는 경우라면 그나마 별 상관없다. 하지만 Test처럼 관련 리소스(테스트 데이터가 담긴 xml이나 스프링 설정파일) 등은 같은 클래스패스에서 리소스로 읽는 것이 디폴트이기 때문에 모두 같은 패키지에 위치 시켜야 한다. 그래서 결국 다음과 같은 스타일이 된다.

root
   + test
         + java
                 + net
                       + openseed
                               + osaf
                                     + datalayer
                                          + hibernate
                                               + HibernateGenericDao.java
         + resources
                 + net
                       + openseed
                               + osaf
                                     + datalayer
                                          + hibernate
                                               + test-context.xml
                                               + test-data.xml

Mylyn을 쓴 것처럼 달랑 세개 파일을 적었으니 그나마 간단히 보이지, 사실 이클립스 스타일이라면 간단히 같은 폴더에 넣고 생성하고 열면 되는 파일을 일일히 패키지를 다시 만들고 그 안에 넣고, 저 많은 폴더를 열어서 찾아야 하다니 얼마나 불편하지 모르겠다.

그냥 ANT 쓰던 스타일로 Java클래스와 리소스를 같은 파일에 넣으면 안되는 이유가 뭘까. 어짜피 java로 끝나는 확장자로 구분해서 컴파일과 카피를 적절히 해주면 되는데 말이다.

더 얘기하면 WTP와 Maven의 불편한 관계와 이를 연동시키기 위한 여러가지 땜빵기술들을 찾는 것 등등이 있으나 이쯤에서 생략.. 계속 하려면 끝도 없을 것이다.

 

정리하자면,

Maven의 사용은 기대와는 달리 그다지 많은 편익을 주지 않으면서 이클립스와 같은 기존 개발환경을 가진 사람에게는 불편을 주기도 한다는 점이다. 플러그인 문제는 다음에 좀 더 얘기하도록 하고 오늘 내용을 정리해서 한마디로 하자면

Maven의 사용은 프로젝트를 만들고 빌드환경우 구축하는 면에서 그다지 장점이 없으며, 제대로 사용하기 위해서는 전문적인 지식(Maven + 프로젝트 의존관계)이 필요하다.

라고 할 수 있겠다.

 

이런 이유 때문에 결국 Maven을 사용하지 못하고 여러차례 다시 ANT로 돌아가야만 했다. 또는 JRuby등으로 만들어진 다른 빌드 대안을 찾아보기도 했다.

하지만 최근에 다시 Maven으로 프로젝트를 구성하는 것에 도전중이다. 그렇게 된 배경에는 Maven에 대한 기대치가 워낙 낮아졌기 때문에 그다지 실망하지 않고 담담한 마음으로 접근할 수 있다는 것과 최근에 발견한 Maven의 활용팁들이 주는 편리함이 있다. 아직 100% 만족할 수준은 아니지만 신규 프로젝트와 기존 프로젝트에 모두 Maven을 적용했고 이를 CI에 까지 연동해서 성공적으로 사용하고 있다.

그동안 발견한 좋은 Maven활용 팁들과 Maven에 대해서 했던 고민들에 대해서는 계속 이어서 얘기해보도록 하겠다.

Related posts:

  1. Spring 3.0 (34) R-941 스프링의 Maven 지원정책은?
  2. Maven 3.0과 버전 포맷 문제
  3. Maven의 새로운 가이드북 – Maven: The Definitive Guide
  4. Nexus Maven Repository 1.0 출시
  5. Maven 다중 리포지토리와 버전 범위를 사용할 때의 주의점
  6. Maven archetype 설정파일 자동생성기 – ArchetypeXmlWriter
  7. Maven 의존관계 수렁에 빠지다
  8. Maven settings.xml의 비밀번호 암호화
  9. Maven: The Definitive Guide 사라지다
  10. Maven POM에 attribute 사용하기 (2)
  11. Maven POM에 attribute 사용하기 (1)
  12. Ruby on Maven
  13. Project Irene 시작하다
  14. Maven의 다중 리포지토리에 존재하는 동일 artifact 사용시 주의점
  15. Maven과 OSGi(Spring)의 버전포맷 비호환 문제

Facebook comments:

to “Maven 재도전기 (1)”

  1. nice articles

  2. Look At THIS Web-Site
    [url=http://www.czcsb168.com/templets/michael-michaelkors-hamilton-cadena-de-cuero-bolsaa8q.html]bolsas michael kors[/url]
    bolsas michael kors

  3. Hop Over To These Guys
    [url=http://www.boemi.net/webs/online.asp?/goyard-luggage-londongoyardofficial.html]goyard luggage london,goyard,official[/url]
    goyard luggage london,goyard,official

  4. What are Hedge Cash? michael zimmerman Prentice Capital Additional money cost no service fees till the money complete certain overall performance goals. Usual expenses intended for hedge money are generally 20 percentage associated with profits additionally a pair of percent connected with assets under managing. Famous and also effective professionals typically require greater costs.

  5. In essence, hedge funds are usually communal money for your super-rich. They appear to be shared finances in terms ventures tend to be put in addition to skillfully handled, they tend to be appreciably different in the way account can certainly cooperate. http://www.yellowbook.com/profile/prentice-capital-management_1864878210.html

  6. You Can Try These Out
    [url=http://www.zhongtie021.com/member/editiinfoicompany.php?/breast-cancer-limited-edition-ugg-boots-there-are-many-diferent-kinds-of-designer-2013.html]breast cancer limited edition ugg boots-There are many diferent kinds of designer 2013[/url]
    breast cancer limited edition ugg boots-There are many diferent kinds of designer 2013

  7. Click Here To Investigate
    [url=http://bootsforwomenoutlet.com]ugg slippers women[/url]
    ugg slippers women

  8. Pop Over To THIS Web-Site
    [url=http://cheapbaileybuttonoutlet.com]mini uggs[/url]
    mini uggs

  9. black mbt shoes Maven 재도전기 (1) » Toby’s Epril

  10. mbt tunisha shoes Maven 재도전기 (1) » Toby’s Epril

  11. viagra preço
    Ensure that you get others’ opinions of your photographs. Try and acquire some people that know a lot concerning this field and this are excellent at photography to critique your photographs. Be aware that you will have bad and good responses just don’t bring it individually. Learn from everything and get greater at it.
    dapoxetine kaufen
    If holidays are supposed to be calming, then how come travelling so demanding? Often, it seems as believed it might be quicker to just stay home, however, you don’t need to have to stop on the journey! This information will help you overcome the pressures of touring so that you can kick rear and savor your time and energy out.
    levitra schweiz
    How will you truly feel regarding your pearly whites? Are you content with your dental professional? Can you look after your teeth well enough in the middle trips? If you have any negative reactions to the inquiries, then this article is for yourself. It’s time to manage your dental scenario and understand some information that will shift you forward.
    priligy kaufen

  12. kamagra gel
    Make sure you ask anyone who is marketing a car which kind of operate continues to be accomplished upon it. You should also make sure to talk about it thoroughly to discover if you need to do any operate. Bring along a friend that knows about this stuff if you’re not totally certain what to look for.
    dapoxetin schweiz
    To get the best Search engine optimization, make sure you provide written text backlinks on your own web site. This will assist search engines like yahoo fully grasp precisely what you are actually supplying. It will also, make it easier for anyone to utilize and have confidence in back links mainly because they should be able to see in which they can be heading, instead of simply clicking sightless with a masked link.
    kamagra 100 mg
    In the event that you might be constantly resting together with your mouth area available, consider trying to keep the mouth shut down through the entire nighttime. This will make it much simpler for you to not only take in air, but preserve it too. Sleep at night with the mouth area closed to reduce heavy snoring when you relax at nighttime.
    cialis schweiz

Leave a Reply

(required)

(required)

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

© 2017 Toby's Epril Suffusion theme by Sayontan Sinha