PROBLEM
I have a custom plugin successfully published into Artifactory and I have successfully loaded it into my application by using the following syntax in my BuildConfig.groovy below. However, as I make changes to the plugin, and publish them of course, I want to get those latest changes into my application that is using the plugin?
I thought that doing a grails compile or grails refresh-dependencies would pick up the lasted code but when I go to grails-app.domain folder I do not see my newer Domain classes.
CURRENT WORKAROUND
I had to go to my .grails/2.3.4/projects/myProject/plugins delete the plugin and then run the grails refresh-dependencies in order to get the latest version of the plugin.
QUESTION
Is there a quicker/better way to do this without having to haunt the plugin in the .grails directory?
Attached are the relevant sections of my BuildConfig.groovy in case are needed to assist:
repositories {
inherits true // Whether to inherit repository definitions from plugins
//This is to be able to download our own custom plugins
String serverRoot = 'http://serverRoot/artifactory'
mavenRepo serverRoot + '/plugins-snapshot-local/'
mavenRepo serverRoot + '/plugins-release-local/'
grailsPlugins()
grailsHome()
mavenLocal()
grailsCentral()
mavenCentral()
mavenRepo 'http://repo.spring.io/milestone'
}
plugins {
// plugins for the build system only
build ":tomcat:7.0.47"
// plugins for the compile step
compile ":scaffolding:2.0.1"
compile ':cache:1.1.1'
// plugins needed at runtime but not for compilation
runtime ":hibernate:3.6.10.6" // or ":hibernate4:4.1.11.6"
runtime ":database-migration:1.3.8"
runtime ":jquery:1.10.2.2"
runtime ":resources:1.2.1"
compile ':spring-security-core:2.0-RC2'
compile ":spring-security-ldap:2.0-RC2"
compile ":spring-security-ui:1.0-RC1"
compile ":mycustomplugin:0.1" //This is the plugin that I want get the latest code for
}
Best practice to manage plugins is to change the plugin version whenever you modify the plugin code.
For example, your current version is 0.1 and when you change something in domain or somewhere else then change the version to 0.2 or something else in your plugin descriptor file and then release the plugin. Now use that new version 0.2 in your BuildConfig.groovy as compile ":mycustomplugin:0.1".
But sometime it is required to make some changes in already published version, then there are two ways to do it. First is to add -SNAPSHOT in your plugin version then Grails will always pull the latest version of that plugin and second is to add changing flag to it.
compile(":mycustomplugin:0.1") {
changing = true
}
Please have a look at http://grails.org/doc/latest/guide/conf.html#changingDependencies for more info.
Thanks,
SA
Related
Problem
I have a setup of various distinct repos/projects (i.e. app1, app2, app3) that all depend on shared functionality in my base package.
The projects also use various other third-party dependencies (i.e. app1 and app3 use spring, all of them use kotlinx-serialization).
I want to synchronise the versions of all third-party dependencies, so that any project using my base package uses the same version of every third-party dependency. However, I don't want to introduce new dependencies to projects that do not use them (i.e. app2 does not use spring)
Solution attempts
For libraries, I have been able to solve this with the help of a gradle platform, which does exactly what I want - I specify the versions in my base package, then add the platform as a dependency to my projects and can then simply add dependencies by name (i.e. implementation("org.springframework.boot:some-package")) without having to specify a version number, because it uses the provided value from my platform.
However, for plugins, I have not been able to do this. Many libraries come with plugins and naturally the plugin should be at the same version as the library. I have tried various approaches, including writing a standalone plugin, but none have worked.
Current best idea
I added implementation("org.springframework.boot:spring-boot-gradle-plugin:3.0.2") to the dependencies of my standalone plugin. Then, I added the following code to my standalone plugin:
class BasePlugin : Plugin<Project> {
override fun apply(target: Project) {
target.plugins.apply("org.springframework.boot")
}
}
This works and applies the plugin to my main project at the correct version. However, there are 2 major problems with this:
a) Now every project applies the spring plugin, including app2 (which does not use spring).
b) I have many plugins to manage and no idea how to get the long implementation-string for most of them. I found the "org.springframework.boot:spring-boot-gradle-plugin:3.0.2" by looking up the plugin-id on https://plugins.gradle.org/ and then looking at the legacy plugin application section, which sounds like I am on the wrong track.
I just want to manage the versions of plugins and libraries of multiple projects/repos in a central place - this feels like a fairly basic use case - why is this so hard?
There are some great and detailed answers about dependency management, but unfortunately none worked to perform cross-project version management for plugins.
It seems that there is no gradle functionality to do this, but I got it working with a bit of a workaround. Here is my (working) approach, in hope that it helps someone else with this:
Create a Standalone gradle Plugin
In the build.gradle.kts of the plugin, include the maven coordinates (not its ID) of every other plugin whose version you want to manage in any of your projects in the dependency block with the api keyword. i.e. api("org.springframework:spring-web:6.0.2")
In the main projects, remove every other plugin from the plugins block, so that your custom standalone plugin is the only one remaining.
Create a file (i.e. a plugins.json or whatever you want) in the project root directory of all main projects and in there supply the plugin IDs of the plugins that you actually intend to use in that project. Just the IDs, no version numbers, i.e. "org.springframework.boot" for Spring's plugin. (Keep in mind that for plugins declared as kotlin("abc") you will have to add the prefix "org.jetbrains.com.", as the kotlin method is just syntactic sugar for that)
In your plugin source code, in the overriden apply method, look for. a file named plugins.json (or whatever you chose) in the project.buildFile.parent directory (which will be the directory of the project using this plugin, NOT of the plugin itself). From this file, read the plugin IDs
for every pluginID in the file, call project.plugins.apply(id)
How/Why it works:
The main project build.gradle.kts is executed, looks at the plugin block and applies your standalone plugin (which is the only one), which calls its apply method.
This plugin then applies other plugins based on their ID from the file.
Normally, this will throw an error because these plugins are not found, but because we defined them as dependencies with the api keyword in our standalone plugin, they are now available on the classpath and in exactly the version of that import statement.
Hope it helps someone!
I use version numbers in a gradle.properties file for this purpose. Since the introduction of Gradle version catalogs, my approach is probably a bit out of date, but I'll share it here anyway. It's based on the fact that plugin versions can be managed in settings.gradle.kts by reading values from the properties file.
In gradle.properties:
springBootVersion=3.0.2
In settings.gradle.kts:
pluginManagement {
val springBootVersion: String by settings
plugins {
id("org.springframework.boot") version springBootVersion
}
}
And finally in build.gradle.kts:
plugins {
id("org.springframework.boot")
}
dependencies {
val springBootVersion: String by project
implementation(platform("org.springframework.boot:spring-boot-dependencies:$springBootVersion"))
}
Notice that the plugin version is omitted in the build script because it is already specified in the settings file.
And note also that the method for accessing the property in the settings script is slightly different from that in the build script.
a) Now every project applies the spring plugin, including app2 (which does not use spring).
It is indeed better to avoid applying too many plugins - and that's why Gradle encourages reacting to plugins.
import org.gradle.api.Plugin
import org.gradle.api.Project
import org.gradle.kotlin.dsl.*
import org.springframework.boot.gradle.plugin.SpringBootPlugin
class BasePlugin : Plugin<Project> {
override fun apply(target: Project) {
// don't apply
//target.plugins.apply("org.springframework.boot")
// instead, react!
target.plugins.withType<SpringBootPlugin>().configureEach {
// this configuration will only trigger if the project applies both
// BasePlugin *and* the Spring Boot pluging
}
// you can also react based on the plugin ID
target.pluginManager.withPlugin("org.springframework.boot") {
}
}
}
Using the class is convenient if you want to access the plugin, or the plugin's extension, in a typesafe manner.
You can find the Plugin's class by
looking in the source code for the class that implements Plugin<Project>,
in the plugin's build config for the implementationClass,
or in the published plugin JAR - in the META-INF/gradle-plugins directory there will be a file that has the implementationClass.
This doesn't help your version alignment problem - but I thought it was worth mentioning!
b) I have many plugins to manage and no idea how to get the long implementation-string for most of them. I found the "org.springframework.boot:spring-boot-gradle-plugin:3.0.2" by looking up the plugin-id on https://plugins.gradle.org/ and then looking at the legacy plugin application section, which sounds like I am on the wrong track.
You're on the right track with the "long implementation string" as you call it. I'll refer to those as the 'Maven coordinates' of the plugin.
Gradle Plugin Maven Coordinates
The plugin id of the Kotlin JVM plugin is org.jetbrains.kotlin.jvm, but the Maven coordinates are org.jetbrains.kotlin:kotlin-gradle-plugin:1.8.0 .
The 'legacy' part refers to how the plugins are applied, using the apply(plugin = "...") syntax. The new way uses the plugin {} block, but under the hood, both methods still use the Maven coordinates of the plugin.
If you add those Maven coordinates (with versions) to your Java Platform, then you can import the platform into your project. But where?
Defining plugin versions
There are a lot of ways to define plugins, so I'll only describe one, and coincidentally it will be compatible with defining the version using a Java Platform.
If you're familiar with buildSrc convention plugins, you'll know that they can apply plugins, but they can't define versions.
// ./buildSrc/src/main/kotlin/kotlin-jvm-convention.gradle.kts
plugins {
kotlin("jvm") version "1.8.0" // error: pre-compiled script plugins can't set plugin versions!
}
Instead, plugin versions must be defined in the build config for buildSrc
// ./buildSrc/build.gradle.kts
plugins {
`kotlin-dsl`
}
dependencies {
// the Maven coordinates of the Kotlin JVM plugin - including the version
implementation("org.jetbrains.kotlin:kotlin-gradle-plugin:1.8.0")
}
This looks a lot more traditional, and so I hope the next step is clean: use your Java Platform!
Applying a Java Platform to buildSrc
// ./buildSrc/build.gradle.kts
plugins {
`kotlin-dsl`
}
dependencies {
// import your Java Platform
implementation(platform("my.group:my-platform:1.2.3"))
// no version necessary - it will be supplied by my.group:my-platform
implementation("org.jetbrains.kotlin:kotlin-gradle-plugin")
}
Note that this same method will also apply if your projects an 'included build' instead of buildSrc.
Once the plugin versions are defined in ./buildSrc/build.gradle.kts, you can use them throughout your project (whether in convention plugins, or in subprojects), they will be aligned.
// ./subproject-alpha/build.gradle.kts
plugins {
kotlin("jvm") // no version here - it's defined in buildSrc/build.gradle.kts
}
tl;dr: I cannot configure IntelliJ to generate the java files in the same directory as gradle
I have a small project which uses the immutables annotation processor.
It works as expected in the gradle command line build, but I cannot get IntelliJ to output the generated files to the same directory.
The full project is available on GitLab
Gradle config:
I use the folowing gradle plugins:
gradle-idea plugin which handles the idea configuration
gradle-apt-plugin which provides the apt configuration and handles the compile-class path and idea config related to annotation processing (if also the idea plugin is applied)
relevant parts of the build-script (link to the full listing):
apply plugin: 'java'
apply plugin: "net.ltgt.apt"
apply plugin: 'idea'
dependencies {
def immutablesVersion = '2.3.9'
compileOnly "org.immutables:value:$immutablesVersion:annotations"
compileOnly "org.immutables:encode:$immutablesVersion"
apt "org.immutables:value:$immutablesVersion"
}
when I start ./gradlew build everything is as expected:
The source file DataEncoding.java is processed an the generated java-file DataEncodingEnabled.java ends up in
/build/generated/source/apt/main under the expected package com.tmtron.immutables.data
and the generated file is also compiled to a .class file
In IntelliJ I activate the annotation processing as suggested by the gradle-apt-plugin docs:
Then I execute ./gradlew clean to make sure, that the previous files are gone and then I click Build - Build Project in IntelliJ.
The annotation processor is executed, but the problem is that the generated java file ends up in the wrong location:
It is in: /build/generated/source/apt/main/build/generated/source/apt/main/com.tmtron.immutables.data
the bold part is redundant.
What am I doing wrong and how can I set it up correctly, so that IntelliJ and gradle generate the files in the same directory?
Notes:
I have of course already tried to just leave the "Production sources dir" in the IntelliJ annotation configuration empty, but his does not work: then it automatically uses "generated" and I also end up with a wrong path.
IntelliJ version 2016.3.4
Now https://github.com/tbroyer/gradle-apt-plugin states:
The goal of this plugin was to eventually no longer be needed, being superseded by built-in features. This is becoming a reality with Gradle 5.2 and IntelliJ IDEA 2019.1.
So:
dependencies {
compile("com.google.dagger:dagger:2.18")
annotationProcessor("com.google.dagger:dagger-compiler:2.18")
compileOnly("com.google.auto.factory:auto-factory:1.0-beta6")
annotationProcessor("com.google.auto.factory:auto-factory:1.0-beta6")
compileOnly("org.immutables:value-annotations:2.7.1")
annotationProcessor("org.immutables:value:2.7.1")
}
compileOnly is necessary if you use annotations, compile if you use classes, annotationProcessor introduced in Gradle 4.6.
To enable processing specific compile task:
compileJava {
options.annotationProcessorPath = configurations.annotationProcessor
}
To disable:
compileTestJava {
options.compilerArgs += '-proc:none'
}
UPDATE 2.2019
since Gradle 5.2 there is an easy way to do it - see gavenkoas answer
UPDATE 5.2018
The easiest way, I know of is to use the apt-idea plugin
Just activate the plugin in the build.gradle file:
plugins {
id 'java'
id 'net.ltgt.apt-idea' version "0.15"
}
and then add the annotation processors to the annotationProcessor configuration:
final DAGGER_VER = '2.16'
dependencies {
implementation "com.google.dagger:dagger:${DAGGER_VER}"
annotationProcessor"com.google.dagger:dagger-compiler:${DAGGER_VER}"
}
Test-project on GitHub: ex.dagger
(using IntelliJ 2018.1.4, Gradle 4.7)
ORIG ANSWER
There's a simple workaround using the parent-dir which works fine in IntelliJ 2016.3.4
Production sources directory: ../main
Test sources directory: ../test
Now gradle and IntelliJ will generate the code to the same directories.
Fixed in GitLab project V0.0.2
see also: apt-gradle-plugin issue#35
Hey there everyone I had the same issue and found a clean way of solving this issue.
I am using two libraries that require annotation processing (Lombok and MapStruct).
Also my IntelliJ is 2019.1 (update yours in case it's older) and Gradle 5.2.1.
First let's configure IntelliJ:
Disable Annotaion Processing in Settings, since we're going to delegate everything to Gradle:
Delegeate IDE actions to Gradle:
Last step is to configure your dependencies correctly in Gradle.
Dependencies section in Gradle:
Now you can execute the Build and Run from both command line and IDE.
Cheers!
2019.2.x
Disable annotation processor of intellij
add, build directory in your gradle build.gradle file
then run your gradle task to generate build file classes, example gradle compileJava
File -> project structure -> Modules -> Main Folder || remove exclude and add as source
And project should find all annotation and generated source file. Hope it helps.
I am developing a plugin for IntelliJ IDEA. The way I am going about this is by creating a plugin project in IDEA, then packaging this into a jar with appropriate META-INF/plugin.xml, and installing the plugin from the jar.
The problem is that I would like to add a dependency on org.scala-lang:scala-library:2.11.0. I have this specified as a library dependency in the IDEA project, but this information never seems to get passed along to the generated JAR.
How can I include this information in such a way that IntelliJ IDEA will recognize it?
As far as I understand, you want to bundle some library (e.g. scala library) with your plugin.
This is pretty simple.
Go to Project Settings, select module and go to Dependencies tab. Set scope for the library you want to bundle to 'Compile'. In this example it is 'checker-framework' library. 'groovy-2.3.6' library will not be bundled due to its scope set to 'Provided'. Save changes.
Prepare plugin for deployment
Then you got plugin, zipped, ready for deployment (uploading to repo or installing locally) in the root of project. It will contain lib folder with all necessary jars.
The officially supported plugin dependency management solution is to use Gradle with the gradle-intellij-plugin, via Gradle's dependencies or the intellij.plugins entry points. If you want to add a dependency on an artifact (ex. hosted on Maven Central), then configure dependencies just as you normally would in a Gradle based project:
buildscript {
repositories {
mavenCentral()
}
}
dependencies {
compile("org.scala-lang:scala-library:2.11.0")
}
The intellij.plugins entry point will add an artifact in the current project, as well as a <depends> tag to your plugin.xml file. To install an external plugin alongside your own, for example if you are using the Plugin Extensions feature (suppose the plugin is hosted on the JetBrains Plugin Repository), use the following snippet:
plugins {
id "org.jetbrains.intellij" version "0.2.13"
}
intellij {
//...
plugins "org.intellij.scala:2017.2.638"
}
Is there a simple way to attach sources to auto-generated Gradle-based dependencies with IntelliJ IDEA 13.0 that won't be erased on next Gradle refresh?
For example, my build.gradle has such entry:
project(":projectName") {
dependencies {
compile files("c:/Program Files (x86)/groovy-2.2.1/embeddable/groovy-all-2.2.1.jar")
// more stuff here
}
}
Thus when I click Refresh all Gradle projects
I get a nice dependency set looking like so:
but there are no sources attached and if I do attach them manually, on next refresh they are erased.
I have sources for many different libraries, sometimes in jar file, sometimes directly in the file system (e.g. my groovy install has sources in c:\Program Files (x86)\groovy-2.2.1\src\).
Some of the dependencies I use can be downloaded from maven central repo, but in my build.gradle all the dependencies are configured to be taken from my local file system.
Thanks!
Konrad
The only easy solution is to get the dependencies straight from a Maven repository (either Maven Central or an inhouse repository). If that's not an option for you, you'll have to configure sources via a hook such as idea.module.iml.withXml or idea.module.iml.whenMerged (after applying the idea plugin to allprojects). You can find details on these APIs in the Gradle Build Language Reference and the Gradle User Guide.
this is an odd request but here is the scenario. I am writing custom maven plugins that basically manipulate build versions then will install or deploy the modified jar. The plugin is called both via command line and a build profile.
The plugins all have similar behavior, so the solution will work for all. Currently I am manipulating the project version in memory, via MavenProject.setVersion(newVersion);. This works and builds a local jar with the new version, but once the MavenInstaller executes the newVersion jar is installed in my local repo with the old version information and location. Is there a way I can prevent or override this behavior? The plugin is not using the Maven Installer or Deployer directly, and is just part of the build phase.
The file is executed as: mvn install -Pincrement and the increment profile is associated with the process-sources phase.
EDIT 1: I am looking into overriding the install/deploy lifecycle with a plugin that will basically handle what I plan on doing, while also still handling the normal behavior of install/deploy.
http://www.sonatype.com/books/mvnref-book/reference/writing-plugins-sect-override-default-lifecycle.html
EDIT 2: Following Edit 1 I was able to override a default lifecycle, in this case install and deploy with a custom solution. I do not like that it requires a custom package, so packaging tag no longer refers to the true packaging type and requires me to set an additional tag so that I can lookup the type.