This message was deleted.

The type used to implement one is

org.gradle.api.Plugin

What else would they call it?

The type does not matter. It is an implementation detail. The "plugin users" do not care which Java interface the "plugin" implements. On top of that, the users must not use Plugin interface (it exists for Gradle to call the apply method)

Tbh, I personally fully disagree. I would find it very strange if would not be called

plugin

, and even more if it were called

module

. A plugin is some thing that adds functionality. You for example install an IDE plugin to make the IDE have more functionality. Or you install a TeamCity plugin to make TeamCity have more functionality. Gradle plugins add functionality to Gradle, like making it able to execute SpotBugs, or to build HTML from AsciiDoc documents. Yes, there are also convention plugins that do not actually add functionality but just configure built-in things. But those are just a very small subset. Even most convention plugins will apply further 3rd party plugins and thus add functionality.

retroactively breaking a decade or more of gradle information on the internet with a rename would be quite bad too. naming is hard, personal biases one way or the other are too.

J2EE application "adds functionality to an application server", yet noone calls ear a plugin

No, it does not really add functionality to the application server. The application server serves standalone applications that are deployed to it. Putting a HTML page to an Apache instance is also not extending the functionality of the Apache server, it just provides content that is served by it.

Application server has features and abilities even without a single deployed application. For instance, there's likely an admin console. The more apps one deploys the more features the server will have You can't customize TeamCity without a plugin as there's no way to put code that teamcity would execute and augment UI. Correct me if I am wrong, but one can't add features to TeamCity UI without writing a plugin. The same goes to file format plugins in video and image processing apps: the only way to add support of a new file format is to add a binary (plugin) that will parse it. At the same time, Gradle can be extended without plugins by writing all the code in build.gradle.kts. Gradle is already customizable, so the "plugins" do not really unblock customizability, but they are more like "for factoring out code so it is split across several files better".

The more apps one deploys the more features the server will have

No, deployed apps do imho not add features to the application server. A feature of the application server is, that it can serve ears, another feature is that it can serve wars, another feature is that it can provide the deployed applications a database connection. A deployed application cannot add such functionality to an application server. And again, even if one considers this as "added features to the application server", that the application server does not call it "plugin" is no indication that it is wrong to call it "plugin" for other domains.

You can't customize TeamCity without a plugin as there's no way to put code that teamcity would execute and augment UI. Correct me if I am wrong, but one can't add features to TeamCity UI without writing a plugin.

That's again a highly subjective question and matter of definition. If you define deploying an application to an application server as adding functionality, then you could also consider setting up a project build in TeamCity as adding functionality, as you add the functionality to build project X. I would not call that adding functionality, but at the same time I do not call deploying an application to an application server adding functionality. 😄

The same goes to file format plugins in video and image processing apps: the only way to add support of a new file format is to add a binary (plugin) that will parse it.

Highly depends on the program. In GiMP you can for example use Script-Fu to add functionality to GiMP without installing any plugin.

At the same time, Gradle can be extended without plugins by writing all the code in build.gradle.kts. Gradle is already customizable, so the "plugins" do not really unblock customizability,

So are other programs like GiMP, jEdit, and many others already highly customizable, or able to execute scripts or macros that add functionality and so on. Doesn't make it less valid to call something a "plugin" that someone prepares for you and you plug into the existing program to then have it done something, even if that something would just be some sequence of already built-in things. Also, if we drive your statement further, then even without possibility to put code to

build.gradle.kts

, Gradle is open source and you can any time check out its source code, do any customization you need and build an own distribution with your customizations, so even without build scripts, Gradle would not per-se block customizability.

but they are more like "for factoring out code so it is split across several files better".

I fully disagree here too. Yes, you can do that with plugins too. But the main point of a plugin is, that one person implements something, be it a convention that just does configuration, some added functionality, or whatever else, packages that as plugin and provides it, so that other persons can get the plugin, plugin it into their build and have that added functionality, where functionality can just be different conventions / configuration, convenience over existing functionality, or completely new functionality.

Gradle users can execute Spotbugs even without spotbugs plugin. They can create javaexec task and execute whatever they want. Spotbugs plugin is not something special. It does not unlock features from the end-user point of view.

