// Copyright (C) 2024 Gradle, Inc.
//
// Licensed under the Creative Commons Attribution-Noncommercial-ShareAlike 4.0 International License.;
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
//      https://creativecommons.org/licenses/by-nc-sa/4.0/
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.

[[implemention_plugins]]
= Implementation Options for Plugins

The choice between script, precompiled script, or binary plugins depends on your specific requirements and preferences.

*Script Plugins* are simple and easy to write.
They are written in Kotlin DSL or Groovy DSL.
They are suitable for small, one-off tasks or for quick experimentation.
However, they can become hard to maintain as the build script grows in size and complexity.

*Precompiled Script Plugins* are Kotlin or Groovy DSL scripts compiled into Java class files packaged in a library.
They offer better performance and maintainability compared to script plugins, and they can be reused across different projects.
You can also write them in Groovy DSL but that is not recommended.

*Binary Plugins* are full-fledged plugins written in Java, Groovy, or Kotlin, compiled into JAR files, and published to a repository.
They offer the best performance, maintainability, and reusability.
They are suitable for complex build logic that needs to be shared across projects, builds, and teams.
You can also write them in Scala or Groovy but that is not recommended.

Here is a breakdown of all options for implementing Gradle plugins:

[cols="~,~,~,~,~"]
|===
|*#* |*Using:* |*Type:* |*The Plugin is:* |*Recommended?*

|1
|Kotlin DSL
|Script plugin
|in a `.gradle.kts` file as an abstract class that implements the `apply(Project project)` method of the `Plugin<Project>` interface.
|Nofootnote:1[<<plugins#sec:build_script_plugins,*Script plugins*>> are hard to maintain. Do not use script plugins `apply from:`, they are not recommended.]

|2
|Groovy DSL
|Script plugin
|in a `.gradle` file as an abstract class that implements the `apply(Project project)` method of the `Plugin<Project>` interface.
|Nofootnote:1[]

|3
|Kotlin DSL
|Pre-compiled script plugin
|a `.gradle.kts` file.
|Yes

|4
|Groovy DSL
|Pre-compiled script plugin
|a `.gradle` file.
|Okfootnote:2[It is recommended to use a statically-typed language like *Java* or *Kotlin* for implementing plugins to reduce the likelihood of binary incompatibilities. If using Groovy, consider using *statically compiled Groovy*.]

|5
|Java
|Binary plugin
|an abstract class that implements the `apply(Project project)` method of the `Plugin<Project>` interface in Java.
|Yes

|6
|Kotlin / Kotlin DSL
|Binary plugin
|an abstract class that implements the `apply(Project project)` method of the `Plugin<Project>` interface in Kotlin and/or Kotlin DSL.
|Yes

|7
|Groovy / Groovy DSL
|Binary plugin
|an abstract class that implements the `apply(Project project)` method of the `Plugin<Project>` interface in Groovy and/or Groovy DSL.
|Okfootnote:2[]

|8
|Scala
|Binary plugin
|an abstract class that implements the `apply(Project project)` method of the `Plugin<Project>` interface in Scala.
|Nofootnote:2[]
|===

If you suspect issues with your plugin code, try creating a link:https://scans.gradle.com/[Build Scan] to identify bottlenecks.
The link:https://github.com/gradle/gradle-profiler[Gradle profiler] can help automate Build Scan generation and gather more low-level information.
