How do you write a custom gradle plugin to handle dependencies in a custom module descriptor, from a custom repository? The gradle documentation says the following, but I haven't been able to find anything that tells me how.
Even if your project is using a custom dependency management system or
something like an Eclipse .classpath file as master data for
dependency management, it is very easy to write a Gradle plugin to use
this data in Gradle.
I've been maintaining a Custom Ivy resolver for ATG projects (forked from this project), but Gradle recently deprecated this with version 1.8, and I need to port the implementation to a native Gradle plugin.
Implementations of ATG use 'modules' (not unlike Gradle projects), that have a MANIFEST.MF file for a module descriptor. These files define other 'modules' that a module depends on, and also a list of paths (jars or directories) that form the (direct) classpath for the current module.
e.g.
ATG-Class-Path: lib/classes.jar lib/commons-beanutils-1.7.jar
ATG-Required: MyProj.core MyProj.integration.webservices DAF.Endeca.Assembler
Module dependencies are transitive, and may refer to custom modules or modules that sit within the ATG product installation. Hence, I need to define a custom repository that can use the ATG product installation as a source of artifacts.
Without Gradle, I need to maintain dependencies in the form of
ATG's MANIFEST.MF files
Eclipse .classpath files
Dependencies for the Ant build-script
SonarQube configurations
Since I can't get rid of the ATG MANIFEST.MF files, I would like to write a write a custom plugin to allows them to be used in Gradle builds. I can then use Gradle as my build system, which can also generate Eclipse .classpath and .project files, and run Sonar against the project.
Gradle seems to have a lot of source code, and rummaging through it for the last couple of days hasn't got me anywhere.
If someone can point me to a list of interfaces that need to be implemented to (1) implement a custom repository, and (2) implement a custom dependency resolver (to use custom files as module descriptors), that should be enough to get me started.
The Eclipse .classpath use case mentioned above can be solved by parsing that file and translating it to Gradle file dependencies. It isn't currently possible to plug in a custom repository implementation.
Related
I want to publish a common build script which i will include across various projects in my application.
This will contain only the common set of dependencies, i.e dependencies with particular versions that will be common across all the artifacts in my enterprise application..
My applications will refer to this file from the url.
How can i achieve this?
EDIT1: my exploration in this direction is based on this answer on SO:
How to share a common build.gradle via a repository?
There are a few different options for this.
One is to publish a project with the dependencies you want to share defined as API dependencies. Projects that depend on this will inherit the dependencies.
Or you could write and publish a Gradle plugin that will configure your projects with the common dependencies. Projects can apply the plugin, and will automatically be configured in a certain way. (You don't need to publish a plugin to do this - first try creating a project-local buildSrc convention plugin.)
I would actually recommend neither of these approaches.
It's easy to get into a tangled web of dependency hell when transitive dependencies are inherited. It's likely that at some point some dependency will clash, and excluding dependencies can be a big headache, and will easily cancel out any benefit in trying to reduce a little duplication.
Additionally, it's nice when a project is explicit about its dependencies. Being able to look at a build.gradle.kts and understand exactly what dependencies are set is very convenient.
Instead, what I would recommend is controlling the versions of common dependencies in a central location. This can be achieved with the Java Platform plugin. This plugin can be applied to a single build.gradle.kts file, and it lists all versions of all possible dependencies. (It can also import existing Maven BOMs, like the Spring Boot BOM).
Now, all subprojects can add a platform dependency on the 'Java Platform' project.
dependencies {
// import the platform from a Maven repo
implementation(platform("my.company:my-shared-platform:1.2.3"))
// or import a platform from a local project
implementation(platform(":my-project:version-platform"))
// no need to define a version, if it's defined in the platform
implementation("com.fasterxml.jackson.core:jackson-databind")
}
This is the best of both worlds. Projects can be explicit about their dependencies, retain autonomy, while the versions can be aligned across independent projects.
I have 2 gradle projects. One is my custom gradle plugin and the other one is project which uses this plugin.
I know I can build my custom plugin, publish it to some repository and use it in my other project but is there any way how can I set something like "dependency" for my plugin (in build.gradle of my other project) and use it without need of building/publishing it somewhere?
To get and idea what I am trying to accomplish, here is some code which hopefully demonstrates the idea:
buildScript {
dependencies {
compile project(":my-gradle-plugin")
}
}
apply "my-gradle-plugin"
You can do that if your plugin project can be moved inside buildSrc of the project that wants to include it. In that case, the plugin will be by default on the classpath of the project.
If that plugin is shared between multiple projects, you will need to produce the binary and then reference it. Note that a local repository can be used, it does not have to be a remote one. One advantage of using a local repository is that Gradle will not cache the resolved plugin and thus any update, even without a version change, will be picked up immediately.
Ive been working off the guides which mention to start by doing
gradle init
on the project. So this creates build.grade. However, the rest of the gradle file is very thinly padded. Im quite new to doing these conversions, but broadly speaking, what would be the next step to get things in harmony?
The Gradle docs lists the following features of the Maven POM conversion:
Uses effective POM and effective settings (support for POM inheritance, dependency management, properties)
Supports both single module and multimodule projects
Supports custom module names (that differ from directory names)
Generates general metadata - id, description and version
Applies maven, java and war plugins (as needed)
Supports packaging war projects as jars if needed
Generates dependencies (both external and inter-module)
Generates download repositories (inc. local Maven repository)
Adjusts Java compiler settings
Supports packaging of sources and tests
Supports TestNG runner
Generates global exclusions from Maven enforcer plugin settings
This means, every required functionality beyond these features must be added manually, either by searching and applying plugins equivalent to the ones used in Maven or by implementing the functionality on your own.
When you define multi module project in Maven, you have one root project and its modules. When you build the root project, Maven transitivelly builds all its modules in correct order. So far pretty similar to Gradle.
But with Maven, you can clone only one submodule from repository and build it locally without need to download the whole project structure. This is because you define dependencies on other modules within the same project just as any other external dependency and it is downloaded and cached from your local repository (Nexus).
With Gradle, you define cross module dependencies as compile project(':other'). So you need to clone whole project structure from repository in order to resolve and build correctly. Is there any way to use Gradle multi module project support, without having to locally clone whole project structure?
I would argue that Maven's multi-module support is a slapped on after-thought. Unlike Gradle, a project dependency is not a first class concept. Instead the maven "reactor" substitutes local artifacts for dependencies when the GAV (group/artifact/version) matches.
If you'd like to use the same approach in Gradle then you can specify your dependencies using the GAV notation and then use the new composite build feature to join two or more separate gradle builds together and substitute repository dependencies for local source dependencies. Note that that you can define the projects included in the composite using groovy so you could easily script this based on custom logic (eg if a subfolder exists in some root folder etc)
Note that composite build support is a new feature added in Gradle 3.1. Prior to Gradle 3.1 you can use Prezi Pride to achieve the same
When using some 3rd party libraries, I add a dependency to my module's build.gradle file.
compile 'com.android.support:appcompat-v7:24.1.1'
Or I add a plugin
apply plugin: 'com.neenbedankt.android-apt'
Some other times, the library requires adding a dependency to my app's build.gradle file.
classpath 'com.neenbedankt.gradle.plugins:android-apt:1.8'
What is the difference between these dependencies and plugins?
Why can't they all be set in a single build.gradle file?
All suggestions are appreciated, I'm having trouble searching for info on this
Three things. Gradle plugin, module dependency, a build dependency which is placed on the classpath of the build tool.
A plugin is how Gradle knows what tasks to use. There are many plugins. For more info, see Gradle - Plugin Documentation
A dependency is a library that is compiled with your code. The following line makes your module depend on the Android AppCompat V7 library. For the most part, you search Maven or Jcenter for these.
compile 'com.android.support:appcompat-v7:24.1.1'
The classpath setting is needed for Gradle, not your app. For example, this allows this includes the Gradle Build Tools for Android into the classpath, and allows Gradle to build apps.
classpath 'com.android.tools.build:gradle:2.1.2'
Why can't they all be in one build.gradle file?
They probably can be. It is simply more modular to not.
I got this answer from a colleague, and this helped me understand. "A gradle plugin is like the tools you use to build the app. The dependencies are the libraries included in the app. A gradle plugin is usually the tasks - like ktlint, etc."
I didn't understand this myself so here is what i found. My answer is based on gradle build tool.
Plugins:
Add additional tasks, repositories, new DSL elements, configuration for classpaths/build/run or dependency management for subsequent development. Plugins are developed for a larger scope of development like java, kotlin or spring-boot.
Dependencies:
modules/libraries for tasks like http, serialization or database are dependencies stored remotely at repositories or locally that are needed at runTime, test or build are resolved by gradle in a configured fashion.
Sources:
Spring boot gradle plugin: https://github.com/spring-projects/spring-boot/tree/master/spring-boot-project/spring-boot-tools/spring-boot-gradle-plugin
Gradle documentation on plugins/dependencies: https://docs.gradle.org/current/userguide/plugins.html
https://docs.gradle.org/current/userguide/core_dependency_management.html
Remote repositories:
https://mvnrepository.com/
In simple words:
Plugins are used to add some additonal features to the software/tools(like Gradle). Gradle will use the added plugins at the time of building the App.
Dependecies are used to add some addtional code to your source code, so a dependency will make some extra code (like Classes in Java) in the form of library available for your source code.