As a mean to share and centralize gradle build files it would be interesting to have a way of “including” a gradle script from a repository artefact. For instance it would be interesting to have something similar to “apply from: ‘common.gradle’” that would support artefact notation like the following: “apply from: ‘com.company:common-gradle:1.0.1’”.
The buildscript closure could be used to determine where to get the artefact from (similar like the way custom gradle plugin can be fetched).
This would allow complex builds to factor out repeated/common gradle code and at the same time have smart dependency checking at the buildscript level for the gradle build.
I saw very similar concept of this idea in multiple peoples posts, it looks like they had a very similar need.
Here are URLs that reflect the need for such a feature:
Plugins should be for additional functionality, the way I see it.
Sometimes all I want is to share a list of dependencies between all my we applications or a common set of tasks. I do not want to have to duplicate those files. Also, I want to be able to have a version for those files so when I change them I do not break all the projects related to it.
The 3 current way I see how I could achieve that are the following (and the reason why I do not think they are perfectly fit):
1- Writing a plugin. I think writing a plugin is meant for additional functionality. I also think that if most people would want to have the functionality built-in than it should be included in the main release of gradle instead of adding a plugin. Also, some functionality (like the one I describe) are very closely linked with the way gradle works and therefore, as to my opinion, should be part of gradle. Writing a plugin takes also a lot more effort and knowledge, therefore simple addition should not have to be coded in plugins when you could only write 1 very clear line of code to replace them.
2- Creating a multi-project build. This would allow to put the common gradle code in the parent project. This makes a lot of sense in most cases, but when the different projects that shares the common code are very different projects and are not part of the same build, this is not something I see as a good solution.
3- Using the "apply from: ‘http://server/path/common.gradle’ ". This is very close to what I want and very close to the feature I am requesting. But this has some disadvantages, you have to have a web server running somewhere when all you want is sharing a few files. Also when testing your build script locally, you have to start a web server just for testing the sharing of 1 file. Finally, sharing file on a web server using simply HTTP does not have all the benefits of dependency management that we have grown to love; you cannot have 1 build including a gradle script that itself depends on another gradle script somewhere else.
Also, something very very interesting that could be possible to perform if this feature is added to gradle, is to share gradle code with other gradle users by publishing the gradle code as a gradle artefact in a repository online. This would make it possible to write gradle build code like you would write java code and to use gradle “library” the way you use java library.
I just looked more in detail about how to write a plugin and what the “apply from” does more exactly.
I have to admit writing a plugging is a lot less complex than I though it was.
I therefore think that writing a plugin probably solves most of the concert I had.
The only concern I am not sure if it is solved or not is the following:
If I would write a plugging, can my plugin have artefact dependencies?
Yes, plug-ins can have configurations and dependencies as any Gradle project (they are gradle projects)
They can add dependencies to configurations added by other plug-ins for instance.
See also the script handler https://docs.gradle.org/current/javadoc/org/gradle/api/initialization/dsl/ScriptHandler.html
Which allows to specify your plug-in repository location and their dependencies.
For that you need to use the ‘buildscript’ block and the ‘classpath’ configuration of your gradle Project or gradle Settings object.
Tell us if you need more help, but the user guide section is clear enough to get a good start