InfoQ에 기사가 올라왔다. 메이븐 2까지는
Plexus DI container 라는 넘을 쓴 모양이다. 글을 올린 InfoQ의
Josh Long의 요약에 따르면 메이블 플러그인 개발이 Plexus에 종속적인 면(Plugin authors need to understand Plexus)과 부족한 문서(the poor documentation)를 들었다. 다른 이유로 메이블 프로젝트와 소나타입(Sonatype) 창립자인
Jason Van Zyl의 말을 인용했다.
Van Zyl cites many reasons for the migration from Plexus to Guice,besides the poor documentation. He describes the need to reduce thecommitment to the Plexus project, saying that the Maven project didn'tintended to build and support a DI container, but to promote and buildtools and infrastructure supporting developers and builds.
얼핏 읽어보면 기반 솔루션(IoC 컨테이너)보다는 핵심 역량(개발 지원 및 빌드 도구)에 집중한다는 듯하다. 하지만,
Jason Van Zyl 이
JSR 330: Dependency Injection for Java Expert Group 구성원란 점을 안다면 다르게 해석할 수 있다.
그가 작성한 글을 보면 Guice의 기능 때문에 오랜 친구(?)를 버린 듯하다.
제이슨이 직접 스프링(Spring)이 아닌 이유를 언급하진 않았는데, 메이븐 개발자인 Stuart McCulloch이 나와 같은 궁금증이 있던 방문자의 글에 답을 달았다.
The main reason for using Guice was its support for programmatic bindings: ie. Modules and the binding DSL. This really helped us mapPlexus metadata to Guice bindings at runtime while still providing alevel of type-safety. I know Spring has JavaConfig, but this wouldrequire an annotated method per-bean (@Bean) which means you'd need todynamically create binding classes using CGLIB or ASM, etc. I'm surethe core Spring container can be configured directly using method calls(ie. no XML/annotations) but I don't believe it would be as easy as theGuice binding DSL.
OSGi In Action의 저자이기도 한 Stuart McCulloch가
Felix에 참여한다는 점을 고려하면 Spring을 선호할 가능성은 매우 낮아 보이기도 한다. 현재
메이븐3 버전은 알파 6에 머물러 있다. 메이븐3은 메이븐을 시도하면서 겪었던 거부감을 완화하고 편리함을 느끼게 해줄 수 있을까?
이올린에 북마크하기
이올린에 추천하기
Bowling Game Kata With Eclipse Keys.ppt
