사용자 도구

사이트 도구


gradle:from_maven

차이

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

차이 보기로 링크

양쪽 이전 판 이전 판
다음 판
이전 판
gradle:from_maven [2012/10/11 15:06]
kwon37xi
gradle:from_maven [2014/06/20 01:18] (현재)
kwon37xi [Gradle이 Maven보다 좋았던 점]
줄 4: 줄 4:
   * 프로젝트 구성과 빌드는 근본적으로 "구성"이라는 정적인 요소와 "빌드"라는 동적인 요소의 집합이다. 이를 Maven은 정적인 데이터를 저장하는 XML로 만들어서 동적인 행위 정의를 매우 어렵게 만들었다.   * 프로젝트 구성과 빌드는 근본적으로 "구성"이라는 정적인 요소와 "빌드"라는 동적인 요소의 집합이다. 이를 Maven은 정적인 데이터를 저장하는 XML로 만들어서 동적인 행위 정의를 매우 어렵게 만들었다.
     * Maven의 가장 큰 문제이며 이로인한 복잡한 프로젝트에서 설정이 거의 불가능한 상황이 자주 발생한다.     * Maven의 가장 큰 문제이며 이로인한 복잡한 프로젝트에서 설정이 거의 불가능한 상황이 자주 발생한다.
-  * Gradle은 DSL로 설정 정보를 구성하고, 그 자체가 Groovy 스크립트 언어이므로 동적인 작업은 그냥 Groovy 코드로 즉석에서 작성하면 된다.+    * Gradle은 DSL로 설정 정보를 구성하고, 그 자체가 Groovy 스크립트 언어이므로 동적인 작업은 그냥 Groovy 코드로 즉석에서 작성하면 된다.
   * 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 =====
줄 52: 줄 80:
  
 ===== projectA의 단위테스트가 projectB의 단위테스트에 의존 ===== ===== projectA의 단위테스트가 projectB의 단위테스트에 의존 =====
-projectA의 단위테스트가 projectB의 단위테스트에 의존하는 경우가 있다. 원칙적으로는 이러면 안된다. projectA와 B간의 의존관계는 메인 자바 소스에 대한 것이어야지 테스트에 대한 것이면 안된다. 하지만 해결은 가능하다.+projectA의 단위테스트가 projectB의 단위테스트에 의존하는 경우가 있다. 원칙적으로는 이러면 안된다. 근본적으로 projectA와 B간의 의존관계는 메인 자바 소스에 대한 것이어야지 테스트에 대한 것이면 안된다. 하지만 어쨌든 이런 상태로 컴파일과 실행이 가능하게 만들 수는 있다.
  
 [[http://wiki.kwonnam.pe.kr/gradle/multiproject?s[]=sourcesets&s[]=test&s[]=output#%EB%8B%A8%EC%9C%84_%ED%85%8C%EC%8A%A4%ED%8A%B8%EA%B0%84%EC%9D%98_%EC%9D%98%EC%A1%B4%EC%84%B1|Multi Project 단위 테스트간의 의존성 참조]] [[http://wiki.kwonnam.pe.kr/gradle/multiproject?s[]=sourcesets&s[]=test&s[]=output#%EB%8B%A8%EC%9C%84_%ED%85%8C%EC%8A%A4%ED%8A%B8%EA%B0%84%EC%9D%98_%EC%9D%98%EC%A1%B4%EC%84%B1|Multi Project 단위 테스트간의 의존성 참조]]
gradle/from_maven.1349935604.txt.gz · 마지막으로 수정됨: 2012/10/11 15:06 저자 kwon37xi