- 플러그인의 기능(What plugins do)
- 플러그인 타입(Types of plugins)
- 플러그인 사용(Using plugins)
- 바이너리 플러그인(Binary plugins)
- 스크립트 플러그인(Script plugins)
- 커뮤니티 플러그인 찾기(Finding community plugins)
- 플러그인에 대한 추가 정보(More on plugins)
그레이들 플러그인 사용(Using Gradle Plugins)
그레이들 코어는 의도적으로 실제 자동화를 거의 제공하지 않는다. 자바 코드 컴파일 기능과 같은 유용한 기능은 모두 플러그인에 의해 추가된다. 플러그인은 새로운 태스크(예: JavaCompile), 도메인 객체(예: SourceSet), 컨벤션(예: Java 소스는 src/main/java에 있음)을 추가할 뿐만 아니라 코어 객체와 다른 플러그인의 객체를 확장한다.
이 장에서는 플러그인을 사용하는 방법과 플러그인을 둘러싼 용어 및 개념을 설명한다.
플러그인의 기능(What plugins do)
프로젝트에 플러그인을 적용하면 플러그인이 프로젝트의 기능을 확장할 수 있다. 다음과 같은 작업을 수행할 수 있다.
- 그레이들 모델 익스텐션(예: 구성할 수 있는 새 DSL 요소 추가)
- 컨벤션에 따라 프로젝트를 구성한다(예: 새 태스크 추가 또는 합리적인 기본값 구성).
- 특정 구성 적용(예: 조직 리포지터리 추가 또는 표준 시행)
프로젝트 빌드 스크립트에 로직을 추가하는 대신 플러그인을 적용하면 다양한 이점을 얻을 수 있다. 플러그인 적용.
- 재사용을 촉진하고 여러 프로젝트에서 유사한 논리를 유지 관리하는 오버헤드를 줄인다.
- 더 높은 레벨의 모듈화를 허용하여 이해력과 구성을 향상시킨다.
- 명령형 논리를 캡슐화하고 빌드 스크립트를 최대한 선언적으로 만들 수 있다.
플러그인 타입(Types of plugins)
그레이들에는 바이너리 플러그인과 스크립트 플러그인 두 가지 타입의 플러그인이 있다. 바이너리 플러그인은 플러그인 인터페이스를 구현하여 프로그래밍 방식으로 작성되거나 그레이들의 DSL 언어 중 하나를 사용하여 선언적으로 작성된다. 바이너리 플러그인은 빌드 스크립트 내부, 프로젝트 계층 구조 내부 또는 플러그인 jar 외부에 있을 수 있다. 스크립트 플러그인은 선언적 방식으로 구현하는 추가 빌드 스크립트다. 외부 원격 위치에서 접근할 수 있지만 일반적으로 빌드 내에서 사용된다.
작성하기 쉽기 때문에 스크립트 플러그인으로 시작하는 경우가 많으며, 코드의 가치가 높아짐에 따라 쉽게 테스트하고 여러 프로젝트 또는 조직 간에 공유할 수 있는 바이너리 플러그인으로 마이그레이션된다.
플러그인 사용(Using plugins)
플러그인에 캡슐화된 빌드 로직을 사용하려면 그레이들은 두 단계를 수행해야 한다. 먼저 플러그인을 분석(resolve)한 다음 대상(일반적으로 프로젝트)에 플러그인을 적용해야 한다.
플러그인을 분석한다(resolve)는 것은 주어진 플러그인을 포함하는 올바른 jar 버전을 찾아서 이를 스크립트 클래스패스에 추가하는 것을 의미한다. 플러그인이 분석되면 해당 API를 빌드 스크립트에서 사용할 수 있다. 스크립트 플러그인 적용 시 제공된 특정 파일의 위치나 URL에서 분석된다는 점에서 자체 해결이다. 그레이들 배포의 일부로 제공되는 코어 바이너리 플러그인은 자동으로 분석된다.
플러그인을 적용한다는 것은 플러그인으로 개선시키려는 프로젝트 플러그인의 Plugin.apply(T)를 실제로 실행하는 것을 의미한다. 플러그인 적용은 멱등적이다. 즉, 부수효과 없이 모든 플러그인을 여러 번 적용할 수 있다.
플러그인을 사용하는 가장 일반적인 사례는 플러그인을 분석하고 이를 현재 프로젝트에 적용하는 것이다. 이는 매우 일반적인 사례이므로 빌드 작성자는 플러그인 DSL을 사용하여 한 단계로 플러그인을 분석하고 적용하는 것이 좋다.
바이너리 플러그인(Binary plugins)
전역 고유 식별자인 플러그인 id 또는 플러그인명을 기준으로 플러그인을 적용한다. 코어 그레이들 플러그인은 코어 JavaPlugin의 'java'와 같은 짧은 이름을 제공한다는 점에서 특별하다. 다른 모든 바이너리 플러그인은 플러그인 ID의 정규화된 형식(예: com.github.foo.bar)을 사용해야 하지만 일부 레거시 플러그인은 여전히 짧고 정규화되지 않은 형식을 사용할 수 있다. 플러그인 ID를 입력하는 위치는 플러그인 DSL을 사용하는지 아니면 buildscript 블록을 사용하는지에 따라 다르다.
바이너리 플러그인 위치(Locations of binary plugins)
플러그인은 단순하게 플러그인 인터페이스를 구현하는 모든 클래스다. 그레이들은 배포의 일부로 코어 플러그인(예: JavaPlugin)을 제공하므로 자동분석 된다. 그러나 코어가 아닌 바이너리 플러그인을 적용하려면 먼저 분석해야 한다. 이는 여러 가지 방법으로 달성할 수 있다.
- 플러그인 DSL을 사용하여 플러그인 포털 또는 커스텀 리포지터리의 플러그인을 포함(플러그인 DSL을 사용하여 플러그인 적용 참고).
- 빌드스크립트 의존성으로 정의된 외부 jar의 플러그인 포함(빌드스크립트 블록을 사용하여 플러그인 적용 참고)
- 프로젝트의
buildSrc디렉토리 아래 소스 파일로 플러그인을 정의(buildSrc를 사용하여 기능적 로직 추출 참고). - 빌드 스크립트 내에서 인라인 클래스 선언으로 플러그인을 정의.
자신만의 플러그인을 정의하는 방법에 대한 자세한 내용은 커스텀 플러그인을 참고하자.
플러그인 DSL을 사용하여 플러그인 적용(Applying plugins with the plugins DSL)
플러그인 DSL은 플러그인 의존성을 선언하는 간결하고 편리한 방법을 제공한다. 그레이들 플러그인 포털과 함께 작동하여 코어 플러그인과 커뮤니티 플러그인 모두에 쉽게 접근할 수 있다. 플러그인 DSL 블록은 플러그인디펜던시스펙(PluginDependencySpec)의 인스턴스를 구성한다.
코어 플러그인을 적용하면, 짧은 이름을 사용할 수 있다.
예제 1. 코어 플러그인 적용
build.gradle
plugins {
id 'java'
}
build.gradle.kts
plugins {
java
}
포털에서 커뮤니티 플러그인을 적용하려면, 정규화된 플러그인 ID를 사용해야 한다.
예제 2. 커뮤니티 플러그인 적용
build.gradle
plugins {
id 'com.jfrog.bintray' version '1.8.5'
}
build.gradle.kts
plugins {
id("com.jfrog.bintray") version "1.8.5"
}
플러그인 DSL 사용에 대한 자세한 내용은 플러그인디펜던시스펙(PluginDependencySpec)을 참고하자
플러그인 DSL의 제한 사항(Limitations of the plugins DSL)
프로젝트에 플러그인을 추가하는 이 방법은 더 편리한 문법 그 이상이다. 플러그인 DSL은 그레이들이 사용 중인 플러그인을 매우 초기에 매우 빠른 방식으로 처리한다. 이를 통해 그레이들은 다음과 같은 스마트한 작업을 수행할 수 있다.
- 플러그인 클래스의 로딩 및 재사용을 최적화한다.
- 편집 지원을 위해 빌드 스크립트의 잠재적 프로퍼티스 및 값에 대한 자세한 정보를 편집자에게 제공한다.
이를 위해서는 나머지 빌드 스크립트를 실행하기 전에 그레이들이 쉽고 빠르게 추출할 수 있는 방식으로 플러그인을 지정해야 한다. 또한 사용할 플러그인의 정의가 다소 정적이어야 한다.
plugins {} 블록 메커니즘과 “전통적인” apply() 메서드 메커니즘 사이에는 몇 가지 주요 차이점이 있다. 또한 몇 가지 제약 사항이 있는데, 그 중 일부는 메커니즘이 아직 개발되는 동안 일시적인 제한 사항이고 일부는 새로운 접근 방식에 내재되어 있다.
제한된 문법(Constrained Syntax)
plugins {} 블록은 임의 코드를 지원하지 않는다. 멱등성(매번 동일한 결과 생성) 및 부작용 방지(언제든지 그레이들 실행이 안전함)를 위해 제한된다.
형식은 다음과 같다.
build.gradle
plugins {
id «plugin id» //................................................ 1.
id «plugin id» version «plugin version» [apply «false»] //....... 2.
}
- 코어 그레이들 플러그인 또는 빌드 스크립트에 이미 사용 가능한 플러그인.
- 분석해야 하는 바이너리 그레이들 플러그인.
build.gradle.kts
plugins {
`«plugin id»` //................................................ 1.
id(«plugin id») //.............................................. 2.
id(«plugin id») version «plugin version» [apply «false»] //..... 3.
}
- 코어 그레이들 플러그인
- 코어 그레이들 플러그인 또는 빌드 스크립트에 이미 사용 가능한 플러그인.
- 분석해야 하는 바이너리 그레이들 플러그인.
사례 #1에서 «plugin id»는 코어 플러그인 ID의 이름을 딴 정적 코틀린 확장 프로퍼티다. 그리고 사례 #2와 #3은 문자열이다. «plugin version»도 문자열이다. 불이 포함된 apply 문을 사용하면 플러그인을 즉시 적용하는 기본 동작을 비활성화할 수 있다(예: 하위 프로젝트(subprojects)에만 적용하려는 경우).
변수를 사용하여 플러그인 버전을 정의하려면 플러그인 버전 관리를 참고하자.
plugins {} 블록은 빌드 스크립트의 최상위 명령문이어야 한다. 다른 문법(예: if 문 또는 for 루프) 내에 중첩될 수 없다.
빌드 스크립트 및 세팅 파일에서만 사용할 수 있다.(Can only be used in build scripts and settings file)
plugins {} 블록은 현재 프로젝트의 빌드 스크립트와 settings.gradle 파일에서만 사용할 수 있다. 스크립트 플러그인이나 init 스크립트에서는 사용할 수 없다.
그레이들의 향후 버전에서는 이 제한이 제거된다.
plugins {} 블록의 제한이 너무 높을 경우 권장되는 접근 방식은 buildscript {} 블록을 사용하여 플러그인을 적용하는 것이다.
하위 프로젝트에 동일한 버전의 외부 플러그인 적용(Applying external plugins with same version to subprojects)
다중 프로젝트 빌드가 있는 경우 루트 프로젝트가 아닌 빌드의 일부 또는 전체 하위 프로젝트(subprojects)에 플러그인을 적용하고 싶을 수도 있다. plugins {} 블록의 기본 동작은 플러그인을 즉시 해결하고 적용하는 것이다. 그러나 apply false 문법을 사용하여 그레이들에 현재 프로젝트 플러그인을 적용하지 않도록 지시한 다음 하위 프로젝트의 빌드 스크립트에서 버전 없이 plugins {} 블록을 사용할 수 있다.
예제 3.특정 하위 프로젝트에만 플러그인 적용
settings.gradle
include 'hello-a'
include 'hello-b'
include 'goodbye-c'
build.gradle
plugins {
id 'com.example.hello' version '1.0.0' apply false
id 'com.example.goodbye' version '1.0.0' apply false
}
hello-a/build.gradle
plugins {
id 'com.example.hello'
}
hello-b/build.gradle
plugins {
id 'com.example.hello'
}
goodbye-c/build.gradle
plugins {
id 'com.example.goodbye'
}
settings.gradle.kts
include("hello-a")
include("hello-b")
include("goodbye-c")
build.gradle.kts
plugins {
id("com.example.hello") version "1.0.0" apply false
id("com.example.goodbye") version "1.0.0" apply false
}
hello-a/build.gradle.kts
plugins {
id("com.example.hello")
}
hello-b/build.gradle.kts
plugins {
id("com.example.hello")
}
goodbye-c/build.gradle.kts
plugins {
id("com.example.goodbye")
}
더 좋은 점은 자체 컨벤션 플러그인을 사용하여 빌드 로직을 구성하여 외부 플러그인 버전을 캡슐화할 수 있다는 것이다.
buildSrc 디렉토리에서 플러그인 적용(Applying plugins from the buildSrc directory)
정의된 ID가 있는 한 프로젝트의 buildSrc 디렉토리에 있는 플러그인을 적용할 수 있다. 다음 예제에서는 buildSrc에 정의된 플러그인 구현 클래스인 my.MyPlugin을 ID "my-plugin"에 연결하는 방법을 보여준다.
예제 4. ID로 buildSrc 플러그인 정의
buildSrc/build.gradle
plugins {
id 'java-gradle-plugin'
}
gradlePlugin {
plugins {
myPlugins {
id = 'my-plugin'
implementationClass = 'my.MyPlugin'
}
}
}
buildSrc/build.gradle.kts
plugins {
`java-gradle-plugin`
}
gradlePlugin {
plugins {
create("myPlugins") {
id = "my-plugin"
implementationClass = "my.MyPlugin"
}
}
}
그런 다음 플러그인은 정상적으로 ID로 적용할 수 있다.
예제 5. buildSrc에서 플러그인 적용
build.gradle
plugins {
id 'my-plugin'
}
build.gradle.kts
plugins {
id("my-plugin")
}
플러그인 매니지먼트(Plugin Management)
pluginManagement {} 블록은 settings.gradle 파일(파일의 첫 번째 블록이어야 함)이나 초기화(Initialization) 스크립트에만 나타날 수 있다.
예제 6. 프로젝트별 및 전역적으로 pluginManagement 구성
settings.gradle
pluginManagement {
plugins {
}
resolutionStrategy {
}
repositories {
}
}
rootProject.name = 'plugin-management'
init.gradle
settingsEvaluated { settings ->
settings.pluginManagement {
plugins {
}
resolutionStrategy {
}
repositories {
}
}
}
settings.gradle.kts
pluginManagement {
plugins {
}
resolutionStrategy {
}
repositories {
}
}
rootProject.name = "plugin-management"
init.gradle
settingsEvaluated {
pluginManagement {
plugins {
}
resolutionStrategy {
}
repositories {
}
}
}
커스텀 플러그인 리포지터리(Custom Plugin Repositories)
기본적으로 plugins {} DSL은 공개 그레이들 플러그인 포털에서 플러그인을 확인한다. 빌드 작성자들은 플러그인에 구현 세부 정보가 포함되어 있기 때문에, 비공개 메이븐 또는 아이비 리포지터리에서 플러그인을 분석하고 자신의 빌드에 사용할 수 있는 플러그인을 더 잘 제어하기를 원한다.
커스텀 플러그인 리포지터리를 지정하려면 pluginManagement {} 내부의 repositories {} 블록을 사용하자.
예제 7. 커스텀 플러그인 리포지터리의 플러그인 사용.
settings.gradle
pluginManagement {
repositories {
maven {
url './maven-repo'
}
gradlePluginPortal()
ivy {
url './ivy-repo'
}
}
}
settings.gradle.kts
pluginManagement {
repositories {
maven(url = "./maven-repo")
gradlePluginPortal()
ivy(url = "./ivy-repo")
}
}
이는 그레이들에게 플러그인을 분석할 때 먼저 ../maven-repo의 메이븐 리포지터리를 살펴본 다음 메이븐 리포지터리에서 플러그인을 찾을 수 없는 경우 그레이들 플러그인 포털을 확인하도록 지시한다. 그레이들 플러그인 포털을 검색하지 않으려면 gradlePluginPortal() 줄을 생략하자. 마지막으로 ../ivy-repo의 아이비 리포지터리를 확인한다.
플러그인 버전 매니저(Plugin Version Management)
pluginManagement {} 내의 plugins {} 블록을 사용하면 빌드의 모든 플러그인 버전을 단일 위치에서 정의할 수 있다. 그러면 plugins {} 블록을 통해 모든 빌드 스크립트에 ID별로 플러그인을 적용할 수 있다.
이런 방식으로 플러그인 버전을 설정하는 것의 한 가지 이점은 PluginManagement.plugins {}가 빌드 스크립트 plugins {} 블록과 동일한 제한된 문법을 갖지 않는다는 것이다. 이를 통해 플러그인 버전을 gradle.properties에서 가져오거나 다른 메커니즘을 통해 로드할 수 있다.
예제 8. pluginManagement를 통해 플러그인 버전을 관리한다.
settings.gradle
pluginManagement {
plugins {
id 'com.example.hello' version "${helloPluginVersion}"
}
}
build.gradle
plugins {
id 'com.example.hello'
}
gradle.properties
helloPluginVersion=1.0.0
settings.gradle.kts
pluginManagement {
val helloPluginVersion: String by settings
plugins {
id("com.example.hello") version "${helloPluginVersion}"
}
}
build.gradle.kts
plugins {
id("com.example.hello")
}
gradle.properties.kts
helloPluginVersion=1.0.0
플러그인 버전은 gradle.properties에서 로드되고 세팅 스크립트에서 구성되므로 버전을 지정하지 않고도 플러그인을 모든 프로젝트에 추가할 수 있다.
플러그인 분석 규칙(Plugin Resolution Rules)
플러그인 분석 규칙을 사용하면 plugins {} 블록에서 생성된 플러그인 요청을 수정할 수 있다. 요청된 버전을 변경하거나 구현 아티팩트 좌표를 명시적으로 지정한다.
분석 규칙을 추가하려면 pluginManagement {} 블록 내에서 resolutionStrategy {}를 사용하자.
예제 9. 플러그인 분석 전략
settings.gradle
pluginManagement {
resolutionStrategy {
eachPlugin {
if (requested.id.namespace == 'com.example') {
useModule('com.example:sample-plugins:1.0.0')
}
}
}
repositories {
maven {
url './maven-repo'
}
gradlePluginPortal()
ivy {
url './ivy-repo'
}
}
}
settings.gradle.kts
pluginManagement {
resolutionStrategy {
eachPlugin {
if (requested.id.namespace == "com.example") {
useModule("com.example:sample-plugins:1.0.0")
}
}
}
repositories {
maven {
url = uri("./maven-repo")
}
gradlePluginPortal()
ivy {
url = uri("./ivy-repo")
}
}
}
이는 플러그인 ID에서 메이븐/아이비 좌표로의 내장 기본 매핑(default mapping)을 사용하는 대신 지정된 플러그인 구현 아티팩트를 사용하도록 그레이들에 지시한다.
커스텀 메이븐 및 아이비 플러그인 리포지터리에는 실제 플러그인을 구현하는 아티팩트 외에 플러그인 마커 아티팩트가 포함되어야 한다. 커스텀 리포지터리에 플러그인을 게시하는 방법에 대한 자세한 내용은 그레이들 플러그인 개발 플러그인을 참고하자.
pluginManagement {} 블록 사용에 대한 전체 문서는 PluginManagementSpec을 참고하자.
플러그인 마커 아티팩트(Plugin Marker Artifacts)
plugins {} DSL 블록에서는 전역적으로 고유한 플러그인 ID와 버전 프로퍼티로만 플러그인을 선언할 수 있으므로 그레이들에는 플러그인 구현 아티팩트의 좌표를 조회할 수 있는 방법이 필요하다. 이를 위해 그레이들은 좌표가 plugin.id:plugin.id.gradle.plugin:plugin.version인 플러그인 마커 아티팩트를 찾습니다. 이 마커는 실제 플러그인 구현에 대한 의존성을 가져야 한다. 이러한 마커 게시는 java-gradle-plugin에 의해 자동화된다.
예를 들어, 샘플 플러그인 프로젝트의 다음 전체 샘플은 java-gradle-plugin과 maven-publish 플러그인, ivy-publish 플러그인의 조합을 사용하여 com.example.hello 플러그인과 com.example.goodbye 플러그인을 아이비 및 메이븐 리포지터리에 게시하는 방법을 보여준다.
예제 10. 플러그인 게시 샘플
build.gradle
plugins {
id 'java-gradle-plugin'
id 'maven-publish'
id 'ivy-publish'
}
group 'com.example'
version '1.0.0'
gradlePlugin {
plugins {
hello {
id = 'com.example.hello'
implementationClass = 'com.example.hello.HelloPlugin'
}
goodbye {
id = 'com.example.goodbye'
implementationClass = 'com.example.goodbye.GoodbyePlugin'
}
}
}
publishing {
repositories {
maven {
url '../../consuming/maven-repo'
}
ivy {
url '../../consuming/ivy-repo'
}
}
}
build.gradle.kts
plugins {
`java-gradle-plugin`
`maven-publish`
`ivy-publish`
}
group = "com.example"
version = "1.0.0"
gradlePlugin {
plugins {
create("hello") {
id = "com.example.hello"
implementationClass = "com.example.hello.HelloPlugin"
}
create("goodbye") {
id = "com.example.goodbye"
implementationClass = "com.example.goodbye.GoodbyePlugin"
}
}
}
publishing {
repositories {
maven {
url = uri("../../consuming/maven-repo")
}
ivy {
url = uri("../../consuming/ivy-repo")
}
}
}
샘플 디렉토리에서 gradle publish 태스크를 실행하면 다음과 같은 메이브 리포지터리 레이아웃이 생성된다(아이비 레이아웃도 유사함).
레거시 플러그인 애플리케이션(Legacy Plugin Application)
플러그인 DSL의 도입으로 사용자는 기존 플러그인 적용 방법을 사용할 이유가 거의 없다. 현재 작동 방식에 대한 제한으로 인해 빌드 작성자가 플러그인 DSL을 사용할 수 없는 경우에 대비해 여기에 문서화되어 있다.
바이너리 플러그인 적용(Applying Binary Plugins)
예제 11. 바이너리 플러그인 적용
build.gradle
apply plugin: 'java'
build.gradle.kts
apply(plugin = "java")
플러그인 ID를 사용하여 플러그인을 적용할 수 있다. 위의 경우에는 'java'라는 짧은 이름을 사용하여 JavaPlugin을 적용하고 있다.
플러그인 ID를 사용하는 대신 플러그인 클래스를 지정하여 플러그인을 적용할 수도 있다.
예제 12. 타입을 이용한 바이너리 플러그인 적용
build.gradle
apply plugin: JavaPlugin
build.gradle.kts
apply<JavaPlugin>()
위 샘플의 JavaPlugin 심볼은 JavaPlugin을 나타낸다. org.gradle.api.plugins 패키지는 모든 빌드 스크립트에서 자동으로 임포트 해오기 때문에 이 클래스를 명시적으로 임포트해올 필요는 없다(기본 가져오기 참고).
또한, 자바의 .class 대신 코틀린에서 클래스 리터럴을 식별하려면 ::class 접미사를 추가해야 한다.
buildscript 블록을 사용하여 플러그인 적용(Applying plugins with the buildscript block)
외부 jar 파일로 게시된(published) 바이너리 플러그인은 빌드 스크립트 클래스패스에 플러그인을 추가한 후 플러그인을 적용하여 프로젝트에 추가할 수 있다. 빌드 스크립트에 대한 외부 의조성에 설명된 대로 buildscript {} 블록을 사용하여 외부 jar를 빌드 스크립트 클래스패스에 추가할 수 있다.
예제 13. buildscript 블록을 사용하여 플러그인 적용
build.gradle
buildscript {
repositories {
gradlePluginPortal()
}
dependencies {
classpath 'com.jfrog.bintray.gradle:gradle-bintray-plugin:1.8.5'
}
}
apply plugin: 'com.jfrog.bintray'
build.gradle.kts
buildscript {
repositories {
gradlePluginPortal()
}
dependencies {
classpath("com.jfrog.bintray.gradle:gradle-bintray-plugin:1.8.5")
}
}
apply(plugin = "com.jfrog.bintray")
스크립트 플러그인(Script plugins)
예제 14. 스크립트 플러그인 적용
build.gradle
apply from: 'other.gradle'
build.gradle.kts
apply(from = "other.gradle.kts")
스크립트 플러그인은 자동으로 확인되며 로컬 파일 시스템이나 원격 위치의 스크립트에서 적용할 수 있다. 파일 시스템 위치는 프로젝트 디렉토리를 기준으로 하며 원격 스크립트 위치는 HTTP URL로 지정된다. 여러 스크립트 플러그인(어느 타입이든)을 특정 대상에 적용할 수 있다.
커뮤니티 플러그인 찾기(Finding community plugins)
그레이들에는 다양한 기능을 위한 플러그인을 제공하는 활발한 플러그인 개발자 커뮤니티가 있다. 그레아들 플러그인 포털은 커뮤니티 플러그인을 검색하고 탐색하기 위한 인터페이스를 제공한다.
플러그인에 대한 추가 정보(More on plugins)
이 장에서는 플러그인과 그레이들 및 이들의 역할을 소개하는 것을 목표로 한다. 플러그인의 내부 작동에 대한 자세한 내용은 커스텀 플러그인을 참고하자.