Of course it does. Sure, you can also just use batch scripts to build a project, but why should you? "Functionality", as said above, is again a very subjective term that you obviously interpret differently. All-in-all, I think you made clear that you just don't like the term "plugin" for whatever reason, but I highly doubt - and hope - this will ever be changed, as it imho perfectly fits the situation and is the term that is also used in most other situations that are similar. 🙂

> A feature of the application server is, that it can serve ears A feature of the app server is that it responds to external clients like browsers and other systems. > that the application server does not call it “plugin” is no indication that it is wrong to call it “plugin” for other domains. That is an example of a case when “extending functionality” does not necessarily makes something a “plugin”. > So are other programs like GiMP, jEdit, and many others already highly customizable, or able to execute scripts or macros that add functionality and so on. Once again: if something in GiMP can be extended with a script (without re-compilation of GiMP), then that extension most likely is not a plugin. However, historically, “file format handlers” were not scriptable. In other words, it was impossible to add support for a new image file format by changing configuration files. It required implementing plugs that were plugged in to the specially designed APIs of the host program. > Also, if we drive your statement further, then even without possibility to put code to

build.gradle.kts

, Gradle is open source and you can any time check out its source code, do any customization you need and build an own distribution with your customizations, so even without build scripts, Gradle would not per-se block customizability Strongly disagree. My claim is relatively simple: everything a “Gradle plugin” can do can be made without rebuilding Gradle. Changing Gradle’s sources and building a different software binary creates, well, a different software binary. Of course, if you implement a feature by modifying the sources, then you just modify the software. The definition of term “plugin” is that it enables users to augment software features without modifying the host software. > But the main point of a plugin is, that one person implements something, be it a convention that just does configuration, some added functionality, or whatever else, > packages that as plugin and provides it, so that other persons can get the plugin, plugin it into their build and have that added functionality, where functionality can just be different conventions / configuration, convenience over existing functionality, or completely new functionality. What you describe has nothing to do with “plugging”. It has something with “importing”, it has something with “factoring code into several components/modules/extensions/libraries”. However, the definition you mention (~“one person implements something…that other persons can get”) is just a regular library or module. One person implements kotlin-stdlib.jar, and another person can plug it into their project and use it. Noone uses “plugins” for regular JVM .jar libraries. They call them libraries. > All-in-all, I think you made clear that you just don’t like the term “plugin” for whatever reason, That is the point: the term “plugin” is wrong for the concept Gradle uses it.

That is an example of a case when “extending functionality” does not necessarily makes something a “plugin”.

If one calls that "extending functionality", I agree that not everything that extends functionality is eligible to be called "plugin". But as I said before, just because in some situations extending functionality might not be called "plugin" doesn't mean that other things that extend functionality should not be called "plugin". A Gradle plugin extends the functionality of Gradle (be it by providing other conventions than the defaults, or be it making some things like Spotbugs more conveniently usable, or be it completely different functionality doesn't matter) so calling it "plugin" is imho perfectly fine. I see no reason yet why calling it "plugin" could be wrong. That you can achieve the same functionality extending also in other ways does not make them less eligible to be called "plugin".

My claim is relatively simple: everything a “Gradle plugin” can do can be made without rebuilding Gradle. Changing Gradle’s sources and building a different software binary creates, well, a different software binary. Of course, if you implement a feature by modifying the sources, then you just modify the software. The definition of term “plugin” is that it enables users to augment software features without modifying the host software.

From what I read you contradict yourself here. You seem to say that because you can do the same things without rebuilding Gradle, you cannot call them "plugin", but then say that something can just be called "plugin" if it extends the functionality without rebuilding the host software. I fully agree that for something to be called "plugin" it needs to plug into the host software without rebuilding the host software, which is exactly what Gradle plugins do. The point here was, that you said that because you can achieve the same functionality extending without using a plugin, Gradle plugins must not be called plugin. And I just said that you can also achieve the same functionality extending by compiling a new Gradle distribution which then of course would also not be called "plugin" but is also a way to do the same functionality extending. And following from that no OSS functionality extending could ever be called "plugin" as there is always a different way to achieve the same functionality extending.

