I'm working on a Gradle (Groovy, not Kotlin) library using a bunch of external libraries, and we have a case where we want to implement double-inheritance in our code off of a custom Task provided by an external library. (For reference, that library is specifically the MarkLogic DataHub, and we're extending RunFlowTask, but I've generalized a bit for this example. There are a few restrictions that introduces, but I'm fairly certain all of them can be worked around.)
What I want is the following:
ClassA.gradle
class ClassA extends com.external.plugin.TaskA {}
ClassB.gradle
import com.fasterxml.jackson.databind.ObjectMapper
class ClassB extends ClassA {}
...with no restrictions on where things need to be, just that it works. Worth noting that we have a bunch of examples like ClassA that work on their own, I just need to extend ClassA again.
I've detailed a few attempts I made to get this to work below; any feedback on what I did wrong with any of them is more than welcome, or if there's any advice on an entirely new way to build things, that's totally appreciated as well.
First attempt:
apply from: './ClassA'
apply from: './ClassB'
=>
'unable to resolve class ClassA' in ClassB.gradle, which makes enough sense given what I know about how Gradle compilation works. I tried replacing class ClassB... with println ClassB just to see, and that printed without an issue. Made me think that ClassA needed to be compiled in advance, so I'm pretty sure there's nothing I'm doing wrong here, it just won't work.
Second attempt:
buildSrc/src/main/groovy/ClassA.gradle exists and is the same as above.
buildSrc/build.gradle
import com.fasterxml.jackson.databind.ObjectMapper
buildscript {
repositories { }
dependencies {
classpath fileTree(dir: '/path/to/dependencies', include: '*.jar') // includes jackson
}
}
println ObjectMapper
The println worked, but I get:
/path/to/src/main/groovy/ClassA.groovy: 1: unable to resolve class com.fasterxml.jackson.databind.ObjectMapper
# line 1, column 1.
import com.fasterxml.jackson.databind.ObjectMapper
...and the same thing if I duplicate the buildscript block into the ClassA submodule, or if I remove the import from the ClassA submodule. My question for this is is there anything I'm doing wrong with the imports? Seems like this should work and the imports should just work, but they're not.
Third attempt:
Sparing a few code examples here: I got everything very close to working with copying buildSrc into an includeBuild folder, and ClassA is accessible as a TaskReference in the top-level project, but I don't know how to to actually extend ClassA from there.
gradle.includedBuild('subbuild').task(':ClassA') => org.gradle.composite.internal.IncludedBuildTaskReference
gradle.includedBuild('subbuild').task(':UPMCRunFlowTask').resolveTask() => Task with path ':ClassA' not found in project ':subbuild'.
My question for this is is there a way to dig back to the class reference so it's actually extendable? I tried digging into setting up an include './subbuild' subproject and ran into similar issues.
Any help/advice is welcome - thanks!
Answer was on the second attempt. In build.gradle, it needed to be:
repositories {}
dependencies {
implementation fileTree(dir: '/path/to/deps', include: ['*.jar'])
}
...and nothing needed to be in the sub-files.
Related
I have a sub-project with a classifier, test-fixtures, that I want to include into an adjacent sub-project:
dependencies {
implementation(project(":producer"))
}
I assumed that would be a trivial task, but I can't seem to find out how. Is that possible?
I found that this was not a classifier in the maven sense. The variant (what gradle calls them) was created by the java-test-fixtures-plugin. See user guide on testing.
It is used by importing the dependency like this:
dependencies {
testFixtures(project(":producer"))
}
I had a little problem on this since this inhibits my freedom to select the configuration I needed in order to include this jar in an ear-file. I found a way around this by adding it manually as the earlib(...)-method actually does:
dependencies {
add("earlib", testFixtures(project(":producer")))
}
Received this warning in my gradle build this morning, and trying to figure out how to solve it
Adding a Configuration as a dependency is a confusing behavior
which isn't recommended. This behaviour has been deprecated
and is scheduled to be removed in Gradle 8.0. If you're
interested in inheriting the dependencies from the
Configuration you are adding, you should use extendsFrom
Following up on this answer... I was using the configuration as a dependency approach so I could control ordering.
For example:
configurations {
A
B {
extendsFrom A
}
}
dependencies {
A 'jar1'
B 'jar2'
}
Seems to result in the order of B's path being jar1;jar2
But if I want B to be like A, but override some classes from A, then I need B's dependencies first.
So I was using this approach:
configurations {
A
B
}
dependencies {
A 'jar1'
B 'jar2'
B A
}
Which results in B's path being jar2;jar1
I couldn't figure out a way to get this to work using extendsFrom.
Mainly I tried to use B.extendsFrom(A) with various syntax in the dependencies section but couldn't get that to compile.
Is there a way to get the override/ordering use-case to work using extendsFrom?
I believe it's not possible with extendsFrom.
I am not an expert on the dependencies area, but what could work for you or give you some ideas is something like:
def a = project.configurations.findByName("A")
def b = project.configurations.findByName("A")
b.getIncoming().beforeResolve {
// If you want to get also dependencies from
// configurations that "A" extends use getAlLDependencies
a.getDependencies().forEach{
b.dependencies.add(it)
}
}
Note: getDependencies() and getAllDependencies() don't return resolved dependencies, but just the dependencies that were added to a configuration in build script (e.g. A 'jar1'). If you want resolved dependencies you have to resolve A.
Note2: I don't recommend class shadowing as I think you want to achieve. It can bring a lot of unexpected troubles, e.g. app could compile but might not work at runtime. Maybe you should rather do a dependency substitution or resolve conflicts with capabilities (https://docs.gradle.org/7.2/userguide/dependency_capability_conflict.html#sub:declaring-component-capabilities).
I'm trying to understand deeply how gradle is working.
Let's take the case of a basic dependencies {} declaration in a build.gradle script.
dependencies is a method on Project object.
DSL Project object = org.gradle.api.Project interface:
void dependencies​(Closure configureClosure)
Configures the dependencies for this project.
This method executes the given closure against the DependencyHandler for this project. The
DependencyHandler is passed to the closure as the closure's delegate.
So: method receives as parameter a configuration closure and establish that closure's delegate object is DependencyHandler class, than execute the closure against it's delegate object.
Having this example:
dependencies {
// configurationName dependencyNotation
implementation 'commons-lang:commons-lang:2.6'
}
This is translated in a call of method add of DependencyHandler class:
Dependency add​(String configurationName, Object dependencyNotation) Adds a dependency to the given configuration.
And now the question:
How exactly is done the translation of the line
implementation 'commons-lang:commons-lang:2.6'
into a class method call (e.g. DependencyHandler.add()) and who is responsable ?
My impression is that there is a missing explanation in the documentation, something like: default method on this delegate object DependencyHandler is add(...), so each configClosure's line, if matching notation configurationName dependencyNotation, will be translate into delegate's object default method.
But this is just a possible interpretation.
Ideea is: I give a closure with multiple lines, this is executed agains a delegation object which happens to have methods add(), and magically for each line this method is called ... how is this happening, based on what mechanism ? Is the Project.dependencies() method doing this, is the delegate object itself, or some other groovy specific mechanisms, etc.
Thank you.
If you want to get deeper insight on how Gradle (or its DSL) work under the hood, you can always check the actual source code. However, since this is not required to understand how to write build scripts, it is not included in the documentation.
Regarding your specific example, I have to admit that I do not exactly know how it is done, but I have a guess. If someone else has better insights, feel free to prove me wrong.
While Gradle indeed uses AST transformations to extend the regular Groovy syntax in some cases (e.g. the task definition syntax), I think they just rely on dynamic methods for dependency definitions.
Groovy is a dynamic language. This includes a method called methodMissing that may be defined by any class and will be called whenever a missing method is called on an object of that class:
class Example {
def methodMissing(String name, args) {
println name
}
}
def example = new Example()
example.method1()
You can find a more detailed example in Mr. Hakis blog.
Since Groovy allows omitting parentheses for method calls with arguments, your example implementation 'commons-lang:commons-lang:2.6' is basically nothing else but calling the method implementation with the dependency notation string as its argument.
Now Gradle could catch these calls via methodMissing and then call DependencyHandler.add() if the configuration actually exists. This allows you to dynamically add configurations in your build script:
configurations {
myConfig
}
dependencies {
myConfig 'commons-lang:commons-lang:2.6'
}
I have multi-module project under SBT.
Project A (library) has reference.conf file with A's configuration parameters. Project A depends on akka-actor library, which ships with its own reference.conf file. Project A redefines some akka's parameters in own reference.conf.
Project B depends on A.
When I call ConfigFactory.load() in B, I'm getting wrong order of reference.confs merging. It first takes A's config, then applies akka-actor's config over it. Eventually, I'm getting initial akka-actor's configuration.
How can I fix it? I need to get akka-actor's config loaded first, then my A's config should be applied over it.
Ok, looks like I've found the answer in sources of ConfigFactory.
All the reference.conf is being loaded through ClassLoader.getResources. It returns java.util.Enumeration[URL]. The order of URLs in this enum is the answer to the question. So all you need to do: ensure the order of your reference.conf resources in this enumeration properly arranged.
Here is an example of how to do that. First, create your own version of ClassLoader by overriding getResources method:
import scala.collection.JavaConverters._
class CustomClassLoader(loader: ClassLoader) extends ClassLoader(loader){
override def getResources(name: String): util.Enumeration[URL] = {
val resources = super.getResources(name).asScala.toList
// arrange resources as you wish here
java.util.Collections.enumeration(resources.asJava)
}
}
Last, call load method of ConfigFactory with your CustomClassLoader instance.
Currently, I have a few utility functions defined in the top level build.gradle in a multi-project setup, for example like this:
def utilityMethod() {
doSomethingWith(project) // project is magically defined
}
I would like to move this code into a plugin, which will make the utilityMethod available within a project that applies the plugin. How do I do that? Is it a project.extension?
This seems to work using:
import org.gradle.api.Plugin
import org.gradle.api.Project
class FooPlugin implements Plugin<Project> {
void apply(Project target) {
target.extensions.create("foo", FooExtension)
target.task('sometask', type: GreetingTask)
}
}
class FooExtension{
def sayHello(String text) {
println "Hello " + text
}
}
Then in the client build.gradle file you can do this:
task HelloTask << {
foo.sayHello("DOM")
}
c:\plugintest>gradle -q HelloTask
Hello DOM
https://docs.gradle.org/current/userguide/custom_plugins.html
I implemented this recently, a full example is available at Github.
The injection basically boils down to
target.ext.utilityMethod = SomeClass.&utilityMethod
Beware:
This method could potentially conflict with some other plugin, so you should consider whether to use static imports instead.
Based on Answer 23290820.
Plugins are not meant to provide common methods but tasks.
When it comes to extensions they should be used to gather input for the applied plugins:
Most plugins need to obtain some configuration from the build script.
One method for doing this is to use extension objects.
More details here.
Have a look at Peter's answer, using closures carried via ext might be what you are looking for.