I have a project I'm attempting to migrate from Maven to Gradle. I've been trying to follow the instructions on this page, but keep coming up stuck right at the start.
The version of Gradle I'm using is 7.6, and have tried each permutation of generating the build environment from the existing Maven environment:
build script DSL as "Groovy" with new APIs,
build script DLS as "Groovy" without new APIs,
build script DSL as "Kotlin" with new APIs (would prefer this), and
build script DLS as "Kotlin" without new APIs.
But, there are files not being created that the webpage mentions. For example, it says to edit the build.gradle file, but there's no file in the root of the project. There is one in the buildSrc/ directory
And I can't find any site with more up-to-date that gives step by step instructions.
Can someone point to a more updated guide to migrating to Gradle?
Related
I am new to gradle composite builds. I have a multi-project build that uses precompiled script plugins in order to have tasks configured for all projects that include the plugin. Now I want to port that functionality to a composite build setup.
The screenshots below show how the current multi-project build works:
This java precompiled script plugin (/buildSrc/.../java-conventions.gradle.kts) configures the "JavaCompile" tasks (i.e. sourceCompatability, targetCompatability...).
This kotlin precompiled script plugin imports the java conventions plugin and configures the "KotlinCompile" tasks.
Applying the the kotlin conventions plugin to project "test" automagically sets up my project with the proper "JavaCompile" and "KotlinCompile" configuration as shown above.
I have read the official docs and tutorials on gradle composite builds. Still, I dont know the proper way how to do this with composite builds. Do I have to write standalone plugins for this? If so, can you provide a POC code snippet? Any advice is greatly appreciated!
I'm trying to create and publish binary artifacts from an OpenAPI Spec to our internal Maven Repository.
First, I'm using the "org.openapi.generator" version 5.0.0-beta2 to generate an endpoint project from a spec. For example a Kotlin Spring service. Works fine, creates an entire gradle/kotlin project, with a build.gradle.kts file and a settings.gradle file.
If I navigate to that folder I can build that project just fine. I can also call that build from my original build to first generate the code and then build it.
I just don't know how to publish it. My publishing configuration is obviously not in the generated project, nor is there a maven-publish plugin. Is there a way I can 'inject' these? Can I call some kind of 'include' on a build?
For myself, I generate the files to $buildDir/generated/ and do what I want with the files in $buildDir/generated/src/main/kotlin from my own build script ... such as:
copy them to src/main/kotlin (if that's important to you),
compile them, jar them, publish them.
I don't really even appreciate that the openApiGenerate task went to the trouble of preparing a build.gradle file instead of a build.gradle.kts file, with arguably out-dated dependencies ... it should mind its own business.
We would like to start developing custom/internal SonarQube plugins (rules) in our organization but we can't get our hands on Apache Maven at the moment. All development tools must go through a rigorous certification process.
Ant being the current build tool of choice in our organization, is it possible to create a new SonarQube plugin (not being published to the marketplace) by replicating the same standard structure that is expected from SonarQube?
I've already read the following post from the SonarQube archives, but was wondering if that would still be possible to do with a little bit of elbow grease?
Concerning the answer from Simon Brandhof, I think that the plugin key, manifest generation and mandatory properties could easily be generated from well crafted Ant build script, as long as putting all required JARs in the classpath.
As far I know for developping new rules It is mandatory to create a new Sonarqube plugin and can be only build with the maven way.
see https://docs.sonarqube.org/display/DEV/Build+Plugin
I'm a Gradle newb and I'm moving a large build over to Gradle from Maven. I find that I need to write a plugin. Specifically, something to handle drools. How can I write a plugin that downloads its own dependencies so that my users don't have to mess with that? Ideally this would be over-ridable so that my user doesn't necessarily get stuck with those automatically downloaded libraries.
I'm writing an Eclipse plugin and I want to use the gradle tooling api to inspect a gradle project's build script to look whether or not it has certain plugins applied.
Lets say that I have a build script that looks something like this:
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath 'org.dm.gradle:gradle-bundle-plugin:0.6.2'
}
}
apply plugin: 'java'
apply plugin: 'org.dm.bundle'
repositories {
mavenCentral()
}
sourceCompatibility = 1.7
version = '1.0'
Is there a way that I can use the gradle tooling api to find out which plugins this particular gradle project was applying?
I know that you can get the list of project dependencies, but what about the buildscript{} dependencies?
This question has actually two separate questions embedded in it. I didn't realize at the time. The first question should be:
1. How do you use the tooling-api to find out of a particular project has applied a particular plugin?
The answer to this question is handled precisely here: Gradle Tooling API Feature
You can find the source code used in that article here: Tooling API Example Repo
However I had some trouble getting that example to build and execute locally so I posted a fix to my own fork if you want to use it.
Then the 2nd question is this:
Once you have the necessary tooling-api model and plugin from question #1, how do you execute this custom tooling script from an Eclipse plugin context?
For this you will need to use the excellent gradle integration plugin for Eclipse as a dependency for your own eclipse plugin. Once this is configured you can simply import these APIs GradleConnector, ProjectConnection, ModelBuilder that are exported by the gradle plugin for eclipse already mentioned.
Getting your own local custom model on the classpath is as easy as embedding the jar in your eclipse plugin as per normal mechanisms (MANIFEST.MF entry, don't forget build.properties to include the jar). Also you will need to have a local repo available for the custom gradle script to pickup the model/plugin classes as show in the example github repo