사용자 도구

사이트 도구


gradle:from_maven

차이

문서의 선택한 두 판 사이의 차이를 보여줍니다.

차이 보기로 링크

양쪽 이전 판 이전 판
다음 판
이전 판
gradle:from_maven [2012/10/11 16:19]
kwon37xi [projectA의 단위테스트가 projectB의 단위테스트에 의존]
gradle:from_maven [2014/06/20 01:18] (현재)
kwon37xi [Gradle이 Maven보다 좋았던 점]
줄 7: 줄 7:
   * Maven은 상속 구조를 사용해 멀티 모듈을 구현한다. Gradle은 구성 주입(Configuration Injection)을 사용한다.   * Maven은 상속 구조를 사용해 멀티 모듈을 구현한다. Gradle은 구성 주입(Configuration Injection)을 사용한다.
     * Maven에서 특정 설정을 몇몇 모듈에서만 공통으로 사용하려면 불필요하게 부모 프로젝트를 생성하여 설정하고 그것을 자식들이 상속하게 해야 한다. 게다가 다른 모든게 같더라도 약간이라도 설정이 다른 프로젝트가 하나라도 있다면 그 프로젝트는 상속을 할 수 없고, 거의 모든 설정을 중복해서 해당 프로젝트에 넣어줘야 한다.     * Maven에서 특정 설정을 몇몇 모듈에서만 공통으로 사용하려면 불필요하게 부모 프로젝트를 생성하여 설정하고 그것을 자식들이 상속하게 해야 한다. 게다가 다른 모든게 같더라도 약간이라도 설정이 다른 프로젝트가 하나라도 있다면 그 프로젝트는 상속을 할 수 없고, 거의 모든 설정을 중복해서 해당 프로젝트에 넣어줘야 한다.
-    * Gradle은 공통 설정을 조건에 따라 특정 프로젝트에만 주입 가능하다. 불필요한 프로젝트는 필요없다.+    * Gradle은 공통 설정을 조건에 따라 특정 프로젝트에만 주입 가능하다. 불필요한 상속 전용 프로젝트는 필요없다.
   * 프로젝트에 상대적인 파일 경로로 작업을 할 때 Gradle은 ''rootProject.file()'' 로 쉽게 구성 가능하다.(특히 Eclipse linkedResources 적용할 때)   * 프로젝트에 상대적인 파일 경로로 작업을 할 때 Gradle은 ''rootProject.file()'' 로 쉽게 구성 가능하다.(특히 Eclipse linkedResources 적용할 때)
   * Maven은 자신만의 플러그인을 만들기가 힘들다. 하지만 Gradle은 ''build.gradle'' 혹은 ''buildSrc''를 통해 자신만의 플러그인과 태스크를 매우 쉽게 정의할 수 있다.   * Maven은 자신만의 플러그인을 만들기가 힘들다. 하지만 Gradle은 ''build.gradle'' 혹은 ''buildSrc''를 통해 자신만의 플러그인과 태스크를 매우 쉽게 정의할 수 있다.
줄 16: 줄 16:
 ===== 현재(1.2) Gradle의 문제점 ===== ===== 현재(1.2) Gradle의 문제점 =====
   * 의존성에서 ''provided''를 기본으로 제공하지 않고 있다. 하지만 방법은 있다. ''configurations''를 직접 구성해야한다.   * 의존성에서 ''provided''를 기본으로 제공하지 않고 있다. 하지만 방법은 있다. ''configurations''를 직접 구성해야한다.
 +  * Maven보다 프로젝트 컴파일/ 빌드 속도가 느리다.
 +  * 이행적 의존성 충돌이 발생할 때 모르는 사이에 지정한 것보다 높은 버전의 라이브러리를 받아오는 현상이 생긴다. 이것은 문제라기 보다는 Gradle의 의도인데 이것을 이해하지 못하면 의도치 않은 일이 생길 수 있다. [[gradle:dependencies|Gradle Dependencies]] 에서 의존성 충돌에 관해 잘 참고할 것.
   * IDE 지원이 다소 미흡함. 그러나 Eclipse는 대부분 문제가 해결 가능하다.   * IDE 지원이 다소 미흡함. 그러나 Eclipse는 대부분 문제가 해결 가능하다.
  
줄 36: 줄 38:
  
 ===== provided ===== ===== provided =====
-기본적으로 Gradle은 provided를 제공하지 않고 있다. 하지만 [[gradle:web|Gradle Web(War) Plugin]] 프로젝트는 ''providedCompile''을 지원하고 있으며, 웹이 아니더라도 유사 기능을 흉내낼 수 있다.+기본적으로 Gradle은 provided를 제공하지 않고 있다. 하지만 [[gradle:web|Gradle Web(War) Plugin]] 프로젝트는 ''providedCompile''을 지원하고 있으며, 유사 기능을 흉내낼 수 있다.
  
 [[http://wiki.kwonnam.pe.kr/gradle/dependencies#provided|Gradle Dependencies - provided]] 참조. [[http://wiki.kwonnam.pe.kr/gradle/dependencies#provided|Gradle Dependencies - provided]] 참조.
 +
 +===== 이행적 의존성으로 인한 라이브러리 버전 변경 대비 =====
 +현재 프로젝트에서 [[http://www.springsource.org/spring-data/jpa|spring-data-jpa]]를 사용하는데, 이 모듈이 Spring Core/Beans 등에 대해 가변 버전으로 의존하고 있다. 이에 따라 현재 프로젝트의 공식 Spring 버전은 3.1인데, 이행성과 가변 버전 변경에 따라 Core/Beans 등이 3.2.0.M2로 지정되는 현상이 발생하였다.
 +
 +[[gradle:dependencies|Gradle Dependencies]]를 참고하여 의존성 버전 관리 전략에 ''failOnVersionConflict()''을 넣어 주고 항상 명시하는 것이 좋아보인다.
 +
 +===== Profile 흉내내기 =====
 +  * ''-Pprofile=값'' 형태의 옵션으로 Maven의 Profile을 흉내낼 수 있다.<code groovy>
 +final String DEFAULT_PROFILE = 'development'
 +allprojects {
 +    if (!project.hasProperty('profile') || !profile) {
 +        ext.profile = DEFAULT_PROFILE
 +    }
 +
 +    // 리소스에 각 프로필별 리소스 디렉토리 추가
 +    sourceSets {
 +        main {
 +            resources {
 +                srcDir "src/main/resources-${profile}"
 +            }
 +        }
 +    }
 +}
 +</code>
 +  * 이제 ''gradle -Pprofile=production''형태로 호출하면 모든 프로젝트에서 ''profile'' 속성에 ''production''이라는 값이 지정된 상태가 된다. 이에 따라 가변적인 행동을 정의해 준다.
 +  * ''-Pprofile''을 생략하면 기본인 ''DEFAULT_PROFILE'' 상수의 값 ''development''로 작동하게 된다.
  
 ===== Apache CXF ===== ===== Apache CXF =====
gradle/from_maven.1349939953.txt.gz · 마지막으로 수정됨: 2012/10/11 16:19 저자 kwon37xi