What you describe has nothing to do with “plugging”. It has something with “importing”, it has something with “factoring code into several components/modules/extensions/libraries”. However, the definition you mention (~“one person implements something…that other persons can get”) is just a regular library or module. One person implements kotlin-stdlib.jar, and another person can plug it into their project and use it. Noone uses “plugins” for regular JVM .jar libraries. They call them libraries.

That does totally not fit here imho. Using a plugin in any system is always the same as "importing" that functionality into the host software. That does not make them less eligible to be called "plugin". With regular JVM .jar libraries the case is totally different, because there is no host software where you plug them in. You use them from your code. They do not plug into your code so they are not eligible to be called "plugin". But Gradle plugins use the API provided by Gradle to plug into the Gradle build system to extend the functionality.

That is the point: the term “plugin” is wrong for the concept Gradle uses it.

... no 🙂

From what I read you contradict yourself here. You seem to say that because you can do the same things without rebuilding Gradle, you cannot call them “plugin”, but then say that something can just be called “plugin” if it extends the functionality without rebuilding the host software.

It might be lost in translation, but I used a word of “enables users…” In other words, plugins unlocks something that is not otherwise possible. Gradle is extensible via

build.gradle.kts

, so calling “a jar with code that could be within build.gradle.kts” a “plugin”, well, is a stretch. It is much more of a library than a plugin.

by compiling a new Gradle distribution

Can you refer to a third-party definition of a plugin? For instance, https://en.wikipedia.org/wiki/Plug-in_(computing) directly mentions “adds a specific feature to an existing computer program”. Could you please stop bringing “add feature by modifying the source code and rebuilding Gradle” here? I am sure we should focus on adding features to existing software packages like “the official Gradle distribution”.

And following from that no OSS functionality extending could ever be called “plugin” as there is always a different way to achieve the same functionality extending.

OSS can easily have plugins. For instance, Jenkins Plugins are good fit for the word. For instance, Gitlab plugin can talk to Gitlab server, and create jobs based on Gitlab branches. I think one can’t configure Jenkins to talk to Gitlab otherwise. They have to package “plugin code” in a special way so Jenkins loads it and executes. At the same time,

build.gradle.kts

is the common way users configure Gradle, so it would be not much useful to call

build.gradle.kts

a Gradle plugin. Just in case, Gradle’s documentation provides little-to-no definition of what “Gradle plugin” actually means. https://docs.gradle.org/current/userguide/plugins.html#plugin_distribution

Many Gradle features, like the ability to compile Java code, are added by plugins.

Plugins add new tasks (e.g., JavaCompile), domain objects (e.g., SourceSet), conventions (e.g., Java source is located at src/main/java), and extend core objects or objects from other plugins.

Applying a plugin to a project allows the plugin to extend the project’s and Gradle’s capabilities

In other words, the documentation says what plugins do, however, it does not define the word and its meaning. Missing the definition in the Gradle’s official document is quote a bad sign on its own.

It's probably also that I'm not a native speaker that you seem to misinterpret what I say continuously. One last time, even if you can achieve the same thing in a different way, does not mean Gradle plugins must not be called "plugin". No definition you can pull up will say that a plugin must only be called plugin if there is no other way to achieve the same effect. That does not render the term "plugin" ineligible. But as I said - or meant - before, we probably just have to agree we disagree on this topic. 🙂

So you would be fine with "extension" while you dislike "plugin"? I'm curious, where do you see the difference between these terms? I'd have considered them synonyms.

As I read “plugin”, it seems to be “focused” on plugging something in like physically plugging a plug into a socket. However, the way I perceive “Gradle plugins” is not like “plugging the plugins into their sockets”, but I it is more like “importing a subset of build logic”, “importing an build logic extension”, and so on. “extension” sounds better as it does not seem to focus on “plugging”. Of course, calling everything an extension would not be extremely helpful. However, “build extension” sounds more-or-less fine. I remember there was a project by @tony that listed Gradle vocabulary. I wonder how “plugins” were defined there 🙂