-
Notifications
You must be signed in to change notification settings - Fork 4.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use a project dependency for test->main dependency in Java plugin #6483
Comments
While this change should work, it has some unwanted consequences due to the fact that our variant model for JVM components isn't fully fleshed out:
I'm sure we can solve these problems by more correctly modelling the variants when either the I'm not sure if this is worth rushing into 5.0. |
After a little bit more experimentation, here's what I think is required:
However, this has another implication: cross-project dependencies would be resolved the same way, so the test runtime classpath would now contain I think we'll want to do this in a less disruptive way, perhaps by adding rules that choose the new variant only for self-project dependencies, and not for cross-project dependencies. |
@oehme Given my previous comments, do you still want to target this for 5.0? |
I think using the JAR is actually better, as it is much faster to load on Windows than classes folders. For the same reason I'm also in favor of creating API JARs instead of classes folders for compilation, but that's another issue. I don't think we need different behavior for local and downstream consumption. The price is small on Linux and on Windows it's actually faster to compile against a JAR. I'm fine with doing this in another release, I just added it to 5.0 as it may break some hidden assumptions that some plugins might have. |
But changing tests to have a local |
You mean by adding an opt-in and then nagging users to use it? That seems reasonable. |
Note that this is the root cause for #10872 |
We should make this configurable. And then we can change the default in a major (e.g. 8.0). This should be considered when we pick #12912 back up. |
We already modify our test compile classpath to swap the main classes out for the jar, purely for the performance benefits. Not having to do that in our own scripts would be nice. :) Also if you wanted a real performance boost, you could even skip generating the classes to the filesystem in the first place, and write them directly into the jar along with the resources. ;) |
@jvandort let's split this so we can put compileElements into 8.0 |
Instead of doing
sourceSets.test.compileClasspath += sourceSets.main.output
, the Java plugin should usedependencies { testImplementation thisProject }
and Gradle will automatically wire in the main variant of the project.The text was updated successfully, but these errors were encountered: