Testing plugins locally

Help/Discuss
1

I’d like to test my plugins locally using SNAPSHOT versions. I could publish some special version, that I later delete manually, to the plugin portal but publishing and consuming locally seems better.

And Gradle documentation says it supports this, unless that documentation is out of date.

However, following the steps outlined there I could not get this to work.

In the plugin project I have the following (taken nearly verbatim from the doc page):

plugins {
	...

	// for local publishing
	id 'maven-publish'
}


// local publishing (SNAPSHOT testing)
publishing {
	repositories {
		maven {
			name = 'localPluginRepository'
			url = "${buildDir}/local-plugin-repository"
		}
	}
}

I verified that the artifacts at least are published to that directory, so they are there.

The page is a bit unclear on exactly what to do on the consumer side, so maybe I am just messing this part up. I have tried 2 forms (new and old application of plugin):

// build.gradle
buildscript {
    repositories {
        maven {
            url = "${path-to-local-plugin-repository}"
        }
    }
    dependencies {
        classpath "org.hibernate.orm:org.hibernate.orm.gradle.plugin:6.0.1-SNAPSHOT"
    }
}

apply plugin: 'org.hibernate.orm'

this form leads to

> Could not resolve all artifacts for configuration ':classpath'.
   > Could not resolve org.hibernate.orm:hibernate-core:6.0.1-SNAPSHOT.

And the “new form”:

// settings.gradle
pluginManagement {
    repositories {
        maven {
            url "${path-to-local-plugin-repository}"
        }
        gradlePluginPortal()
    }
}

// build.gradle
plugins {
    ...
    id 'org.hibernate.orm'
}

which leads to

Plugin [id: 'org.hibernate.orm'] was not found in any of the following sources:

(notice it does not list any sources; that is not just a copy/paste error)

To note, I have also tried using the FQN of the plugin class in the id/apply, which also does not work.

Thanks for any ideas/pointers!

2

What task are you running in order to do the publishing? This feels like you might be missing the publication of the marker artifact in the local folder.

I didn’t test with the hibernate-orm project exactly as I think you’re wanting because there’s additional changes that would be required to publish all of the 6.0.1-SNAPSHOT dependencies I would need to the specific folder, but I did test with those in mavenLocal() since that’s already support supported automatically with what’s in the project. I deleted the plugin dependencies from mavenLocal though so that they were only in the folder.

My repositories for the test project look like this:

pluginManagement {
    repositories {
        maven {
            url = uri( "${gradle.gradleUserHomeDir}/tmp/plugins" )
        }
        mavenLocal()
        gradlePluginPortal()
    }
}

Although, I probably would just use mavenLocal() without the folder for my own project unless there was specifically something I was trying to work around with the folder.

3

I’ve had problems with SNAPSHOT and mavenLocal before, is the only reason. I can definitely try that.

The task I used to publish the plugin is publishAllPublicationsToLocalPluginRepositoryRepository. I was not sure how to use publishPlugins and have it pick up my local repository (nor publishing to mavenLocal for that matter).

I did then publish hibernate-core, which is a dependency of the plugin, to mavenLocal

4

I was able to get it to work using publishToMavenLocal. “Work” in terms of consuming it properly. For whatever reason, publishing to the “dedicated directory” did not work for whatever reason.

Like I mentioned earlier, I try to stay away from publishing things to mavenLocal. Especially SNAPSHOTs because it causes lots of problems later in my experience

5

Were you just working on the “dedicated directory” publishing locally or did a branch with it ever get pushed to a public remote? We can probably determine the reason here if it’s reproducible without guessing on some of the small details.

The com.gradle.plugin-publish plugin is special in that it doesn’t configure a standard repository, but if maven-publish is applied, it still creates the publications, and the ability to publish to mavenLocal(), like it does for everything else. In the 1.0.0 version that now has an RC out, maven-publish is automatically applied, so there’s no scenario where you wouldn’t just see those tasks going forward.

I imagine this is related to repository precedence and how they’re preferred for transitive dependencies when there’s multiple repositories involved. I’ve never had an issue with this, but the versioning I’m used to is very particular and it’s never possible to have a local version (SNAPSHOT or otherwise) that matches a version published remotely. Admittedly, this isn’t as easy to have when you publish nightlies and other things that are common on open-source projects.