gradle의 종속성 관리에 대한 합의

Question

다중 모듈 프로젝트에서 처음으로 Gradle을 사용하고 있으며 그러한 노력을 위해 종속성 관리를 수행하는 데 올바른/최선의 방법이 있는지 궁금해하고있었습니다. 내가 알 수있는 것에서는 두 가지 접근 방법이 있으며이 첫 번째 방법이 더 널리 받아 들여진 것처럼 보입니다. 다음과 같이 보일 것입니다 : [이 프로젝트가 불충분하다면 죄송합니다! ]

-- MyProject 
---- settings.gradle 
---- build.gradle 
---- coreProject 
---- servicesProject 
------ servicesSubProject 
---- warProject 
---- common 

모든 관리가 하나의 build.gradle 파일에서 수행되는이 방법에 따라 '(다른 외부 .gradle 파일은 다양한 유물을 정의하는 데 사용할 수 있음), 개별 프로젝트 종속성은 해당 관리 할 것 같은 프로젝트 '정의 섹션 뭔가 :

project('servicesProject:servicesSubProject') { 
    dependencies { 
     compile project(':common') 
     compile spring.data 
     compile spring.framework.persistence 
     compile spring.framework.security 
     compile persistence.hibernate.core 
     compile persistence.postgresql 
    } 
} 

대안은 (하위 프로젝트에 대한 의존성이 해당 프로젝트의 build.gradle 파일의 종속 섹션에 여기에) 이런 각각의 하위 프로젝트에 대한 build.gradle 파일을 가지고하는 것입니다

-- MyProject 
---- settings.gradle 
---- build.gradle 
---- coreProject 
------ build.gradle 
---- servicesProject 
------ build.gradle 
------ servicesSubProject 
-------- build.gradle 
---- warProject 
------ build.gradle 
---- common 
------ build.gradle 

제가 말했듯이 제가 읽을 수 있었던 것에서는 첫 번째 접근법이 두 번째 접근법보다 더 널리 사용 된 것처럼 보입니다. Spring Framework의 gradle 파일은 이런 방식으로 설정됩니다. 그러나, 내가 충분히 풀러 가기 전에, 나는 또한 알고 있어야하는 상반 관계 또는 다른 영향이 있는지를 물어야한다고 생각했다. 어떤 생각을 해줘서 고마워!

Answer 1

저는 현재 ~ 30 개의 gradle 서브 프로젝트로 자바 프로젝트를 만들고 있습니다. 지금 우리는 두 대안의 편리한 (적어도 우리를 위해) 혼합물을 사용

/(root) 
- build.gradle 
- subproject_1 
- subproject_2 
- webservices 
-- build.gradle 
-- webservice 1 
-- webservice 2 
- database 
- build.gradle 
-- db-binding1 
-- db-binding2 

우리는이 메이븐 저장소, 플러그인, 인코딩 등과 같은 모든 일반적인 일을 정의하는 우리의 루트 프로젝트에서 하나 build.gradle. 또한이 파일에는 모든 서브 프로젝트의 모든 정보를 포함하는 compile 및 runtime 종속성이 포함되어 있습니다. 우리는 하나의 파일에 모든 외부 라이브러리를 정의하려는 생각을 좋아합니다.

우리의 하위 프로젝트는 기술 주제별로 그룹화되어 있기 때문에 하위 프로젝트에만 해당하는 작업과 구성을 정의하는 '내부'파일이 있습니다. 예를 들어 웹 서비스 바인딩, 데이터베이스 바인딩 등을위한 작업을 정의하는 하나의 build.gradle이 있습니다.

귀하의 임금은 다를 수 있습니다. 프로젝트 규모가 클 경우 서브 프로젝트 당 build.gradle을 원할 수 있습니다.

그러나 너무 많은 노력이나 습관없이 쉽게 파일을 분리/결합 할 수 있습니다.

Answer 2

각 하위 프로젝트마다 별도의 빌드 스크립트를 사용하는 것이 더 일반적입니다. 하나의 큰 스크립트를 여러 개의 작은 스크립트로 나누는 것이 일반적으로 좋은 방법입니다. 즉, 일부 팀은 단일 빌드 스크립트를 선호하며 Gradle은이를 수용 할만큼 유연합니다.

여러 빌드 스크립트를 사용하는 경우 해당 스크립트가 속한 하위 프로젝트의 이름을 지정하면됩니다. 이것은 (코드가 하위 프로젝트의 한 단계가 있다고 가정) settings.gradle에 다음 코드를 추가함으로써 달성 될 수있다 :

rootProject.children.each { it.buildFileName = it.name + ".gradle" } 

PS : 의존성 선언이 종종 하위 프로젝트의 빌드 스크립트의 많은 부분을 형성에도 불구하고, 하나 또는 여러 개의 빌드 스크립트를 사용할지 여부는 종속성 관리에만 해당되는 것은 아닙니다.