Gradle

sourceCompatibility

targetCompatibility

이 값들을 1.5로 지정한다고해서 항상 jdk 1.5로 코드를 컴파일 할 수 있고, jdk 1.5에서 작동할 것으로 예상할 수 있는 것이 아니다. 사용 가능한 라이브러리라는 것.

https://stackoverflow.com/questions/16654951/gradle-sourcecompatibility-vs-targetcompatibility

하위 프로젝트 간에 빌드 로직을 공유하는 방법으로 subproject {}, allprojects {} DSL을 통한 구성

이 방식을 사용하면 하위 프로젝트에 빌드 로직을 주입할 수 있는데, 이는 하위 프로젝트에서 보기에 명확하지 않아 로직을 이해하기 어렵게 만듦.

장기적으로 이 구성방법은 점점 더 많은 조건부 논리와 높은 유지보수 부담으로 복잡해짐

설정 시점에 프로젝트 간에 커플링이 생기기 때문에 configuration-on-demand와 같은 최적화가 제대로 작동하지 않는다.

이를 해결하기 위해 특정 타입의 하위 프로젝트에 플러그인 또는 설정을 적용

현재 프로젝트에 플러그인의 적용 여부를 지정, 설정하지 않으면 프로젝트의 classpath에만 설정.

default: true

플러그인의 클래스를 재사용하거나 하위 프로젝트에 적용할 때 유용함

plugins {
   id "org.company.myplugin" version "1.0" apply false
}

subprojects {
   if (someCondition) {
       apply plugin: "org.company.myplugin"
   }
}

compileJava - java 소스 컴파일

processResources - 프로덕션 리소스를 프로덕션 리소스 디렉토리로 복사

classes -

compileTestJava - 테스트 소스 코드 컴파일

processTestResources

testClasses

jar - main 소스셋에 있는 클래스, 리소스를 기반으로 프로덕션 jar 파일 생성

javadoc - Javadoc을 이용하여 프로덕션 java 소스의 API 문서 생성

test - JUnit or TestNG 유닛 테스트 실행

clean - 프로젝트 빌드 디렉토리 삭제

cleanTaskName - 각 태스트에서 생성된 파일 제거. cleanJar, cleanTest, …​

compileSourceSetJava

processSourceSetResources

sourceSetClasses

assemble - 모든 아카이브를 취합하는 집계 작업

check - 테스트 같은 확인 작업을 수행하는 집계 작업

build - 프로젝트듸 전체 빌드 작업을 수행하는 집계 작업

buildNeeded

buildDepencents

buildConfigName

uploadConfigName

java plugin과 java library plugin의 주요 차이점은 java libaray plugin는 consumer에게 노출되는 api 개념을 도입한다는 것

assembleRelease: .apk 파일 만들어주는 android 태스크

https://scans.gradle.com/#gradle

--scan 옵션을 추가하면 결과를 웹 UI로 볼 수 있음

다만, gradle에 결과를 전송해서 보는 방식