This message was deleted.

I think it doesn't exist, currently I am publishing to a local test maven repository

tasks.testDependsOnPublishToMavenLocalTestFrom(projects.composeResources)

Thanks Javi. That is unfortunate; seems like a commonish set up. I think I'll look into the GradleRunner source and see if I can unravel how that might be accomplished.

You can add your other projects inside that "withPluginClasspath" by adding them to the

pluginUnderTestMetadata

task's

pluginClasspath

.

val additionalPluginClasspath by configurations.creating
dependencies {
    additionalPluginClasspath(project(":foo"))
}
tasks {
    pluginUnderTestMetadata {
        pluginClasspath.from(additionalPluginClasspath)
    }
}

then

withPluginClasspath

inside the tests will have project ":foo" in it.

We try very hard to neither publish to nor consume from mavenLocal. It has caused me problems many times

Yes.

setFrom()

(or

from =

) would replace the default value.

We try very hard to neither publish to nor consume from mavenLocal. It has caused me problems many times

Very wise actually, as it is not a pure repo, but also a caching proxy for Maven. 🙂 But what you can always do too is to publish to a different local repository, just some path somewhere, for example in the

buildDirectory

. Unless you need it for cross-build coordination, it is probably always preferable over

mavenLocal()

.

I must have missed something. I have this, based on your snippet:

configurations {
	additionalPluginTestClasspath
}

dependencies {
    ...

    implementation project(':hibernate-core')
	additionalPluginTestClasspath project(':hibernate-core')
}

tasks {
	pluginUnderTestMetadata {
		pluginClasspath.from configurations.additionalPluginTestClasspath
	}
}

But still end up with test failures because:

> Could not find org.hibernate.orm:hibernate-core:6.1.3-SNAPSHOT.

Oh, indeed it doesn't work that way. If you already have the dependency in implementation, then it's already in the "plugin classpath". But that only means you can resolve plugin IDs from it, or use classes from the build scripts.

That is what I was asking 😉

If you want to resolve JARs from your build, from the build driven by TestKit, then you could use a composite build (emit a settings.gradle with includeBuild)

You'd still need to publish it somewhere first, no?

No. Imagine, without TestKit, having to resolve Hibernate right from your other Hibernate project, but from another unrelated project; then you can use a composite build so you don't even have to "publish" a "snapshot". https://docs.gradle.org/current/userguide/composite_builds.html Now, that other unrelated project can be driven by TestKit, it won't change anything 😉 (assuming the included build is compatible with the version of Gradle you're using for TestKit's withGradleVersion ; otherwise you'll indeed have to publish somewhere)

I understand what composite builds are. We use them already

Then either you don't understand what I'm suggesting, or I don't understand what your problem is / what you're trying to do 😅

Um, sure. That's why I said "I don't understanbd" 😉

How/where do you reference those modules? in

dependencies {}

of the build driven by TestKit?

I have a main module named

hibernate-core

This should work, provided you also have a

repository {}

the resolve the dependency from.

The project itself is fine. What does not work is the "local resolution" of

hibernate-core

relative to

id 'org.hibernate.orm'

Isn't that because your plugin itself adds a dependency on hibernate-core using that SNAPSHOT version?

🙂

If you wanted that to work, then you could have that "test" project itself be a composite build with the "outer" project, so it would resolve hibernate-core from that project (and if using the same Gradle version et al. almost all tasks should be up-to-date)

You mean separate the plugin and its tests?

Not necessarily no.

The "mock" project is the test

I'm certain I already saw such a setup in an open source project, but cannot remember which one. Have the mock project have a settings.gradle file that includeBuild() the Hibernate root project (so you have Hibernate inside your Hibernate)

So you are saying that that test (mock) project needs to be moved out of the plugin project, effectively splitting the plugin from it its tests

Nope: just have the settings.gradle be generated dynamically with the appropriate path to the Hibernate project (the one for which tests are running)

That will only work if you move the test (mock) outside the plugin

Hmm no. Why would it be?

Sure, I'll try that

For example, put the following in the test settings.gradle:

includeBuild(System.getProperty("test.hibernate-project-path"))

and add the following to TestKit's `withArguments()`:

"-Dtest.hibernate-project-path=" + Path.of("../../").toAbsolutePath()

To make sure I understand your suggestion properly... you think I should: 1. Change the test's settings.gradle to use

includeBuild

with relative path up-to

hibernate-core

2. Change the test's project.gradle to use

implementation project('hibernate-core')

3. 3. Do the `pluginClasspath.from`stuff you mentioned earlier correct?

Are you sure about that path? when I run the tests locally, it puts the test project inside /tmp/junitSomething/ so the includeBuild needs to reference the project with an absolute path

Ah, right, it gets copied

diff --git a/tooling/hibernate-gradle-plugin/src/test/resources/projects/simple/build.gradle b/tooling/hibernate-gradle-plugin/src/test/resources/projects/simple/build.gradle
index 20bc5d3..1f34c4b 100644
--- a/tooling/hibernate-gradle-plugin/src/test/resources/projects/simple/build.gradle
+++ b/tooling/hibernate-gradle-plugin/src/test/resources/projects/simple/build.gradle
@@ -27,7 +27,7 @@ dependencies {
 hibernate {
     // to get using the same version to work, we'd have to install hibernate-core into maven local prior to running these.
     // suck we won't be able to adequately test this part, but
-    useSameVersion = false
+    // useSameVersion = false
     enhancement {
         lazyInitialization( true )
         dirtyTracking = true

diff --git a/tooling/hibernate-gradle-plugin/src/test/resources/projects/simple/settings.gradle b/tooling/hibernate-gradle-plugin/src/test/resources/projects/simple/settings.gradle
index e69de29..e823638 100644
--- a/tooling/hibernate-gradle-plugin/src/test/resources/projects/simple/settings.gradle
+++ b/tooling/hibernate-gradle-plugin/src/test/resources/projects/simple/settings.gradle
@@ -0,0 +1 @@
+includeBuild(System.getProperty("test.hibernate-project-path"))

diff --git a/tooling/hibernate-gradle-plugin/src/test/java/org/hibernate/orm/tooling/gradle/JavaProjectTests.java b/tooling/hibernate-gradle-plugin/src/test/java/org/hibernate/orm/tooling/gradle/JavaProjectTests
.java
index 16b07d2..b5d5903 100644
--- a/tooling/hibernate-gradle-plugin/src/test/java/org/hibernate/orm/tooling/gradle/JavaProjectTests.java
+++ b/tooling/hibernate-gradle-plugin/src/test/java/org/hibernate/orm/tooling/gradle/JavaProjectTests.java
@@ -36,7 +36,7 @@ class JavaProjectTests {
                                .withProjectDir( projectDir.toFile() )
                                .withPluginClasspath()
                                .withDebug( true )
-                               .withArguments( "clean", "compileJava", "--stacktrace", "--no-build-cache" )
+                               .withArguments( "clean", "compileJava", "--stacktrace", "--no-build-cache", "-Dtest.hibernate-project-path=" + Path.of("../../").toAbsolutePath() )
                                .forwardOutput();

(repeat last change for each

withArguments()

, repeat changes for Kotlin tests)

Got pulled into one of those awesome "all Friday afternoon" meetings 😉 I'll play around with this some more. Thanks everyone