블로그
기술 자료, 기술 팁
Gradle의 compile vs compileOnly vs compileInclude 비교
Gradle의 compile vs compileOnly vs compileInclude의 비교를 설명합니다.
종속성 관리 설정 비교
안녕하세요, 일본 라이프 레이 서포터 빌리티 엔지니어의 다케오입니다.
이번에는 Gradle의 컴파일, 컴파일 전용, 컴파일 포함의 차이점을 설명하는 기사를 소개합니다.
※본 기사는 Liferay Community Blog에 투고된 " Gradle: compile vs compileOnly vs compileInclude "를 번역한 것입니다. 출처 또는 저자의 허가를 받아 배달합니다.
※오리지날의 영국 기사 저자: David H Nebinger씨 는 사우스캐롤라이나주의 서머빌에 사는 Liferay, Inc.의 Software Architect/리드 컨설턴트입니다. 그는 Liferay Community 사이트에서 많은 기술 정보를 게시하는 등 정력적으로 활동하고 있습니다.
이번에는 자주 묻는 질문, compile, compileOnly 및 compileInclude 비교에 대해 설명하는 기사를 작성하고 싶습니다.
우선, 지금부터 소개하는 것은 실제로 빌드 프로세스중에 사용되는 다양한 설정의 이름입니다만, 의존관계 관리에 있어서, 이 이름을 확실히 인식해 두는 것이 중요합니다. Maven에서 이들은 범위로 구현됩니다.
이 세 가지 유형 중 하나가 dependencies{} 섹션에 나열될 때마다 식별된 종속성을 구성에 추가합니다.
Java 코드가 바이트 코드로 컴파일되는 경우 세 가지 설정은 모두 빌드의 컴파일 단계에서 종속성을 추가합니다.
이러한 설정의 실제 차이점은 빌드시 jar 매니페스트에 있습니다.
compile
compile 은 가장 이해하기 쉬운 것입니다. Java 코드가 깨끗하게 컴파일되어야 한다는 종속성을 선언합니다.
모범 사례로 코드를 컴파일하는 데 필요한 라이브러리에 대한 컴파일 종속성만 나열합니다. 예를 들어 Excel 스프레드시트 group: 'org.apache.poi'、name: 'poi-ooxml'、version: '4.0.0' 필요하지만 http로 스핀아웃하지 않도록 할 수 있습니다. http://mvnrepository.com/artifact/org.apache.poi/poi-ooxml/4.0.0 을 클릭한 다음 POI에 필요한 모든 것에 대해 컴파일 종속성을 선언합니다. 전이적 종속성으로 Gradle은 당신을 대신하여 처리합니다.
컴파일이 발생하면 이 종속성은 javac가 Java 소스 파일을 컴파일하기 위한 클래스 경로에 포함됩니다.
또한 jar를 빌드할 때 POI에서 Java 코드에서 사용하는 패키지가 Import-Package 매니페스트 항목으로 추가됩니다.
OSGi 컨테이너의 다른 모듈에서 사용할 수 없는 경우 누락된 패키지에 대해 "해결된 참조" 오류가 발생합니다.
Maven 사용자를 위한 보충으로 컴파일 설정은 Maven의 컴파일 범위와 동일합니다.
compileOnly
compileOnly 설정은 위의 compile과 마찬가지로 코드를 컴파일하는 데 필요한 종속성을 글머리 기호로 만드는 데 사용됩니다.
차이점은 compileOnly 종속성에서 Java 코드가 사용하는 패키지가 Import-Package 매니페스트 항목으로 표시되지 않는다는 것입니다.
compileOnly를 사용하는 일반적인 예는 일반적으로 주석 사용과 관련된 문제를 해결하는 것입니다. 나는 FindBugs를 사용하는 것을 좋아합니다. 그러나 때로는 FindBugs가 잘못된 결과를 표시하는 FindBugs 자체의 버그라고 생각할 수도 있지만, 자신이 생각했던 대로 감지해주고 있다는 것을 기억합니다.
그러므로 여기에서 일반적인 해결책은 메소드에 @SuppressFBWarninsg 어노테이션을 추가하는 것입니다. 아래 내가 최근에 사용한 것입니다 :
@SuppressFBWarnings(value = "NP_NULL_PARAM_DEREF", justification = "Code allocates always before call.") public void emit(K key) { ... }
FindBugs는 내가 key의 null을 확인하지 않았다고 지적했지만 실제로는 Map 항목을 처리하는 동안 발생하기 때문에 key가 null이 될 수는 없습니다. 널 체크를 추가하는 대신 주석을 추가했습니다.
주석을 사용하려면 물론 종속성을 포함해야 합니다.
compileOnly 'com.google.code.findbugs:annotations:3.0.0'
컴파일 자체의 주석 만 필요하기 때문에 이번에는 compileOnly를 사용했습니다. 런타임 어노테이션이 아니기 때문에 컴파일러는 바이트 코드에서 어노테이션 정보를 제거합니다. 컴파일이 끝난 후에는 이 종속성이 필요하지 않습니다.
그리고 Import-Package 매니페스트 항목에 결코 나타나지 않기를 원합니다.
OSGi에서는 org.osgi.core와 osgi.cmpn 종속성에 compileOnly를 사용하는 경향이 있습니다. 런타임에 패키지가 필요하지 않기 때문에 OSGi 컨테이너 내에서 이러한 패키지가 항상 제공되기 때문입니다. (그러므로 매니페스트는 그것을 강제 할 필요가 없습니다.) 또한 OSGi 컨테이너 외부에서 jar 파일을 사용할 수도 있습니다.
Maven 사용자를 위한 보충으로 compileOnly 설정은 Maven에서 제공하는 범위와 유사합니다.
compileInclude
그리고 마지막으로 compileInclude 입니다. compile 및 compileOnly 와 같이 이 설정은 컴파일 클래스 경로에 종속성을 포함합니다.
compileInclude 설정은 실제로 Liferay에 의해 도입되며 Liferay의 Gradle 플러그인에 포함되어 있습니다.
compileInclude 설정은 내 OSGi Depencencies 블로그 게시물, 옵션 #4(번들에 있는 jar 포함)의 수동 단계를 대체합니다.
사실 내 블로그에서 Bundle-ClassPath 과 -includeresource 명령을 bnd.bnd 파일에 추가하여 설명하는 모든 내용은이 compileInclude 에서도 가능합니다. 그러나 compileInclude 더 좋은 점은 다른 전이적인 종속성도 모듈에 포함된다는 것입니다.
몇 가지 전이적인 종속성이 포함되어 있다고 내가 언급 한 것에 유의하십시오. 어떤 전이적인 종속성을 포함할 것인지를 결정하는 방법에 대해서는 완전히 알 수 없지만 항상 100% 옳은 것은 아닙니다. 나는 특정 전이적인 종속성을 놓쳤을 수 있었다. 다른 종속성을 포함하지 않는다는 것을 알고 있었기 때문에 추이적 종속성이 원인 일 수 있습니다. 이러한 상황을 수정하려면 누락 된 전이 종속성에 compileInclude 설정 행을 추가하는 것만으로 충분합니다.
선언 끝에 플래그를 추가하여 전이적 종속성 포함을 비활성화할 수 있습니다. 예를 들어 poi-ooxml 만 원하지만 어떤 이유로 다른 동적 종속성을 원하지 않는 경우 다음과 같이 사용할 수 있습니다.
compileInclude group: 'org.apache.poi', name: 'poi-ooxml', version: '4.0.0', transitive:false
전이적인 종속성을 포함할지 아니면 제외할지는 구현자에 따라 다르지만 적어도 bnd.bnd 파일을 수동으로 업데이트할 필요가 없습니다.
compileInclude 대체로 잘 작동하지만 악영향을 미칠 수 있다는 인상을 가지고 있다면 옳을 것입니다. Bundle-ClassPath 와 -includeresource 사용하면 모든 것이 정확하게 제어 될 수 없다. 우연히 작업이 적게 끝나고 있을 뿐입니다.
다만, Maven을 사용하고 있는 분은, 유감입니다만, 본건에 대응하는 Maven 스코프는 없습니다. . .
요약
본 기사에서 소개한 3가지 설정으로 발생할 수 있는 다양한 혼란이 조금이라도 해결되면 기쁘게 생각합니다.
어떤 구성을 사용할 때 권장 사항이 필요한 경우 다음을 수행합니다.
OSGi 컨테이너에서 사용할 수 있는 것으로 알려진 패키지의 경우 컴파일 구성을 사용합니다. 여기에는 다른 모듈의 맞춤 코드가 포함됩니다. (모든 com.liferay 코드 등)
OSGi 컨테이너에서 필요하지 않거나 OSGi 컨테이너에서 제공한다고 가정하지 않는 패키지의 경우 compileInclude 설정을 사용하십시오. 이것은 기본적으로 모듈로 컨테이너에 푸시하지 않는 타사 라이브러리 모두입니다.
다른 모든 경우 compileOnly 구성을 사용하십시오.
본 기사는 이상입니다.
어땠습니까?
기사에 관한 의견, 감상 등이 있으시면 부담없이 yasuyuki.takeo@liferay.com 으로 연락 주시기 바랍니다.
■ 지금까지 발신해 온 일본어에 의한 기술 컨텐츠를 Qiita에서 읽을 수 있습니다. 원한다면 그 쪽의 기사도 함께 도움을 주시기 바랍니다.
→ https://qiita.com/yasuflatland-lf
■ Doorkeeper의 라이프레이 커뮤니티 멤버 대환영!
기업 블로그의 기술 콘텐츠 업데이트 정보 등 정기적으로 참가하고 있습니다.
→ https://liferay.doorkeeper.jp/
Placeholder
기술 자료, 기술 팁
Placeholder
고객 경험
Placeholder
고객 경험