Gradle has perfectly documented build lifecycle. But I have failed to find information on third-party plugin's lifecycle, relevant to Gradle's deamon process.
I am interested at least in plugin's classes initialization. When are plugins initialized? Are they initialized on per build basis? Or per deamon? How many instances of a plugin's class exist in single Gradle's deamon process?
As of Gradle 2.2, a new build model is created for each Gradle invocation (whether daemon is enabled or not). This includes creating a new plugin instance for each apply plugin: statement. There aren't any guarantees around class initialization.
Related
We are developing a Drools application and our organization has standardized on Gradle. We need to use the kie-maven-plugin to create and compile our rules in a KJar. This is so we can hot swap new versions of the rules. Is there a Gradle version of this plugin available? I don’t think that Maven plugins can be used in Gradle.
No, you need to port, I think its this project: https://github.com/kiegroup/droolsjbpm-integration/tree/master/kie-maven-plugin
However there is a way of doing drools as resource files like here: https://github.com/Spantree/drools-examples/
and this line is what got me stuck: https://github.com/Spantree/drools-examples/blob/master/src/test/groovy/net/spantree/examples/drools/helloworld/HelloWorldSpec.groovy#L19
(They just get the session directly from container, ignoring getting a base first)
This does not give you the compile time checks the maven module gives you.
However hot swapping resource based drools should be easier (I think).
I'd like to develop a Gradle plugin that performs some operations on the Jenkins model object.
(such as automatically fingerprinting the compile dependencies and the published ivy artifact)
Do you know if it is currently possible to retrieve the instances of Jenkins' AbstractBuild and other classes from a gradle plugin ?
I'm not sure how you'd achieve this with a Gradle plugin, as you need to be running inside the Jenkins JVM to access the model object. You might find it easier to use the REST API if it exposes the data you need. Otherwise you'd need to attach to the Jenkins JVM process remotely.
I'm developing Jenkins' plugin which is dependent on another plugin (specifically MultiJob plugin, but it can be any other one of course).
Obviously, the dependency is found in POM, so I can actually use the classes of it.
The problem: if I'm trying to install my plugin in Jenkins that the dependency is not found in it Jenkins doesn't installs it automatically and upon first usage my plugin throws an exception NoClassDefFoundError, of course.
Question: can I make Jenkins to install my dependencies as prerequisites and if yes, how?
Note: I do see that other plugins somehow cause the dependencies to be installed (Git plugin for instance makes GitClient installed during its installation).
Thanks in advance.
It's been a while since i've raised the question, but if anybody will look for something similar, here is what i've finally came up with:
Since the dependency classes are only needed in case they are really there, i've decided to use Java's lazy linkage behavior and actually refer the relevant classes only on demand.
So practically, made a factory that has a list of class names of interest and every time i need to process some object i'm checking it's class against this list. If matched - the class is loaded and therefore it's okay to init the linking/initiation logic.
Last one, if you plan to use such a pattern do not forget to sign those dependency plugins as optional in your pom.xml.
I'm used to mvn, but I'm testing Gradle (v1.8) for a small web development project.
I've noticed that the Jetty Gradle plugin support autoscan and hot deployment, so I've enabled it. My goal is to recompile from Eclipse and get a Jetty reload the context every time I change a Controller, etc.
However, this is non working, mainly because Gradle compilation output goes to build/, however the Gradle Eclipse plugin creates a .classpath configuration that directs all the Eclipse output to /bin (even mixing test and main source folders).
Is there a way to?...
Run graddle jettyRun on a separate console.
Save a modified class on Eclipse (triggering a compilation)
See that Jetty picks up the change and reloads the context.
As per my research, I've identified three workarounds, but none of them solves the question above (I'm posting them in case you have related comments or more recommendations)
Tweak Gradle Eclipse config to direct test and main build output to the same directory that Gradle uses (using the pattern seen here). This is not recommended by some people, as it means using two different compilation systems that could interfere with each other.
Use the Gradle eclipse-wtp plugin to generate a WTP2 config, and use Eclipse's "Run AS -> Run on Server". This accomplishes the hot deployment / iterative goal and keeps both systems (IDE and Gradle) isolated. However, you need to setup the server on Eclipse.
(Not really a workaround): I've tested Spring's Eclipse build (STS) Gradle integration, however it seems that the integration is focused on the project setup, and while Gradle builds can be automatically triggered, Eclipse compilation is still redirected to bin/.
So you are interested in fine-tuning hot-deployment, right?
Please, consider using Gretty gradle plugin: https://github.com/akhikhl/gretty
It is an advanced gradle plugin for running web-apps on jetty. It does exactly what you want, regarding hot-deployment (and, possibly, even more).
Disclosure: I am author of Gretty plugin.
If you don't want to change to other plugins, here are two steps for the workaround:
add below configurations into your build.gradle:
jettyRun {
reload = "automatic"
scanIntervalSeconds = 1
}
each time after you changed java code, run the following task:
gradle compileJava
Because jetty is watching the *.class files, it will hot reload only after *.class files changed.
Refer to this link: https://discuss.gradle.org/t/hot-deploy-with-jetty-plugins-jettyrun/7416
I am using Gradle as a build tool for my Scala projects. I am also using Eclipse for development, so I always use the apply plugin: 'eclipse' in my build files.
Is there also a way to define the apply plugin globally? SBT already has such a feature. The reason why I want this, is that other developers who’re using my project probably don’t use Eclipse but another IDE and they would have to change the build script for their needs. If there were a global configuration file, one could put personal configurations in there and it wouldn’t conflict other ones.
You can put this into ~/.gradle/init.gradle:
rootProject.allprojects {
apply plugin: "eclipse"
}
The drawback of this approach is that it makes the build less reproducible. People now need to add something to their init.gradle to make (some aspect of) the build work. Therefore, I would recommend to apply the Eclipse plugin in the main build script; it won't hurt people who don't use it.
for the accepted answer, I also got the error message "The root project is not yet available for build".
I am using gradle 7.6 and I was trying to use the Gradle Test Logger Plugin
Here's the ~/.gradle/init.gradle that worked for me:
initscript {
repositories {
gradlePluginPortal()
}
dependencies {
classpath 'com.adarshr:gradle-test-logger-plugin:3.2.0'
}
}
allprojects {
apply plugin: com.adarshr.gradle.testlogger.TestLoggerPlugin
}
There are multiple things to be aware of when configuring a 3rd party plugin globally:
you need to add the plugin as a dependency to make it available
you need to reference the plugin by its implementation class rather than its ID
you must not use quotes around the implementation class
The last two points are described in the Gradle Forums question
Cannot apply plugin by id in init.gradle script.
How to Find the Implementation Class
If you wonder what the implementation class is for your plugin, here's how I found it for the Gradle Test Logger Plugin:
Open the project on github
Look at it's build.gradle file
Look for the section gradlePlugin {
Take the value from implementationClass
for example: https://github.com/radarsh/gradle-test-logger-plugin/blob/29af9282761f003f51d49aa804cc72e35b16c33b/build.gradle#L61
Remember to not copy the quotes :)
You could create a build.gradle in buildSrc which implements your custom logic. Just don't check it into version control. To apply it to multiple projects you could create a central buildSrc directory and create symbolic links in the projects that you want to apply it to.